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

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

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

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

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

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

اهداف راه اندازی زیر را در برنامه های خود هدف قرار دهید:

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

  در مقابل، شروع گرم زمانی رخ می دهد که برنامه از قبل در پس زمینه اجرا می شود. یک شروع سرد به بیشترین کار از سیستم نیاز دارد، زیرا باید همه چیز را از ذخیره سازی بارگیری کند و برنامه را مقداردهی اولیه کند. سعی کنید شروع سرد 500 میلی ثانیه یا کمتر طول بکشد.

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

جک اسکرول

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

برنامه ها باید نرخ تازه سازی 90 هرتز را هدف قرار دهند. نرخ‌های رندر معمولی 60 هرتز هستند، اما بسیاری از دستگاه‌های جدیدتر در هنگام تعامل با کاربر، مانند اسکرول، در حالت 90 هرتز کار می‌کنند. برخی از دستگاه ها حتی از نرخ های بالاتر تا 120 هرتز پشتیبانی می کنند.

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

انتقال هایی که صاف نیستند

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

ناکارآمدی قدرت

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

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

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

مسائل را شناسایی کنید

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

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

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

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

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

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

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

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

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

نقاط ردیابی

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

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

ملاحظات APK

احتیاط: عملکرد را در ساخت اشکال‌زدایی اندازه‌گیری نکنید.

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

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

تالیف

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

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

هم 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 دیگر بدون هیچ فریمی توسط اکتیویتی اول ترسیم می شود.

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

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

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

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

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

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

شکل 2. ردی که فضای بین رویدادهای GC را نشان می دهد.

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

فریم های جانکی

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

هنگامی که فریم‌ها با کمی کار مورد نیاز برنامه ترسیم می‌شوند، نقاط ردیابی Choreographer.doFrame() روی یک آهنگ 16.7 میلی‌ثانیه در دستگاه 60 فریم بر ثانیه رخ می‌دهد:

شکل 3. ردی که فریم های سریع مکرر را نشان می دهد.

اگر کوچک‌نمایی کنید و در ردیابی حرکت کنید، گاهی اوقات می‌بینید که تکمیل فریم‌ها کمی بیشتر طول می‌کشد، اما هنوز مشکلی ندارد زیرا آنها بیش از زمان اختصاص داده شده 16.7 میلی‌ثانیه خود را نمی‌گیرند:

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

همانطور که در شکل 5 نشان داده شده است، هنگامی که یک اختلال در این آهنگ منظم مشاهده می کنید، یک فریم janky است:

شکل 5. ردی که یک قاب جنکی را نشان می دهد.

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

شکل 6. ردی که فریم های جنکی بیشتری را نشان می دهد.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  نکته: برای دریافت اطلاعات بیشتر در مورد این تماس ها می توانید از am trace-ipc start استفاده کنید. آن را قبل از از سرگیری بنچمارک غیرفعال کنید، زیرا سربار قابل توجهی دارد و در غیر این صورت تا راه اندازی مجدد دستگاه باقی می ماند.

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

• I/O: بررسی کنید که آیا I/O در حین راه اندازی انجام شده است و به دنبال توقف های طولانی باشید.

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

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

از System Tracing در دستگاه استفاده کنید

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

از نمایه حافظه اندروید استودیو استفاده کنید

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

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

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

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

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

   شکل 7. افزایش تعداد اشیا.

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

   پس از شناسایی سفر کاربر که فشار حافظه را اضافه می کند، دلایل اصلی فشار حافظه را تجزیه و تحلیل کنید.

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

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

   شکل 9. مقادیر برای تخصیص و اندازه کم عمق .

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

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

     به عنوان مثال، اگر برنامه ای را مشاهده کنید که در هر ثانیه 2000 شی از کلاس به نام "راس" ایجاد می کند، تعداد Allocations را در هر ثانیه 2000 افزایش می دهد و هنگام مرتب سازی بر اساس کلاس آن را مشاهده می کنید. اگر می خواهید از این اشیاء برای جلوگیری از تولید زباله استفاده مجدد کنید، یک مخزن حافظه اجرا کنید.

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

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

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

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

     

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

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

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

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

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

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

{% کلمه به کلمه %} {% آخر کلمه %}