از Simpleperf برای ارزیابی عملکرد دستگاه استفاده کنید. Simpleperf ابزار نمایه‌سازی بومی برای برنامه‌ها و فرایندهای بومی در Android است. از نمایه‌گر CPU برای بازرسی استفاده از CPU برنامه و فعالیت رشته به‌طور هم‌زمان استفاده کنید.
دو نشانگر عملکرد قابل‌مشاهده برای کاربر وجود دارد:
- عملکرد قابل‌پیش‌بینی و قابل‌درک. آیا میانای کاربر (UI) کاربر افت فریم دارد یا به‌طور مداوم با نرخ ۶۰ فریم در ثانیه رندر می‌شود؟ آیا صدا بدون آرتیفکت یا صدای ترک خوردگی پخش می‌شود؟ فاصله زمانی بین لمس کردن صفحه توسط کاربر و نمایش جلوه در نمایشگر چقدر است؟
- مدت زمان لازم برای عملیات طولانی‌تر (مثل باز کردن برنامه‌ها).
اولی بیشتر از دومی قابل‌توجه است. کاربران معمولاً متوجه لرزش می‌شوند اما نمی‌توانند تفاوت بین زمان راه‌اندازی برنامه ۵۰۰ میلی‌ثانیه و ۶۰۰ میلی‌ثانیه را تشخیص دهند، مگر اینکه دو دستگاه را کنار هم قرار دهند. تأخیر لمس بلافاصله قابل‌توجه است و به‌طور قابل‌توجهی در درک دستگاه نقش دارد.
درنتیجه، در دستگاه‌های سریع، خط لوله واسط کاربر مهم‌ترین چیز در سیستم است، به‌جز آنچه برای حفظ عملکرد خط لوله واسط کاربر ضروری است. این یعنی خط لوله میانای کاربر باید هر کار دیگری را که برای میانای کاربر روان ضروری نیست متوقف کند. برای حفظ رابط کاربری روان، همگام‌سازی پس‌زمینه، ارسال اعلان، و کارهای مشابه باید درصورت امکان اجرای کار رابط کاربری به‌تأخیر بیفتند. معاوضه عملکرد عملیات‌های طولانی‌تر (زمان اجرای HDR+، راه‌اندازی برنامه، و غیره) برای حفظ واسط کاربر روان قابل‌قبول است.
ظرفیت دربرابر لرزش
هنگام بررسی عملکرد دستگاه، ظرفیت و لرزش دو سنجه مهم هستند.
ظرفیت
ظرفیت مقدار کل یک منبع است که دستگاه در طول مدت زمانی دراختیار دارد. این می‌تواند منابع CPU، منابع GPU، منابع ورودی/خروجی، منابع شبکه، پهنای باند حافظه، یا هر سنجه مشابهی باشد. هنگام بررسی عملکرد کل سیستم، می‌توان اجزای جداگانه را انتزاعی کرد و یک سنجه واحد را به‌عنوان تعیین‌کننده عملکرد درنظر گرفت (به‌ویژه هنگام تنظیم دستگاه جدید، زیرا حجم‌های کاری که در آن دستگاه اجرا می‌شوند احتمالاً ثابت هستند).
ظرفیت یک سیستم براساس منابع محاسباتی آنلاین متفاوت است. تغییر فرکانس CPU/GPU روش اصلی تغییر ظرفیت است، اما روش‌های دیگری نیز وجود دارد، مانند تغییر تعداد هسته‌های CPU آنلاین. بنابراین، ظرفیت سیستم با مصرف برق مطابقت دارد؛ تغییر ظرفیت همیشه منجر به تغییر مشابهی در مصرف برق می‌شود.
ظرفیت موردنیاز در یک زمان مشخص عمدتاً توسط برنامه درحال اجرا تعیین می‌شود. درنتیجه، پلاتفرم نمی‌تواند کار زیادی برای تنظیم ظرفیت موردنیاز برای یک حجم کاری مشخص انجام دهد و ابزارهای انجام این کار محدود به بهبودهای زمان اجرا (چارچوب Android، ART، Bionic، کامپایلر/درایورهای GPU، هسته) است.
لرزش
درحالی‌که ظرفیت موردنیاز برای حجم کاری به‌راحتی قابل‌مشاهده است، لرزش مفهومی مبهم‌تر است. برای آشنایی خوب با لرزش به‌عنوان مانعی برای سیستم‌های سریع، توصیه می‌کنیم مقاله با عنوان The Case of the Missing Supercomputer Performance: Achieving Optimal Performance on the 8,192 processors of ASCI Q را بخوانید. (این مقاله درباره دلیل عدم دستیابی ابررایانه ASCI Q به عملکرد موردانتظارش است و مقدمه بسیار خوبی برای بهینه‌سازی سیستم‌های بزرگ است.)
این صفحه از اصطلاح لرزش برای توصیف آنچه مقاله ASCI Q نویز می‌نامد استفاده می‌کند. لرزش رفتار تصادفی سیستم است که مانع از اجرای کار قابل‌درک می‌شود. این کار اغلب باید اجرا شود، اما ممکن است الزامات زمان‌بندی دقیقی نداشته باشد که باعث شود در زمان خاصی اجرا شود. ازآنجایی‌که این نوسان تصادفی است، رد کردن وجود آن برای یک حجم کار معین بسیار دشوار است. همچنین اثبات اینکه یک منبع شناخته‌شده از لرزش باعث یک مشکل عملکردی خاص شده است، بسیار دشوار است. ابزارهایی که معمولاً برای تشخیص علت‌های لرزش استفاده می‌شوند (مثل ردیابی یا ثبت گزارش) می‌توانند لرزش خودشان را ایجاد کنند.
منابع لرزش تجربه شده در پیاده‌سازی‌های واقعی Android شامل:
- تأخیر زمان‌بندی
- کنترل‌کننده‌های وقفه
- کد درایور با غیرفعال بودن پیش‌گیری یا وقفه‌ها برای مدت طولانی اجرا می‌شود
- درخواست‌های وقفه نرم‌افزاری طولانی‌مدت
- درگیری بر سر قفل (برنامه، چارچوب، درایور هسته، قفل پیونددهنده، قفل mmap)
- رقابت توصیف‌گر فایل که در آن رشته‌ای با اولویت پایین قفل را روی فایل نگه می‌دارد و مانع از اجرای رشته‌ای با اولویت بالا می‌شود
- اجرای کد حیاتی رابط کاربری در صف‌های کاری که ممکن است با تأخیر مواجه شود
- انتقال‌های بی‌کار واحد پردازش مرکزی
- گزارش‌گیری
- تأخیرهای ورودی/خروجی
- ایجاد فرایند غیرضروری (برای مثال،
CONNECTIVITY_CHANGEهمه‌فرستی) - کوبش حافظه نهان صفحه به‌دلیل حافظه آزاد ناکافی
مقدار زمان موردنیاز برای یک دوره معین از لرزش ممکن است با افزایش ظرفیت کاهش یابد یا کاهش نیابد. برای مثال، اگر درایوری وقفه‌ها را درحین انتظار برای خواندن ازطریق گذرگاه i2c غیرفعال کند، صرف‌نظر از اینکه CPU روی ۳۸۴ مگاهرتز یا ۲ گیگاهرتز باشد، مدت‌زمان ثابتی طول خواهد کشید. افزایش ظرفیت راهکار مناسبی برای بهبود عملکرد درصورت وجود لرزش نیست. درنتیجه، پردازنده‌های سریع‌تر معمولاً عملکرد را در شرایط محدودشده با لرزش بهبود نمی‌بخشند.
در نهایت، برخلاف ظرفیت، لرزش تقریباً به‌طور کامل در حوزه فروشنده سیستم قرار دارد.
مصرف حافظه
به‌طور سنتی، مصرف حافظه مقصر عملکرد ضعیف دانسته می‌شود. اگرچه مصرف به‌خودی‌خود مشکل عملکردی نیست، اما می‌تواند ازطریق سربار lowmemorykiller، بازراه‌اندازی سرویس، و حافظه نهان صفحه باعث لرزش شود. کاهش مصرف حافظه می‌تواند از دلایل مستقیم عملکرد ضعیف جلوگیری کند، اما ممکن است بهبودهای هدفمند دیگری نیز وجود داشته باشد که از این دلایل جلوگیری کنند (برای مثال، سنجاق کردن چارچوب برای جلوگیری از صفحه‌بندی آن زمانی که به‌زودی صفحه‌بندی می‌شود).
تجزیه‌وتحلیل عملکرد اولیه دستگاه
شروع از یک سیستم کارآمد اما با عملکرد ضعیف و تلاش برای اصلاح رفتار سیستم با بررسی موارد فردی عملکرد ضعیف قابل مشاهده برای کاربر، استراتژی مناسبی نیست. ازآنجایی‌که عملکرد ضعیف معمولاً به‌راحتی قابل‌تکرار نیست (یعنی لرزش) یا مشکل برنامه است، متغیرهای بسیار زیاد در سیستم کامل مانع از مؤثر بودن این استراتژی می‌شود. درنتیجه، به‌راحتی می‌توان دلایل را اشتباه تشخیص داد و بهبودهای جزئی ایجاد کرد، درحالی‌که فرصت‌های سیستمی برای اصلاح عملکرد در سراسر سیستم ازدست می‌رود.
درعوض، هنگام راه‌اندازی دستگاه جدید از رویکرد کلی زیر استفاده کنید:
- سیستم را با همه درایورهای درحال اجرا و برخی تنظیمات پایه کنترل‌کننده بسامد به میانای کاربری بوت کنید (اگر تنظیمات کنترل‌کننده بسامد را تغییر دادید، همه مراحل زیر را تکرار کنید).
- مطمئن شوید که هسته از نقطه پیگیری
sched_blocked_reasonو همچنین دیگر نقاط پیگیری در خط لوله نمایشگر که نشان می‌دهد قاب چه زمانی به نمایشگر تحویل داده می‌شود پشتیبانی می‌کند. - ردگیری‌های طولانی از کل خط لوله میانای کاربر (از دریافت ورودی ازطریق IRQ تا اسکن نهایی) را درحین اجرای یک بار کاری سبک و ثابت (برای مثال، UiBench یا آزمایش توپ در TouchLatency) انجام دهید.
- افت‌های قاب شناسایی‌شده در بار کاری سبک و یکنواخت را برطرف کنید.
- مراحل ۳ و ۴ را تکرار کنید تا زمانی که بتوانید هر بار بیش‌از ۲۰ ثانیه بدون فریم افتاده اجرا کنید.
- به منابع دیگر قابل‌مشاهده کاربر از لرزش حرکت کنید.
از دیگر کارهای ساده‌ای که می‌توانید در مراحل اولیه راه‌اندازی دستگاه انجام دهید می‌توان به موارد زیر اشاره کرد:
- مطمئن شوید هسته شما دارای sched_blocked_reason tracepoint patch باشد. این نقطه ردیابی با دسته ردیابی زمان‌بندی در systrace فعال می‌شود و تابعی را که مسئول خوابیدن هنگام ورود آن رشته به خواب غیرقابل‌وقفه است ارائه می‌دهد. این ویژگی برای تجزیه‌وتحلیل عملکرد بسیار مهم است زیرا خواب بدون وقفه نشانگر بسیار رایجی برای لرزش است.
- مطمئن شوید که ردیابی کافی برای GPU و خطوط لوله نمایش دارید. در SOCهای جدید Qualcomm، نقطه‌های ردیابی بااستفاده از موارد زیر فعال می‌شوند:
adb shell "echo 1 > /d/tracing/events/kgsl/enable"adb shell "echo 1 > /d/tracing/events/mdss/enable"
این رویدادها هنگام اجرای systrace فعال می‌مانند تا بتوانید اطلاعات بیشتری درباره خط لوله نمایشگر (MDSS) در بخش mdss_fb0 در ردیابی ببینید. در «تراشه‌های سیستم» Qualcomm، اطلاعات اضافی درباره GPU در نمای استاندارد systrace نمی‌بینید، اما نتایج در خود ردیابی وجود دارد (برای جزئیات، به درک systrace مراجعه کنید).
آنچه از این نوع ردیابی نمایشگر می‌خواهید رویدادی واحد است که مستقیماً نشان دهد چارچوبی به نمایشگر تحویل داده شده است. از آنجا، می‌توانید تعیین کنید که آیا زمان پردازش فریم را با موفقیت به‌دست آورده‌اید یا نه؛ اگر رویداد Xn کمتر از ۱۶٫۷ میلی‌ثانیه پس‌از رویداد Xn-1 (با فرض نمایشگر ۶۰ هرتز) رخ دهد، متوجه می‌شوید که پرش نداشته‌اید. اگر SOC شما چنین نشان‌هایی ارائه نمی‌دهد، با تأمین‌کننده‌تان همکاری کنید تا آن‌ها را دریافت کنید. اشکال‌زدایی لرزش بدون داشتن سیگنال قطعی تکمیل قاب بسیار دشوار است.
استفاده از محک‌های ترکیبی
معیارهای سنجش ترکیبی برای اطمینان از وجود عملکرد پایه دستگاه مفید هستند. بااین‌حال، درنظر گرفتن محک‌ها به‌عنوان پراکسی برای عملکرد درک‌شده دستگاه مفید نیست.
براساس تجربه‌های SOC، تفاوت در عملکرد معیار ترکیبی بین SOCها با تفاوت مشابه در عملکرد UI محسوس (تعداد قاب‌های افتاده، زمان قاب صدک ۹۹، و غیره) همبستگی ندارد. معیارهای سنجش مصنوعی فقط معیارهای سنجش ظرفیت هستند؛ لرزش فقط با گرفتن زمان از عملیات انبوه معیار سنجش بر عملکرد اندازه‌گیری‌شده این معیارهای سنجش تأثیر می‌گذارد. درنتیجه، امتیازهای محک‌زنی مصنوعی عمدتاً به‌عنوان سنجه‌ای برای عملکرد مشهود برای کاربر بی‌ربط هستند.
دو SOC را درنظر بگیرید که «معیار X» را اجرا می‌کنند که ۱۰۰۰ فریم از واسط کاربر را پرداز می‌زند و کل زمان پرداز زدن را گزارش می‌کند (امتیاز پایین‌تر بهتر است).
- SOC 1 هر فریم از «معیار X» را در ۱۰ میلی‌ثانیه رندر می‌کند و امتیاز ۱۰٬۰۰۰ را کسب می‌کند.
- SOC 2 ۹۹٪ قاب‌ها را در ۱ میلی‌ثانیه پرداز می‌کند اما ۱٪ قاب‌ها را در ۱۰۰ میلی‌ثانیه پرداز می‌کند و امتیاز ۱۹٬۹۰۰ را کسب می‌کند که امتیازی به‌مراتب بهتر است.
اگر این معیار نشان‌دهنده عملکرد واقعی واسط کاربر باشد، SOC 2 غیرقابل استفاده خواهد بود. با فرض نرخ بازآوری ۶۰ هرتز، SOC 2 هر ۱٫۵ ثانیه عملکرد یک قاب لرزان خواهد داشت. درحالی‌که SOC 1 (SOC کندتر طبق «معیار X») کاملاً روان خواهد بود.
استفاده از گزارش‌های اشکال
گزارش‌های اشکال گاهی برای تجزیه‌وتحلیل عملکرد مفید هستند، اما چون بسیار سنگین هستند، به‌ندرت برای اشکال‌زدایی مشکلات پرش‌های پراکنده مفید هستند. این گزارش‌ها ممکن است سرنخ‌هایی درباره عملکرد سیستم در یک زمان معین ارائه دهند، به‌ویژه اگر کندی مربوط به انتقال برنامه باشد (که در گزارش اشکال ثبت می‌شود). گزارش‌های اشکال همچنین می‌توانند نشان دهند که چه زمانی مشکلی گسترده‌تر در سیستم وجود دارد که می‌تواند ظرفیت مؤثر آن را کاهش دهد (مانند محدودیت حرارتی یا تکه‌تکه شدن حافظه).
استفاده از TouchLatency
چندین نمونه از عملکرد بد از TouchLatency می‌آید که
بار کاری دوره‌ای ترجیحی مورداستفاده برای Pixel و Pixel XL است. در
frameworks/base/tests/TouchLatency دردسترس است و دو حالت دارد: تأخیر لمس
و توپ جهنده (برای تغییر حالت، روی دکمه گوشه بالا سمت راست
کلیک کنید).
آزمایش توپ جهنده دقیقاً به همان سادگی است که به‌نظر می‌رسد: توپی بدون توجه به درونداد کاربر، برای همیشه در صفحه می‌جهد. این آزمایش معمولاً به‌مراتب سخت‌ترین آزمایش برای اجرای بی‌نقص است، اما هرچه به اجرای بدون هیچ‌گونه قاب افتاده نزدیک‌تر باشد، دستگاه شما بهتر خواهد بود. آزمایش توپ جهنده دشوار است زیرا حجم کاری جزئی اما کاملاً سازگار است که با سرعت ساعت بسیار پایینی اجرا می‌شود (این فرض می‌کند که دستگاه دارای کنترل‌کننده فرکانس است؛ اگر دستگاه با سرعت ساعت ثابت اجرا می‌شود، هنگام اجرای آزمایش توپ جهنده برای اولین‌بار، سرعت ساعت CPU/GPU را به نزدیک حداقل کاهش دهید). با آرام شدن سیستم و نزدیک شدن ساعت‌ها به حالت آماده به‌کار، زمان موردنیاز CPU/GPU به‌ازای هر فریم افزایش می‌یابد. می‌توانید توپ را تماشا کنید و ببینید که چیزها دچار لرزش می‌شوند، و همچنین می‌توانید فریم‌های ازدست‌رفته را در systrace ببینید.
ازآنجایی‌که بار کاری بسیار یکنواخت است، می‌توانید با پیگیری دقیق آنچه در سیستم درطول هر قاب ازدست‌رفته اجرا می‌شود، به‌جای خط لوله رابط کاربری، بیشتر منابع لرزش را بسیار آسان‌تر از اکثر بارهای کاری قابل‌مشاهده کاربر شناسایی کنید. ساعت‌های پایین‌تر با افزایش احتمال افت فریم ناشی از لرزش، اثرات لرزش را تقویت می‌کنند. در نتیجه، هرچه TouchLatency به ۶۰FPS نزدیک‌تر باشد، احتمال اینکه رفتار بد سیستم باعث ایجاد پرش‌های پراکنده و سخت‌تکرار در برنامه‌های بزرگ‌تر شود کمتر است.
ازآنجایی‌که لرزش اغلب (اما نه همیشه) مستقل از سرعت ساعت است، از آزمایشی استفاده کنید که در سرعت‌های ساعت بسیار پایین اجرا می‌شود تا لرزش را به دلایل زیر تشخیص دهد:
- همه لرزش‌ها مستقل از سرعت ساعت نیستند؛ بسیاری از منابع فقط زمان CPU مصرف می‌کنند.
- فرماندار باید با کاهش سرعت ساعت، میانگین زمان پردازش فریم را به مهلت مقرر نزدیک کند، بنابراین زمان صرف‌شده برای اجرای کارهای غیررابط کاربری می‌تواند آن را به مرز حذف فریم برساند.