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

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

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

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

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

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

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

  • شروع سرد در کمتر از 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: در کنسول 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 برای تطابق بیشتر عملکرد تولید (اگرچه این نیاز به گرم کردن برنامه و حذف پروفایل ها یا کامپایل کردن پروفایل های پایه برنامه دارد).

هم 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 شکل 1. اثری که فعالیت ترامپولین را نشان می دهد.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • شروع سرد در کمتر از 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: در کنسول 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 برای تطابق بیشتر عملکرد تولید (اگرچه این نیاز به گرم کردن برنامه و حذف پروفایل ها یا کامپایل کردن پروفایل های پایه برنامه دارد).

هم 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 شکل 1. اثری که فعالیت ترامپولین را نشان می دهد.

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

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

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

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

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

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

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

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

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

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

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

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

هنگامی که می بینید اختلال در این کادو معمولی ، یک قاب شوخی است ، همانطور که در شکل 5 نشان داده شده است:

alt_text شکل 5. اثری که یک قاب شوخی را نشان می دهد.

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

alt_text شکل 6. اثری که فریم های پرشور بیشتری را نشان می دهد.

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

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

اشتباهات مشترک بازیافت

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • I/O: I/O را در هنگام راه اندازی انجام دهید و به دنبال غرفه های طولانی باشید.

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

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

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

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

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

شما می توانید از Profiler Memory Android Studio برای بازرسی از فشار حافظه که ممکن است در اثر نشت حافظه یا الگوهای استفاده بد ایجاد شود ، استفاده کنید. این یک نمای زنده از تخصیص شی را ارائه می دهد.

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

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

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

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

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

    alt_text شکل 8 مجموعه زباله ها.

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

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

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

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

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

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

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

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

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

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

      alt_text شکل 10. حافظه کامل حافظه.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

جنجال

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

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

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

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

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

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

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

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

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

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

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

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

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

  • جریان استارتاپ
  • جانک
    • معیارهای میدانی
      • بازی Console Frame Vitals: در کنسول Play ، شما نمی توانید معیارها را برای یک سفر خاص کاربر محدود کنید. این فقط Jank را در کل برنامه گزارش می دهد.
      • اندازه گیری سفارشی با FrameMetricsAggregator : شما می توانید FrameMetricsAggregator برای ضبط معیارهای JANK در طول یک گردش کار خاص استفاده کنید.
    • تست های آزمایشگاهی
      • پیمایش با macrobenchmark .
      • Macrobenchmark زمان بندی فریم را با استفاده از دستورات dumpsys gfxinfo جمع می کند که یک سفر کاربر واحد را براکت می کند. این راهی برای درک تنوع در Jank در یک سفر خاص کاربر است. معیارهای RenderTime ، که نشان می دهد فریم های طولانی برای ترسیم ، مهمتر از شمارش فریم های شوخی برای شناسایی رگرسیون یا پیشرفت هستند.

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

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

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

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

نقاط ردیابی

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

در حالی که ردپایی در حال ضبط است ، ردیابی یک سربار کوچک تقریباً 5μs در هر بخش را متحمل می شود ، بنابراین آن را به هر روشی نگذارید. ردیابی تکه های بزرگتر از 0.1ms می تواند بینش قابل توجهی در مورد تنگناها ایجاد کند.

ملاحظات APK

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

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

تالیف

برنامه خود را در دستگاه خود به یک حالت شناخته شده کامپایل کنید -به طور کلی 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 را برای میکروب مارک ها در نظر بگیرید. از جمله موارد دیگر ، این اسکریپت ها موارد زیر را انجام می دهند:

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

ما توصیه نمی کنیم از اسکریپت lockClocks برای تست های متمرکز بر تجربه کاربر مانند راه اندازی برنامه ، تست دو و تست JANK استفاده کنیم ، اما می تواند برای کاهش نویز در آزمایش های میکروب مارک ضروری باشد.

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

راه اندازی برنامه آهسته: فعالیت غیر ضروری ترامپولین

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

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

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

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

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

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

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

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

قاب های شوخی

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

هنگامی که فریم ها با کار کمی مورد نیاز از برنامه ترسیم می شوند ، Tracepoints Choreographer.doFrame() در یک دستگاه 16.7ms در یک دستگاه 60 فریم در ثانیه اتفاق می افتد:

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

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

alt_text شکل 4. اثری که فریم های سریع مکرر را با پشت سر هم دوره ای کار نشان می دهد.

هنگامی که می بینید اختلال در این کادو معمولی ، یک قاب شوخی است ، همانطور که در شکل 5 نشان داده شده است:

alt_text شکل 5. اثری که یک قاب شوخی را نشان می دهد.

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

alt_text شکل 6. اثری که فریم های پرشور بیشتری را نشان می دهد.

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

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

اشتباهات مشترک بازیافت

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • I/O: I/O را در هنگام راه اندازی انجام دهید و به دنبال غرفه های طولانی باشید.

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

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

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

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

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

شما می توانید از Profiler Memory Android Studio برای بازرسی از فشار حافظه که ممکن است در اثر نشت حافظه یا الگوهای استفاده بد ایجاد شود ، استفاده کنید. این یک نمای زنده از تخصیص شی را ارائه می دهد.

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

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

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

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

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

    alt_text شکل 8 مجموعه زباله ها.

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

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

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

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

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

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

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

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

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

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

      alt_text شکل 10. حافظه کامل حافظه.

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

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

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

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

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

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