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

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

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

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

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

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

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

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

اسکرول جانک

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

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

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

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

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

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

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

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

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

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

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

برای رفع مشکلات عملکرد، مسیرهای حیاتی کاربر زیر را شناسایی و بررسی کنید:

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

برای هر یک از این جریان‌ها، با استفاده از ابزارهای اشکال‌زدایی زیر، آنچه اتفاق می‌افتد را بررسی کنید:

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

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

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

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

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

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

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

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

نقاط ردیابی

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

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

ملاحظات APK

اشکال‌زدایی انواع مختلف می‌تواند برای عیب‌یابی و نمادگذاری نمونه‌های پشته مفید باشد، اما تأثیرات شدیدی بر عملکرد دارد. دستگاه‌هایی که اندروید ۱۰ (سطح API ۲۹) و بالاتر را اجرا می‌کنند می‌توانند از 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 دیگری دنبال می‌شود، بدون اینکه هیچ فریمی توسط اکتیویتی اول ترسیم شود.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

در برخی موارد، برای اطلاعات بیشتر در مورد اینکه کدام اجزای رابط کاربری توسط Compose به‌روزرسانی می‌شوند یا مانند شکل 6، برای اینکه بدانید یک LazyColumn چه کاری انجام می‌دهد، باید روی یک نقطه ردیابی زوم کنید. هنگام تشخیص این گلوگاه‌های رابط کاربری، ردیابی استاندارد سیستم ممکن است نشان ندهد که کدام composableها علت اصلی هستند. در این موارد، از ردیابی ترکیب Jetpack Compose استفاده کنید، که توابع composable دقیق را مستقیماً در داخل ردیابی نشان می‌دهد و تشخیص ترکیب‌های غیرمنتظره را آسان‌تر می‌کند. شکل‌های 5 و 6 نتایج ردیابی ترکیب را نشان می‌دهند.

برای اطلاعات بیشتر در مورد بهینه‌سازی عملکرد Compose، به Jetpack Compose Performance مراجعه کنید. برای اطلاعات بیشتر در مورد شناسایی فریم‌های مشکل‌دار و اشکال‌زدایی علل آنها، به Slow rendering مراجعه کنید.

اشتباهات رایج در چیدمان با تنبلی

بی‌اعتبار کردن کل وضعیت پشتیبان یک طرح‌بندی تنبل (lazy layout) بدون نیاز به بررسی می‌تواند منجر به ترکیب‌بندی‌های بیش از حد، زمان رندر فریم طولانی و بی‌نظمی شود. برای به حداقل رساندن تعداد آیتم‌های لیست که نیاز به به‌روزرسانی دارند، از کلیدهای آیتم برای آیتم‌های خود استفاده کنید و فقط عناصر وضعیت خاصی را که تغییر می‌کنند، تغییر دهید.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

     

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

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

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

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

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