بررسی اجمالی اندازه گیری عملکرد برنامه

این سند به شما کمک می‌کند تا مشکلات کلیدی عملکرد در برنامه خود را شناسایی و برطرف کنید.

مسائل کلیدی عملکرد

مشکلات زیادی وجود دارد که می‌تواند به عملکرد ضعیف یک برنامه منجر شود، اما موارد زیر برخی از مشکلات رایجی هستند که باید در برنامه خود به دنبال آنها باشید:

تأخیر راه‌اندازی

تأخیر راه‌اندازی، مدت زمانی است که بین ضربه زدن روی آیکون برنامه، اعلان یا سایر نقاط ورود و نمایش داده‌های کاربر روی صفحه طول می‌کشد.

اهداف اولیه زیر را در برنامه‌های خود دنبال کنید:

  • شروع سرد در کمتر از ۵۰۰ میلی‌ثانیه. شروع سرد زمانی اتفاق می‌افتد که برنامه در حال اجرا در حافظه سیستم وجود نداشته باشد. این اتفاق زمانی می‌افتد که برنامه برای اولین بار پس از راه‌اندازی مجدد اجرا می‌شود یا از زمانی که فرآیند برنامه توسط کاربر یا سیستم متوقف شده است.

    در مقابل، شروع گرم زمانی اتفاق می‌افتد که برنامه در پس‌زمینه در حال اجرا باشد. شروع سرد بیشترین کار را از سیستم می‌طلبد، زیرا باید همه چیز را از حافظه بارگذاری کرده و برنامه را مقداردهی اولیه کند. سعی کنید شروع سرد را به ۵۰۰ میلی‌ثانیه یا کمتر برسانید.

  • تأخیرهای P95 و P99 بسیار نزدیک به تأخیر متوسط ​​​​هستند. وقتی برنامه مدت زمان زیادی برای شروع طول می‌کشد، تجربه کاربری ضعیفی ایجاد می‌کند. ارتباطات بین فرآیندی (IPC) و ورودی/خروجی‌های غیرضروری در طول مسیر بحرانی راه‌اندازی برنامه می‌توانند باعث ایجاد تداخل در قفل و ایجاد ناهماهنگی شوند.

اسکرول جانک

جنک اصطلاحی است که به وقفه بصری اشاره دارد و زمانی رخ می‌دهد که سیستم قادر به ساخت و ارائه فریم‌ها به موقع برای نمایش آنها در صفحه با سرعت درخواستی ۶۰ هرتز یا بالاتر نیست. جنک بیشتر هنگام اسکرول کردن آشکار می‌شود، زمانی که به جای جریان روان انیمیشن، وقفه‌هایی وجود دارد. جنک زمانی ظاهر می‌شود که حرکت در طول مسیر برای یک یا چند فریم متوقف می‌شود، زیرا برنامه برای رندر محتوا بیشتر از مدت زمان یک فریم در سیستم زمان می‌برد.

برنامه‌ها باید نرخ تازه‌سازی ۹۰ هرتز را هدف قرار دهند. نرخ‌های رندرینگ مرسوم ۶۰ هرتز هستند، اما بسیاری از دستگاه‌های جدیدتر در طول تعاملات کاربر، مانند اسکرول کردن، در حالت ۹۰ هرتز کار می‌کنند. برخی از دستگاه‌ها حتی از نرخ‌های بالاتر تا ۱۲۰ هرتز نیز پشتیبانی می‌کنند.

برای مشاهده‌ی نرخ نوسازی (Refresh Rate) دستگاه در یک زمان مشخص، با استفاده از گزینه‌ی Developer Options > Show refresh rate در بخش Debugging ، یک گزینه‌ی همپوشانی (overlay) را فعال کنید.

گذارهایی که روان نیستند

این موضوع در طول تعاملاتی مانند جابجایی بین تب‌ها یا بارگذاری یک فعالیت جدید آشکار می‌شود. این نوع انتقال‌ها باید انیمیشن‌های روان باشند و شامل تأخیر یا لرزش بصری نباشند.

ناکارآمدی‌های برق

انجام کار، شارژ باتری را کاهش می‌دهد و انجام کارهای غیرضروری، عمر باتری را کم می‌کند.

تخصیص حافظه، که از ایجاد اشیاء جدید در کد حاصل می‌شود، می‌تواند باعث کار قابل توجهی در سیستم شود. دلیل این امر این است که نه تنها خود تخصیص‌ها نیاز به تلاش از سوی Android Runtime (ART) دارند، بلکه آزادسازی این اشیاء در آینده ( جمع‌آوری زباله ) نیز به زمان و تلاش نیاز دارد. هم تخصیص و هم جمع‌آوری، به ویژه برای اشیاء موقت، بسیار سریع‌تر و کارآمدتر هستند. اگرچه قبلاً بهترین روش برای جلوگیری از تخصیص اشیاء در هر زمان ممکن بود، اما توصیه می‌کنیم کاری را انجام دهید که برای برنامه و معماری شما منطقی‌تر باشد. با توجه به توانایی‌های ART، صرفه‌جویی در تخصیص‌ها با ریسک غیرقابل نگهداری بودن کد، بهترین روش نیست.

با این حال، این کار نیاز به تلاش دارد، بنابراین به خاطر داشته باشید که اگر اشیاء زیادی را در حلقه داخلی خود اختصاص دهید، می‌تواند به مشکلات عملکردی منجر شود.

شناسایی مسائل

ما گردش کار زیر را برای شناسایی و رفع مشکلات عملکرد توصیه می‌کنیم:

  1. مسیرهای حیاتی کاربر زیر را شناسایی و بررسی کنید:
    • جریان‌های راه‌اندازی رایج، از جمله از لانچر و اعلان.
    • صفحاتی که کاربر در آنها داده‌ها را پیمایش می‌کند.
    • انتقال بین صفحه نمایش ها.
    • جریان‌های طولانی مدت، مانند ناوبری یا پخش موسیقی.
  2. با استفاده از ابزارهای اشکال‌زدایی زیر، بررسی کنید که در جریان‌های قبلی چه اتفاقی می‌افتد:
    • Perfetto : به شما امکان می‌دهد با داده‌های زمان‌بندی دقیق، ببینید چه اتفاقی در کل دستگاه می‌افتد.
    • Memory Profiler : به شما امکان می‌دهد ببینید چه تخصیص‌های حافظه‌ای روی هیپ اتفاق می‌افتد.
    • Simpleperf : نمودار شعله‌ای از اینکه کدام فراخوانی‌های تابع بیشترین استفاده را از CPU در یک دوره زمانی خاص دارند، نشان می‌دهد. وقتی چیزی را در Systrace شناسایی می‌کنید که مدت زیادی طول می‌کشد، اما دلیل آن را نمی‌دانید، Simpleperf می‌تواند اطلاعات بیشتری ارائه دهد.

برای درک و اشکال‌زدایی این مشکلات عملکردی، اشکال‌زدایی دستی تک تک تست‌ها بسیار مهم است. شما نمی‌توانید مراحل قبلی را با تجزیه و تحلیل داده‌های تجمیع‌شده جایگزین کنید. با این حال، برای درک آنچه کاربران واقعاً می‌بینند و شناسایی زمان وقوع رگرسیون‌ها، راه‌اندازی مجموعه معیارها در تست خودکار و در محل مهم است:

  • جریان‌های استارتاپی
  • جانک
    • معیارهای میدانی
      • نکات مهم در مورد فریم کنسول بازی: در کنسول بازی، نمی‌توانید معیارها را به یک مسیر کاربری خاص محدود کنید. این کنسول فقط گزارش‌های کلی از مشکلات در سراسر برنامه را ارائه می‌دهد.
      • اندازه‌گیری سفارشی با FrameMetricsAggregator : می‌توانید از FrameMetricsAggregator برای ثبت معیارهای ناخواسته در طول یک گردش کار خاص استفاده کنید.
    • تست‌های آزمایشگاهی
      • پیمایش با Macrobenchmark
      • Macrobenchmark زمان‌بندی فریم‌ها را با استفاده از دستورات dumpsys gfxinfo که یک مسیر کاربر را دسته‌بندی می‌کنند، جمع‌آوری می‌کند. این روشی برای درک تغییرات در jank در طول یک مسیر کاربر خاص است. معیارهای RenderTime که مدت زمان ترسیم فریم‌ها را نشان می‌دهند، برای شناسایی پسرفت یا بهبود، از تعداد فریم‌های jank مهم‌تر هستند.

پیوندهای برنامه، پیوندهای عمیقی هستند که بر اساس URL وب‌سایت شما ایجاد می‌شوند و تعلق آنها به وب‌سایت شما تأیید شده است. دلایل زیر می‌تواند باعث عدم موفقیت تأیید پیوندهای برنامه شود.

  • محدوده‌های فیلتر Intent: فقط برای URLهایی که برنامه شما می‌تواند به آنها پاسخ دهد، autoVerify به فیلترهای Intent اضافه کنید.
  • سوئیچ‌های پروتکل تأیید نشده: ریدایرکت‌های سمت سرور و زیردامنه تأیید نشده، خطرات امنیتی محسوب می‌شوند و تأیید را با شکست مواجه می‌کنند. آن‌ها باعث می‌شوند همه لینک‌های autoVerify با شکست مواجه شوند. به عنوان مثال، هدایت لینک‌ها از HTTP به HTTPS، مانند example.com به www.example.com، بدون تأیید لینک‌های HTTPS می‌تواند باعث عدم تأیید شود. حتماً با اضافه کردن فیلترهای intent، App Links را تأیید کنید .
  • پیوندهای غیرقابل تأیید: اضافه کردن پیوندهای غیرقابل تأیید برای اهداف آزمایشی می‌تواند باعث شود سیستم پیوندهای برنامه را برای برنامه شما تأیید نکند.
  • سرورهای غیرقابل اعتماد: مطمئن شوید که سرورهای شما می‌توانند به برنامه‌های کلاینت شما متصل شوند.

برنامه خود را برای تجزیه و تحلیل عملکرد تنظیم کنید

برای دریافت بنچمارک‌های دقیق، تکرارپذیر و کاربردی از یک برنامه، راه‌اندازی صحیح آن ضروری است. روی سیستمی آزمایش کنید که تا حد امکان به محیط عملیاتی نزدیک باشد و در عین حال منابع نویز را سرکوب کند. بخش‌های زیر تعدادی از مراحل خاص APK و سیستم را که می‌توانید برای آماده‌سازی یک راه‌اندازی آزمایشی انجام دهید، نشان می‌دهد که برخی از آنها مختص هر مورد استفاده هستند.

نقاط ردیابی

برنامه‌ها می‌توانند کد خود را با رویدادهای ردیابی سفارشی ، ابزارسازی کنند.

در حالی که ردیابی‌ها ثبت می‌شوند، ردیابی سربار کمی در حدود ۵ میکروثانیه در هر بخش ایجاد می‌کند، بنابراین آن را در مورد هر روشی به کار نبرید. ردیابی بخش‌های بزرگتر کار با زمان بیش از ۰.۱ میلی‌ثانیه می‌تواند بینش قابل توجهی در مورد گلوگاه‌ها ارائه دهد.

ملاحظات APK

اشکال‌زدایی انواع مختلف می‌تواند برای عیب‌یابی و نمادگذاری نمونه‌های پشته مفید باشد، اما تأثیرات شدیدی بر عملکرد دارد. دستگاه‌هایی که اندروید ۱۰ (API Level 29) و بالاتر را اجرا می‌کنند می‌توانند از profileable android:shell="true" در مانیفست خود برای فعال کردن پروفایلینگ در نسخه‌های منتشر شده استفاده کنند.

از پیکربندی کاهش حجم کد در سطح تولید خود استفاده کنید. بسته به منابعی که برنامه شما استفاده می‌کند، این می‌تواند تأثیر قابل توجهی بر عملکرد داشته باشد. برخی از پیکربندی‌های ProGuard نقاط ردیابی را حذف می‌کنند، بنابراین حذف این قوانین را برای پیکربندی که روی آن تست‌ها را اجرا می‌کنید، در نظر بگیرید.

گردآوری

برنامه خود را روی دستگاه به یک وضعیت مشخص کامپایل کنید - عموماً speed برای سادگی، یا speed-profile برای عملکرد نزدیک‌تر به محیط تولید (اگرچه این کار مستلزم گرم کردن برنامه و حذف پروفایل‌ها، یا کامپایل پروفایل‌های پایه برنامه است).

هر دو speed و speed-profile میزان کد در حال اجرا که از dex تفسیر می‌شود و در نتیجه میزان کامپایل درجا (JIT) در پس‌زمینه که می‌تواند تداخل قابل توجهی ایجاد کند را کاهش می‌دهند. فقط speed-profile تأثیر بارگذاری کلاس زمان اجرا از dex را کاهش می‌دهد.

دستور زیر برنامه را با استفاده از حالت speed کامپایل می‌کند:

adb shell cmd package compile -m speed -f com.example.packagename

حالت کامپایل speed ، متدهای برنامه را به طور کامل کامپایل می‌کند. حالت speed-profile متدها و کلاس‌های برنامه را طبق پروفایلی از مسیرهای کد استفاده شده که در طول استفاده از برنامه جمع‌آوری می‌شود، کامپایل می‌کند. جمع‌آوری پروفایل‌ها به طور مداوم و صحیح می‌تواند دشوار باشد، بنابراین اگر تصمیم به استفاده از آنها دارید، مطمئن شوید که آنها آنچه را که انتظار دارید جمع‌آوری می‌کنند. پروفایل‌ها در مکان زیر قرار دارند:

/data/misc/profiles/ref/[package-name]/primary.prof

ملاحظات سیستم

برای اندازه‌گیری‌های سطح پایین و با دقت بالا، دستگاه‌های خود را کالیبره کنید. مقایسه‌های A/B را در همان دستگاه و همان نسخه سیستم عامل انجام دهید. حتی در همان نوع دستگاه، ممکن است تفاوت‌های قابل توجهی در عملکرد وجود داشته باشد.

در دستگاه‌های روت‌شده، استفاده از اسکریپت lockClocks را برای Microbenchmarks در نظر بگیرید. این اسکریپت‌ها از جمله موارد زیر را انجام می‌دهند:

  • CPU ها را در یک فرکانس ثابت قرار دهید.
  • هسته‌های کوچک را غیرفعال کنید و GPU را پیکربندی کنید.
  • تنظیم دمایی را غیرفعال کنید.

ما استفاده از اسکریپت lockClocks را برای تست‌های متمرکز بر تجربه کاربری مانند اجرای برنامه، تست DoU و تست jank توصیه نمی‌کنیم، اما می‌تواند برای کاهش نویز در تست‌های Microbenchmark ضروری باشد.

در صورت امکان، استفاده از یک چارچوب آزمایشی مانند Macrobenchmark را در نظر بگیرید که می‌تواند نویز را در اندازه‌گیری‌های شما کاهش داده و از عدم دقت اندازه‌گیری جلوگیری کند.

شروع کند برنامه: فعالیت غیرضروری ترامپولین

یک اکتیویتی ترامپولین می‌تواند زمان راه‌اندازی برنامه را بی‌جهت افزایش دهد، و مهم است که از این موضوع آگاه باشید که آیا برنامه شما این کار را انجام می‌دهد یا خیر. همانطور که در مثال زیر نشان داده شده است، یک activityStart بلافاصله توسط activityStart دیگری دنبال می‌شود، بدون اینکه هیچ فریمی توسط اکتیویتی اول ترسیم شود.

alt_text شکل ۱. ردی که فعالیت ترامپولین را نشان می‌دهد.

این می‌تواند هم در یک نقطه ورودی اعلان و هم در یک نقطه ورودی راه‌اندازی برنامه معمولی اتفاق بیفتد، و شما اغلب می‌توانید با بازسازی آن را برطرف کنید. برای مثال، اگر از این فعالیت برای انجام تنظیمات قبل از اجرای یک فعالیت دیگر استفاده می‌کنید، این کد را در یک کامپوننت یا کتابخانه قابل استفاده مجدد قرار دهید.

تخصیص‌های غیرضروری که باعث ایجاد GCهای مکرر می‌شوند

ممکن است در Systrace شاهد باشید که جمع‌آوری زباله (GC) بیشتر از آنچه انتظار دارید اتفاق می‌افتد.

در مثال زیر، هر 10 ثانیه در طول یک عملیات طولانی مدت، نشانگر این است که برنامه ممکن است در طول زمان به طور غیر ضروری اما مداوم تخصیص دهد:

alt_text شکل ۲. ردیابی که فاصله بین رویدادهای GC را نشان می‌دهد.

همچنین ممکن است متوجه شوید که هنگام استفاده از Memory Profiler، یک پشته فراخوانی خاص، بخش عمده‌ای از تخصیص‌ها را انجام می‌دهد. نیازی نیست که همه تخصیص‌ها را به شدت حذف کنید، زیرا این کار می‌تواند نگهداری کد را دشوارتر کند. در عوض، با کار بر روی نقاط حساس تخصیص‌ها شروع کنید.

قاب‌های بی‌کیفیت

خط لوله گرافیکی نسبتاً پیچیده است و ممکن است در تعیین اینکه آیا کاربر در نهایت ممکن است یک فریم از دست رفته را ببیند یا خیر، نکات ظریفی وجود داشته باشد. در برخی موارد، پلتفرم می‌تواند با استفاده از بافرینگ، یک فریم را "نجات" دهد. با این حال، می‌توانید بیشتر این نکات ظریف را نادیده بگیرید تا فریم‌های مشکل‌ساز را از دیدگاه برنامه خود شناسایی کنید.

وقتی فریم‌ها با کار کمی از سوی برنامه ترسیم می‌شوند، نقاط ردیابی Choreographer.doFrame() با سرعت ۱۶.۷ میلی‌ثانیه در دستگاهی با نرخ ۶۰ فریم بر ثانیه رخ می‌دهند:

alt_text شکل ۳. ردیابی که فریم‌های سریع مکرر را نشان می‌دهد.

اگر بزرگنمایی کنید و در طول مسیر حرکت کنید، گاهی اوقات می‌بینید که فریم‌ها کمی بیشتر طول می‌کشند تا تکمیل شوند، اما هنوز هم اشکالی ندارد زیرا آنها بیشتر از زمان اختصاص داده شده ۱۶.۷ میلی‌ثانیه خود طول نمی‌کشند:

alt_text شکل ۴. ردیابی که فریم‌های سریع مکرر را با انفجارهای دوره‌ای کار نشان می‌دهد.

وقتی اختلالی در این ریتم منظم مشاهده می‌کنید، مانند شکل ۵، یک فریم نامنظم خواهید داشت:

alt_text شکل ۵. ردیابی که یک قاب خراب را نشان می‌دهد.

می‌توانید با تمرین، آنها را شناسایی کنید.

alt_text شکل ۶. ردیابی که فریم‌های بی‌کیفیت بیشتری را نشان می‌دهد.

در برخی موارد، برای اطلاعات بیشتر در مورد اینکه کدام نماها در حال متورم شدن هستند یا RecyclerView چه کاری انجام می‌دهد، باید روی یک نقطه ردیابی زوم کنید. در موارد دیگر، ممکن است لازم باشد بیشتر بررسی کنید.

برای اطلاعات بیشتر در مورد شناسایی فریم‌های نامنظم و اشکال‌زدایی علل آنها، به رندرینگ آهسته مراجعه کنید.

اشتباهات رایج در RecyclerView

بی‌اعتبار کردن کل داده‌های پشتیبان RecyclerView بدون نیاز می‌تواند منجر به زمان رندر فریم طولانی و کندی شود. در عوض، برای به حداقل رساندن تعداد نماهایی که نیاز به به‌روزرسانی دارند، فقط داده‌هایی را که تغییر می‌کنند، بی‌اعتبار کنید.

برای روش‌های جلوگیری از فراخوانی‌های پرهزینه notifyDatasetChanged() که باعث به‌روزرسانی محتوا به جای جایگزینی کامل آن می‌شوند، به Present dynamic data مراجعه کنید.

اگر از هر RecyclerView تو در تو به درستی پشتیبانی نکنید، می‌تواند باعث شود RecyclerView داخلی هر بار به طور کامل از نو ساخته شود. هر RecyclerView داخلی تو در تو باید یک مجموعه RecycledViewPool داشته باشد تا از بازیافت نماها بین هر RecyclerView داخلی اطمینان حاصل شود.

عدم پیش‌واکشی کافی داده‌ها، یا عدم پیش‌واکشی به موقع، می‌تواند رسیدن به انتهای لیست پیمایش را زمانی که کاربر نیاز به انتظار برای داده‌های بیشتر از سرور دارد، ناخوشایند کند. اگرچه این از نظر فنی بی‌احتیاطی نیست، زیرا هیچ مهلت فریمی از دست نمی‌رود، اما می‌توانید با تغییر زمان و مقدار پیش‌واکشی، تجربه کاربری را به طور قابل توجهی بهبود بخشید تا کاربر مجبور نباشد برای داده‌ها منتظر بماند.

اشکال‌زدایی برنامه شما

در ادامه روش‌های مختلفی برای اشکال‌زدایی عملکرد برنامه شما ارائه شده است. برای مرور کلی در مورد ردیابی سیستم و استفاده از پروفایلر اندروید استودیو، ویدیوی زیر را مشاهده کنید.

اشکال‌زدایی هنگام راه‌اندازی برنامه با Systrace

برای مرور کلی فرآیند راه‌اندازی برنامه، به زمان راه‌اندازی برنامه مراجعه کنید و برای مرور کلی ردیابی سیستم، ویدیوی زیر را ببینید.

شما می‌توانید انواع استارت‌آپ‌ها را در مراحل زیر مشخص کنید:

  • راه‌اندازی سرد: با ایجاد یک فرآیند جدید بدون هیچ وضعیت ذخیره‌شده‌ای شروع می‌شود.
  • راه‌اندازی گرم: یا فعالیت را هنگام استفاده مجدد از فرآیند، یا فرآیند را با حالت ذخیره شده، دوباره ایجاد می‌کند.
  • راه‌اندازی داغ: فعالیت را مجدداً آغاز می‌کند و با تورم شروع می‌شود.

توصیه می‌کنیم Systraces را با برنامه System Tracing روی دستگاه ضبط کنید. برای اندروید ۱۰ و بالاتر، از Perfetto استفاده کنید. برای اندروید ۹ و پایین‌تر، از Systrace استفاده کنید. همچنین توصیه می‌کنیم فایل‌های ردیابی را با نمایشگر ردیابی مبتنی بر وب Perfetto مشاهده کنید. برای اطلاعات بیشتر، به «مروری بر ردیابی سیستم» مراجعه کنید.

برخی از مواردی که باید به دنبال آنها باشید شامل موارد زیر است:

  • رقابت بر سر مانیتور: رقابت برای منابع تحت حفاظت مانیتور می‌تواند باعث تأخیر قابل توجه در شروع برنامه شود.

  • تراکنش‌های اتصال همزمان: به دنبال تراکنش‌های غیرضروری در مسیر بحرانی برنامه خود باشید. اگر یک تراکنش ضروری پرهزینه است، همکاری با تیم پلتفرم مربوطه را برای ایجاد بهبود در نظر بگیرید.

  • GC همزمان: این مورد رایج و نسبتاً کم‌تأثیر است، اما اگر اغلب با آن مواجه می‌شوید، بررسی آن با استفاده از پروفایلر حافظه اندروید استودیو را در نظر بگیرید.

  • ورودی/خروجی: ورودی/خروجی‌های انجام‌شده در طول راه‌اندازی را بررسی کنید و به دنبال وقفه‌های طولانی باشید.

  • فعالیت قابل توجه در سایر نخ‌ها: این موارد می‌توانند با نخ رابط کاربری تداخل داشته باشند، بنابراین هنگام راه‌اندازی مراقب کارهای پس‌زمینه باشید.

توصیه می‌کنیم برای بهبود گزارش‌دهی معیار راه‌اندازی برنامه، هنگام تکمیل راه‌اندازی، reportFullyDrawn فراخوانی کنید. برای اطلاعات بیشتر در مورد استفاده از reportFullyDrawn به بخش «زمان نمایش کامل» مراجعه کنید. می‌توانید زمان‌های شروع تعریف‌شده توسط RFD را از طریق پردازنده ردیابی Perfetto استخراج کنید و یک رویداد ردیابی قابل مشاهده توسط کاربر منتشر می‌شود.

استفاده از ردیابی سیستم روی دستگاه

شما می‌توانید از برنامه سطح سیستمی به نام System Tracing برای ثبت ردیابی سیستم روی یک دستگاه استفاده کنید. این برنامه به شما امکان می‌دهد بدون نیاز به اتصال دستگاه یا اتصال آن به adb ، ردیابی‌ها را از دستگاه ضبط کنید.

استفاده از پروفایلر حافظه اندروید استودیو

شما می‌توانید از ابزار پروفایل حافظه اندروید استودیو برای بررسی فشار حافظه که ممکن است ناشی از نشت حافظه یا الگوهای استفاده نادرست باشد، استفاده کنید. این ابزار، نمای زنده‌ای از تخصیص اشیاء را ارائه می‌دهد.

شما می‌توانید با دنبال کردن اطلاعات حاصل از استفاده از Memory Profiler برای ردیابی دلیل و تعداد دفعات وقوع GCها، مشکلات حافظه را در برنامه خود برطرف کنید.

برای پروفایل کردن حافظه برنامه، مراحل زیر را انجام دهید:

  1. مشکلات حافظه را تشخیص دهید.

    یک جلسه پروفایل حافظه از سفر کاربری که می‌خواهید روی آن تمرکز کنید، ضبط کنید. همانطور که در شکل ۷ نشان داده شده است، به دنبال افزایش تعداد اشیاء باشید که در نهایت منجر به GCها می‌شود، همانطور که در شکل ۸ نشان داده شده است.

    alt_text شکل ۷. افزایش تعداد اشیاء.

    alt_text شکل ۸. جمع‌آوری زباله.

    بعد از اینکه مسیر کاربر که باعث افزایش فشار بر حافظه می‌شود را شناسایی کردید، ریشه‌های فشار بر حافظه را تجزیه و تحلیل کنید.

  2. نقاط حساس فشار حافظه را تشخیص دهید.

    همانطور که در شکل 9 نشان داده شده است، یک محدوده را در جدول زمانی انتخاب کنید تا هم Allocations و هم Shallow Size را به صورت بصری مشاهده کنید.

    alt_text شکل ۹. مقادیر مربوط به تخصیص‌ها و اندازه سطحی .

    روش‌های مختلفی برای مرتب‌سازی این داده‌ها وجود دارد. در ادامه چند مثال از اینکه چگونه هر دیدگاه می‌تواند به شما در تحلیل مشکلات کمک کند، آورده شده است.

    • مرتب‌سازی بر اساس کلاس : زمانی مفید است که می‌خواهید کلاس‌هایی را پیدا کنید که اشیاء تولید می‌کنند که در غیر این صورت در یک مخزن حافظه ذخیره می‌شوند یا دوباره استفاده می‌شوند.

      برای مثال، اگر برنامه‌ای را می‌بینید که هر ثانیه ۲۰۰۰ شیء از کلاسی به نام "Vertex" ایجاد می‌کند، تعداد تخصیص‌ها را هر ثانیه ۲۰۰۰ واحد افزایش می‌دهد و هنگام مرتب‌سازی بر اساس کلاس، این افزایش را مشاهده خواهید کرد. اگر می‌خواهید از این اشیاء برای جلوگیری از تولید زباله، دوباره استفاده کنید، یک استخر حافظه پیاده‌سازی کنید.

    • مرتب‌سازی بر اساس callstack : زمانی مفید است که می‌خواهید مسیری را پیدا کنید که حافظه در آن تخصیص داده می‌شود، مانند داخل یک حلقه یا داخل یک تابع خاص که کار تخصیص زیادی انجام می‌دهد.

    • Shallow Size : فقط حافظه خود شیء را ردیابی می‌کند. این برای ردیابی کلاس‌های ساده‌ای که عمدتاً از مقادیر اولیه تشکیل شده‌اند، مفید است.

    • اندازه حفظ‌شده : کل حافظه مربوط به شیء و ارجاعاتی که صرفاً توسط شیء ارجاع داده شده‌اند را نشان می‌دهد. این برای ردیابی فشار حافظه ناشی از اشیاء پیچیده مفید است. برای دریافت این مقدار، یک dump کامل از حافظه بگیرید، همانطور که در شکل 10 نشان داده شده است، و اندازه حفظ‌شده به عنوان یک ستون اضافه می‌شود، همانطور که در شکل 11 نشان داده شده است.

      alt_text شکل ۱۰. تخلیه کامل حافظه.

      ستون اندازه حفظ شده.
      شکل ۱۱. ستون اندازه حفظ‌شده.

  3. اندازه‌گیری تأثیر یک بهینه‌سازی

    GCها مشهودتر و اندازه‌گیری تأثیر بهینه‌سازی‌های حافظه آسان‌تر هستند. وقتی یک بهینه‌سازی فشار حافظه را کاهش می‌دهد، GCهای کمتری می‌بینید.

    برای اندازه‌گیری تأثیر بهینه‌سازی، در جدول زمانی پروفایلر، زمان بین GCها را اندازه‌گیری کنید. سپس می‌توانید ببینید که بین GCها زمان بیشتری طول می‌کشد.

    تأثیرات نهایی بهبود حافظه به شرح زیر است:

    • اگر برنامه دائماً با فشار حافظه مواجه نشود، احتمالاً تعداد دفعات خاموش شدن به دلیل کمبود حافظه کاهش می‌یابد.
    • داشتن GC های کمتر، به خصوص در P99، معیارهای jank را بهبود می‌بخشد. دلیل این امر این است که GC ها باعث ایجاد درگیری CPU می‌شوند که می‌تواند منجر به تعویق افتادن وظایف رندرینگ در حین انجام GC شود.
{% کلمه به کلمه %} {% فعل کمکی %} {% کلمه به کلمه %} {% فعل کمکی %}