عملکرد را ارزیابی کنید

از Simpleperf برای ارزیابی عملکرد یک دستگاه استفاده کنید. Simpleperf یک ابزار پروفایل بومی برای برنامه ها و فرآیندهای بومی اندروید است. از CPU Profiler برای بررسی استفاده از CPU برنامه و فعالیت رشته در زمان واقعی استفاده کنید.

دو شاخص عملکرد قابل مشاهده برای کاربر وجود دارد:

• عملکرد قابل پیش بینی و قابل درک . آیا رابط کاربری (UI) فریم ها را رها می کند یا به طور مداوم با سرعت 60 فریم در ثانیه رندر می شود؟ آیا صدا بدون آرتیفکت یا پاپ پخش می شود؟ تأخیر بین لمس صفحه توسط کاربر و نمایش اثر روی نمایشگر چقدر است؟
• مدت زمان مورد نیاز برای عملیات طولانی تر (مانند باز کردن برنامه ها).

مورد اول بیشتر از دومی قابل توجه است. کاربران معمولا متوجه jank می‌شوند، اما نمی‌توانند زمان راه‌اندازی برنامه را 500 میلی‌ثانیه در مقابل 600 میلی‌ثانیه تشخیص دهند، مگر اینکه به دو دستگاه در کنار هم نگاه کنند. تأخیر لمس بلافاصله قابل توجه است و به طور قابل توجهی به درک یک دستگاه کمک می کند.

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

ظرفیت در مقابل جیتر

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

ظرفیت

ظرفیت کل مقدار منابعی است که دستگاه در مدت زمان مشخصی در اختیار دارد. این می تواند منابع CPU، منابع GPU، منابع I/O، منابع شبکه، پهنای باند حافظه یا هر معیار مشابهی باشد. هنگام بررسی عملکرد کل سیستم، انتزاع اجزای منفرد و فرض یک معیار واحد که عملکرد را تعیین می کند می تواند مفید باشد (مخصوصاً هنگام تنظیم یک دستگاه جدید زیرا بارهای کاری اجرا شده در آن دستگاه احتمالاً ثابت هستند).

ظرفیت یک سیستم بر اساس منابع محاسباتی آنلاین متفاوت است. تغییر فرکانس CPU/GPU ابزار اصلی تغییر ظرفیت است، اما موارد دیگری مانند تغییر تعداد هسته‌های CPU آنلاین وجود دارد. بر این اساس، ظرفیت یک سیستم با مصرف برق مطابقت دارد. تغییر ظرفیت همیشه منجر به تغییر مشابهی در مصرف برق می شود.

ظرفیت مورد نیاز در یک زمان معین به طور عمده توسط برنامه در حال اجرا تعیین می شود. در نتیجه، پلتفرم نمی‌تواند برای تنظیم ظرفیت مورد نیاز برای یک حجم کاری معین انجام دهد، و ابزارهای انجام این کار به بهبود زمان اجرا محدود می‌شود (فریم ورک اندروید، ART، Bionic، کامپایلر/درایورهای GPU، هسته).

عصبانیت

در حالی که ظرفیت مورد نیاز برای حجم کار به راحتی قابل مشاهده است، جیتر مفهومی مبهم‌تر است. برای آشنایی با جیتر به‌عنوان مانعی برای سیستم‌های سریع، به «مورد عملکرد ناپدید شده سوپرکامپیوتر: دستیابی به عملکرد بهینه در 8192 پردازنده ASCl Q» مراجعه کنید. (این تحقیق در مورد اینکه چرا ابررایانه ASCI Q به عملکرد مورد انتظار خود دست نیافته است و مقدمه ای عالی برای بهینه سازی سیستم های بزرگ است.)

این صفحه از اصطلاح جیتر برای توصیف آنچه که کاغذ ASCI Q نویز می نامد استفاده می کند. Jitter رفتار تصادفی سیستم است که از اجرای کار محسوس جلوگیری می کند. اغلب کاری است که باید اجرا شود، اما ممکن است الزامات زمان بندی دقیقی نداشته باشد که باعث شود در هر زمان خاصی اجرا شود. از آنجایی که تصادفی است، رد کردن وجود جیتر برای حجم کاری معین بسیار دشوار است. همچنین بسیار دشوار است که ثابت کنیم یک منبع شناخته شده از لرزش علت یک مشکل عملکرد خاص بوده است. ابزارهایی که بیشتر برای تشخیص علل جیتر استفاده می‌شوند (مانند ردیابی یا ورود به سیستم) می‌توانند جیتر خود را معرفی کنند.

منابع جیتر تجربه شده در پیاده سازی دنیای واقعی اندروید عبارتند از:

• تاخیر زمانبندی
• کنترل کننده های وقفه
• کد درایور برای مدت طولانی اجرا می‌شود و پیش‌پرداخت یا وقفه غیرفعال است
• سافتیرک های طولانی مدت
• مناقشه قفل (برنامه، فریمورک، درایور هسته، قفل بایندر، قفل mmap)
• جدال توصیفگر فایل که در آن یک رشته با اولویت پایین قفل یک فایل را نگه می‌دارد و از اجرای یک رشته با اولویت بالا جلوگیری می‌کند.
• اجرای کدهای حیاتی UI در صف های کاری که ممکن است به تاخیر بیفتد
• انتقال بیکار CPU
• ورود به سیستم
• تاخیرهای ورودی/خروجی
• ایجاد فرآیند غیرضروری (به عنوان مثال، پخش CONNECTIVITY_CHANGE )
• حذف حافظه پنهان صفحه ناشی از حافظه آزاد ناکافی است

مقدار زمان مورد نیاز برای یک دوره معین از لرزش ممکن است با افزایش ظرفیت کاهش یابد یا نباشد. به عنوان مثال، اگر درایور هنگام انتظار خواندن از طریق گذرگاه i2c، وقفه‌ها را غیرفعال کند، صرف نظر از اینکه پردازنده در فرکانس 384 مگاهرتز یا 2 گیگاهرتز باشد، مدت زمان ثابتی طول می‌کشد. افزایش ظرفیت یک راه حل عملی برای بهبود عملکرد زمانی که جیتر درگیر است نیست. در نتیجه، پردازنده‌های سریع‌تر معمولاً عملکرد را در موقعیت‌های محدود به لرزش بهبود نمی‌بخشند.

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

مصرف حافظه

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

تجزیه و تحلیل عملکرد اولیه دستگاه

شروع از یک سیستم عملکردی اما ضعیف و تلاش برای اصلاح رفتار سیستم با مشاهده موارد منفرد از عملکرد ضعیف قابل مشاهده توسط کاربر، استراتژی درستی نیست . از آنجا که عملکرد ضعیف معمولاً به راحتی قابل تکرار نیست (یعنی جیتر) یا یک مشکل برنامه، متغیرهای بیش از حد در سیستم کامل از موثر بودن این استراتژی جلوگیری می کند. در نتیجه، شناسایی نادرست علل و ایجاد بهبودهای جزئی در عین از دست دادن فرصت‌های سیستمی برای اصلاح عملکرد در سراسر سیستم بسیار آسان است.

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

1. سیستم بوت شدن سیستم را به رابط کاربری با درایورهای در حال اجرا و برخی تنظیمات پایه فرکانس تنظیم کنید (اگر تنظیمات تنظیم کننده فرکانس را تغییر دادید، تمام مراحل زیر را تکرار کنید).
2. اطمینان حاصل کنید که هسته از نقطه ردیابی sched_blocked_reason و همچنین سایر نقاط ردیابی در خط لوله نمایشگر پشتیبانی می کند که نشان دهنده زمانی است که فریم به نمایشگر تحویل داده می شود.
3. هنگام اجرای یک حجم کاری سبک و ثابت (مثلاً UiBench یا تست توپ در TouchLatency) از کل خط لوله UI (از دریافت ورودی از طریق IRQ تا اسکن نهایی) ردپای طولانی بگیرید.
4. افت فریم های شناسایی شده در حجم کاری سبک و ثابت را برطرف کنید.
5. مراحل 3-4 را تکرار کنید تا بتوانید هر بار 20+ ثانیه بدون فریم افت کرده بدوید.
6. به دیگر منابع قابل مشاهده برای کاربر از jank بروید.

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

• اطمینان حاصل کنید که هسته شما دارای وصله نقطه ردیابی sched_blocked_reason است. این نقطه ردیابی با دسته‌بندی sched trace در systrace فعال می‌شود و عملکردی را که مسئول خواب زمانی است که آن رشته وارد خواب بی‌وقفه می‌شود، فراهم می‌کند. این برای تجزیه و تحلیل عملکرد بسیار مهم است زیرا خواب بی وقفه یک شاخص بسیار رایج از لرزش است.
• مطمئن شوید که ردیابی کافی برای خطوط لوله گرافیکی و نمایشگر دارید. در SOCهای اخیر کوالکام، نقاط ردیابی با استفاده از موارد زیر فعال می شوند:

adb shell "echo 1 > /d/tracing/events/kgsl/enable"
adb shell "echo 1 > /d/tracing/events/mdss/enable"

این رویدادها هنگام اجرای systrace فعال می‌مانند، بنابراین می‌توانید اطلاعات اضافی را در ردیابی خط لوله نمایش (MDSS) در بخش mdss_fb0 مشاهده کنید. در SOCهای Qualcomm، هیچ اطلاعات اضافی درباره GPU در نمای استاندارد systrace نخواهید دید، اما نتایج در خود ردیابی وجود دارد (برای جزئیات، به درک systrace مراجعه کنید).

چیزی که شما از این نوع ردیابی نمایش می خواهید، یک رویداد واحد است که مستقیماً نشان می دهد که یک فریم به نمایشگر تحویل داده شده است. از آنجا، می توانید تعیین کنید که آیا زمان فریم خود را با موفقیت انجام داده اید یا خیر. اگر رویداد X n کمتر از 16.7 میلی ثانیه بعد از رویداد X n-1 رخ دهد (با فرض نمایشگر 60 هرتز)، پس می دانید که jank نکرده اید. اگر SOC شما چنین سیگنال هایی را ارائه نمی دهد، برای دریافت آنها با فروشنده خود همکاری کنید. اشکال زدایی جیتر بدون سیگنال قطعی تکمیل فریم بسیار دشوار است.

از معیارهای مصنوعی استفاده کنید

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

بر اساس تجربیات با SOCها، تفاوت در عملکرد معیار مصنوعی بین SOCها با تفاوت مشابهی در عملکرد UI محسوس (تعداد فریم های افت شده، زمان فریم صدک 99 و غیره) مرتبط نیست. معیارهای مصنوعی معیارهایی هستند که فقط ظرفیت دارند. لرزش بر عملکرد اندازه گیری شده این معیارها تنها با ربودن زمان از عملکرد انبوه معیار تأثیر می گذارد. در نتیجه، امتیازهای معیار مصنوعی عمدتاً به عنوان معیار عملکرد درک شده توسط کاربر بی‌ربط هستند.

دو SOC را در نظر بگیرید که Benchmark X را اجرا می کنند که 1000 فریم از UI را رندر می کند و کل زمان رندر را گزارش می کند (امتیاز کمتر بهتر است).

• SOC 1 هر فریم از Benchmark X را در 10 میلی ثانیه رندر می کند و 10000 امتیاز می گیرد.
• SOC 2 99% فریم ها را در 1 میلی ثانیه ارائه می کند اما 1% فریم ها را در 100 میلی ثانیه ارائه می دهد و امتیاز 19900 را به دست می آورد که به طور چشمگیری امتیاز بهتری دارد.

اگر معیار نشان دهنده عملکرد واقعی UI باشد، SOC 2 غیرقابل استفاده خواهد بود. با فرض نرخ نوسازی 60 هرتز، SOC 2 در هر 1.5 ثانیه کار، یک فریم janky خواهد داشت. در همین حال، SOC 1 (SOC کندتر طبق معیار X) کاملاً روان خواهد بود.

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

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

از TouchLatency استفاده کنید

چندین نمونه از رفتار بد از TouchLatency است که بار کاری دوره‌ای ترجیحی مورد استفاده برای Pixel و Pixel XL است. این در frameworks/base/tests/TouchLatency موجود است و دارای دو حالت است: تأخیر لمسی و توپ پرش (برای تغییر حالت ها، روی دکمه در گوشه سمت راست بالا کلیک کنید).

تست توپ پرش دقیقاً به همان سادگی است که به نظر می رسد: یک توپ بدون توجه به ورودی کاربر برای همیشه به اطراف صفحه می پرد. معمولاً همچنین سخت‌ترین آزمایش برای اجرای بی‌نقص است، اما هر چه به اجرای بدون هیچ فریمی نزدیک‌تر شود، دستگاه شما بهتر خواهد بود. آزمایش توپ پرش دشوار است زیرا یک حجم کاری بی اهمیت اما کاملاً ثابت است که در یک ساعت بسیار پایین اجرا می شود (این فرض را بر این می گذارد که دستگاه دارای یک تنظیم کننده فرکانس است؛ اگر دستگاه در عوض با ساعت های ثابت کار می کند، CPU/GPU را تا نزدیک به حداقل کاهش دهید. هنگام اجرای تست توپ پرش برای اولین بار). همانطور که سیستم خاموش می شود و ساعت ها به حالت بیکار نزدیک می شوند، زمان مورد نیاز CPU/GPU برای هر فریم افزایش می یابد. شما می‌توانید توپ را تماشا کنید و چیزهای بدی را ببینید، و همچنین می‌توانید فریم‌های از دست رفته را در systrace ببینید.

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

از آنجایی که جیتر اغلب (اما نه همیشه) با سرعت ساعت ثابت است، برای تشخیص لرزش به دلایل زیر از تستی استفاده کنید که در ساعت بسیار پایین اجرا می شود:

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