استخدِم Simpleperf لتقييم أداء جهاز. Simpleperf هي أداة تحليل أداء تطبيقات محلية والعمليات المحلية على Android. استخدِم أداة تحليل وحدة المعالجة المركزية للتحقّق من استخدام وحدة المعالجة المركزية للتطبيق ونشاط المواضيع في الوقت الفعلي.
هناك مؤشّران للأداء يظهران للمستخدم:
- أداء متوقع وواضح: هل تُسقط واجهة المستخدم (UI) اللقطات أو يتم عرضها باستمرار بمعدّل 60 لقطة في الثانية؟ هل يتم تشغيل الصوت بدون أي تشويش أو صوت عالٍ؟ ما هو طول المدة التي تستغرقها التأثيرات في الظهور على الشاشة بعد أن يلمسها المستخدم؟
- المدة الزمنية المطلوبة لتنفيذ العمليات الأطول (مثل فتح التطبيقات)
ويكون التأثير الأول أكثر وضوحًا من الثاني. يلاحظ المستخدمون عادةً الارتباك، ولكن لن يتمكّنوا من التمييز بين وقت بدء تشغيل التطبيق الذي يبلغ 500 ملي ثانية ووقت بدء تشغيله الذي يبلغ 600 ملي ثانية ما لم يكن ينظرون إلى جهازَين جنبًا إلى جنب. يمكن ملاحظة وقت استجابة اللمس على الفور ويساهم بشكل كبير في تقييم أداء الجهاز.
نتيجةً لذلك، في الأجهزة السريعة، تكون مسار معالجة واجهة المستخدم هي أهم عنصر في النظام باستثناء ما هو ضروري للحفاظ على مسار معالجة واجهة المستخدم. وهذا يعني أنّ مسار واجهة المستخدم يجب أن يسبق أي عمل آخر غير ضروري لتوفير واجهة مستخدم سلسة. للحفاظ على واجهة مستخدم سلسة، يجب تأخير مزامنة الخلفية وإرسال الإشعارات وغيرها من الأعمال المشابهة إذا كان من الممكن تنفيذ عمل واجهة المستخدم. من المقبول تقليل أداء العمليات الأطول (وقت تشغيل HDR+ وبدء تشغيل التطبيق وما إلى ذلك) للحفاظ على واجهة مستخدم سلسة.
السعة مقابل الارتعاش
عند النظر في أداء الجهاز، يُعدّ السعة والتشويش مقياسَين مهمّين.
السعة
السعة هي إجمالي مقدار بعض الموارد التي يمتلكها الجهاز على مدار فترة زمنية معيّنة. ويمكن أن تكون هذه الموارد هي موارد وحدة المعالجة المركزية أو وحدة معالجة الرسومات أو موارد الإدخال/الإخراج أو موارد الشبكة أو معدل نقل البيانات للذاكرة أو أي مقياس مشابه. عند فحص أداء النظام بأكمله، قد يكون من المفيد تجميع المكوّنات الفردية واستخدام مقياس واحد لتحديد الأداء (خاصةً عند ضبط إعدادات جهاز جديد لأنّه من المحتمل أن تكون أعباء العمل التي يتم تشغيلها على هذا الجهاز ثابتة).
تختلف سعة النظام استنادًا إلى موارد الحوسبة على الإنترنت. إنّ تغيير معدّل تكرار وحدة المعالجة المركزية أو وحدة معالجة الرسومات هو الوسيلة الأساسية لتغيير السعة، ولكن هناك وسائل أخرى، مثل تغيير عدد نوى وحدة المعالجة المركزية على الإنترنت. وبناءً على ذلك، تتوافق سعة النظام مع استهلاك الطاقة، ويؤدي تغيير السعة دائمًا إلى تغيير مماثل في استهلاك الطاقة.
يتم تحديد السعة المطلوبة في وقت معيّن بشكل كبير من قِبل التطبيق الذي يتم تشغيله. ونتيجةً لذلك، لا يمكن للنظام الأساسي فعل الكثير لضبط السعة المطلوبة لتحميل عمل معيّن، وتقتصر وسائل إجراء ذلك على تحسينات وقت التشغيل (إطار عمل Android وART وBionic ومجمع/برامج تشغيل وحدة معالجة الرسومات والنواة).
غير مستقر
على الرغم من أنّه من السهل معرفة السعة المطلوبة لأيّ حجم عمل، فإنّ الارتعاش هو مفهوم أكثر غموضًا. للحصول على مقدمة جيدة عن الارتعاش كعائق أمام الأنظمة السريعة، ننصحك بقراءة المقالة بعنوان حالة عدم توفّر أداء الكمبيوتر الفائق: تحقيق الأداء الأمثل على المعالجات الـ 8,192 في ASCI Q. (يتناول هذا التقرير التحقيق في سبب عدم تحقيق الكمبيوتر الفائق ASCI Q للأداء المتوقّع، وهو يقدّم مقدمة رائعة لتحسين الأنظمة الكبيرة).
تستخدِم هذه الصفحة مصطلح الارتعاش لوصف ما يُطلَق عليه في ورقة ASCI Q الضوضاء. الارتعاش هو سلوك النظام العشوائي الذي يمنع تنفيذ المهام التي يمكن ملاحظتها. غالبًا ما يكون هذا العمل مطلوبًا، ولكن قد لا يكون له متطلبات توقيت صارمة تؤدي إلى تشغيله في أي وقت محدّد. ولأنّه عشوائي، من الصعب جدًا إثبات عدم توفّر الارتعاش لتحميل ملف معين. ومن الصعب أيضًا إثبات أنّ مصدرًا معروفًا للانقطاع هو سبب مشكلة أداء معيّنة. إنّ الأدوات الأكثر استخدامًا لتشخيص أسباب الارتعاش (مثل التتبّع أو التسجيل) يمكن أن تتسبّب بدورها في الارتعاش.
تشمل مصادر الارتعاش التي تحدث في عمليات تنفيذ Android في العالم الحقيقي:
- تأخُّر المخطِّط
- معالجات المقاطعات
- تشغيل رمز برنامج تشغيل لفترة طويلة جدًا مع إيقاف الاستيلاء أو عمليات المقاطعة
- عمليات softirq التي تستغرق وقتًا طويلاً
- تزايد الطلب على دالة الاستبعاد المتبادل (التطبيق والإطار الأساسي وبرنامج تشغيل النواة وقفل الربط وقفل mmap )
- تعارض معرّف الملف حيث تحتفظ سلسلة محادثات ذات أولوية منخفضة بقفل ملف، ما يمنع سلسلة محادثات ذات أولوية عالية من التشغيل
- تشغيل رمز برمجي مهم لواجهة المستخدم في قوائم العمل التي قد يتأخّر فيها
- عمليات النقل في وضع السكون لوحدة المعالجة المركزية
- التسجيل
- تأخيرات في الإدخال والإخراج
- إنشاء عمليات غير ضرورية (مثل عمليات بث
CONNECTIVITY_CHANGE) - ازدحام التخزين المؤقت للصفحات بسبب عدم توفّر مساحة كافية في الذاكرة
قد ينخفض أو لا ينخفض المدّة الزمنية المطلوبة لفترة معيّنة من التقلّب مع زيادة السعة. على سبيل المثال، إذا ترك برنامج تشغيل عمليات المقاطعة متوقفة أثناء انتظار عملية قراءة من خلال ناقل i2c، سيستغرق ذلك مدّة زمنية ثابتة بغض النظر عمّا إذا كانت وحدة المعالجة المركزية تعمل بسرعة 384 ميغهرتز أو 2 غيغاهرتز. إنّ زيادة السعة ليست حلًا عمليًا لتحسين الأداء عند استخدام الارتعاش. ونتيجةً لذلك، لن تؤدي المعالجات الأسرع عادةً إلى تحسين الأداء في الحالات التي تتضمّن تأخيرًا في الإرسال.
أخيرًا، على عكس السعة، يُعدّ عدم الاستقرار من نطاق مورّد النظام بالكامل تقريبًا.
استهلاك الذاكرة
وعادةً ما يُحمّل استهلاك الذاكرة مسؤولية الأداء السيئ. على الرغم من أنّ الاستهلاك نفسه ليس مشكلة في الأداء، إلا أنّه يمكن أن يتسبب في حدوث تقطُّع في الأداء بسبب التأثير الإضافي لبرنامج lowmemorykiller وإعادة تشغيل الخدمة وزيادة عدد عمليات التخزين المؤقت للصفحات. يمكن أن يؤدي تقليل استهلاك الذاكرة إلى تجنُّب الأسباب المباشرة لضعف الأداء، ولكن قد يكون هناك تحسينات أخرى مستهدفة تتجنّب هذه الأسباب أيضًا (على سبيل المثال، تثبيت الإطار الأساسي لمنع إخراجه من الذاكرة عندما يتم تحميله مجددًا بعد ذلك بوقت قصير).
تحليل الأداء الأولي للجهاز
ليس من الاستراتيجيات الجيدة البدء من نظام يعمل بشكل جيد ولكنّ أداؤه ضعيف ومحاولة إصلاح سلوك النظام من خلال الاطّلاع على حالات فردية للأداء السيئ الذي يلاحظه المستخدم. ولأنّه لا يمكن عادةً تكرار الأداء السيئ بسهولة (أيّ الارتعاش) أو مشكلة في التطبيق، فإنّ العديد من المتغيّرات في النظام الكامل تمنع هذه الاستراتيجية من أن تكون فعّالة. نتيجةً لذلك، من السهل جدًا تحديد الأسباب بشكل خاطئ وإجراء تحسينات بسيطة مع عدم الاستفادة من الفرص المنهجية لإصلاح الأداء على مستوى النظام.
بدلاً من ذلك، اتّبِع النهج العام التالي عند عرض جهاز جديد:
- ابدأ تشغيل النظام لعرض واجهة المستخدم مع تشغيل جميع برامج التشغيل وبعض الإعدادات الأساسية لنظام التحكّم في التردد (إذا غيّرت إعدادات نظام التحكّم في التردد، كرِّر جميع الخطوات أدناه).
- تأكَّد من أنّ النواة متوافقة مع نقطة التتبّع
sched_blocked_reasonبالإضافة إلى نقاط التتبّع الأخرى في مسار العرض التي تشير إلى وقت إرسال الإطار إلى الشاشة. - يمكنك إجراء عمليات تتبُّع طويلة لقناة تدفق واجهة المستخدم بالكامل (بدءًا من تلقّي الإدخال عبر طلب إعادة جدولة طلبات الخدمة ووصولاً إلى عملية المسح النهائي) أثناء تنفيذ حمولة عمل خفيفة ومتسقة (على سبيل المثال، UiBench أو اختبار الكرة في TouchLatency).
- عالج مشاكل انخفاض معدل عرض اللقطات التي تم رصدها في الحمولة المنخفضة والمتسقة.
- كرِّر الخطوات من 3 إلى 4 إلى أن تتمكّن من تشغيل الفيديو بدون أي لقطات مفقودة لمدة 20 ثانية أو أكثر في المرة الواحدة.
- انتقِل إلى مصادر أخرى للانقطاع التي تظهر للمستخدم.
تشمل الإجراءات البسيطة الأخرى التي يمكنك اتّخاذها في مرحلة مبكرة من عملية إعداد الجهاز ما يلي:
- تأكَّد من أنّ نواة النظام تتضمّن تصحيح نقطة التتبّع sched_blocked_reason. يتم تفعيل نقطة التتبُّع هذه باستخدام فئة تتبُّع المخطط الزمني في systrace، وتوفر الدالة المسؤولة عن وضع السكون عندما يدخل سلسلت المعالجة هذه في وضع السكون غير القابل للمقاطعة. وهو أمر مهم لتحليل الأداء، لأنّ النوم غير القابل للانقطاع هو مؤشر شائع جدًا للتشويش.
- تأكَّد من توفّر بيانات تتبُّع كافية لوحدة معالجة الرسومات ومسار العرض. في المعالجات الدقيقة Qualcomm SOC الحديثة، يتم تفعيل نقاط التتبُّع باستخدام:
adb shell "echo 1 > /d/tracing/events/kgsl/enable"adb shell "echo 1 > /d/tracing/events/mdss/enable"
تظل هذه الأحداث مفعَّلة عند تشغيل systrace حتى تتمكّن من الاطّلاع على معلومات إضافية في التتبُّع حول مسار العرض (MDSS) في القسم
mdss_fb0. في وحدات المعالجة المركزية Qualcomm SOC، لن تظهر لك أي معلومات إضافية
حول وحدة معالجة الرسومات في عرض systrace العادي، ولكن تظهر النتائج
في عملية التتبّع نفسها (للاطّلاع على التفاصيل، اطّلِع على فهم
systrace).
ما تريده من هذا النوع من تتبُّع الشاشة هو حدث واحد يشير مباشرةً إلى أنّه تم عرض إطار على الشاشة. من هنا، يمكنك تحديد ما إذا كنت قد حقّقت وقت عرض اللقطة بنجاح. إذا حدث الحدث Xn في أقل من 16.7 ملي ثانية بعد الحدث Xn-1 (على افتراض شاشة بمعدل تكرار 60 هرتز)، هذا يعني أنّك لم تواجه أي تقطُّع. إذا لم توفّر وحدة التحكّم في العمليات هذه الإشارات، عليك التعاون مع المورّد للحصول عليها. من الصعب جدًا تصحيح أخطاء الارتعاش بدون إشارة نهائية لإكمال اللقطة.
استخدام مقاييس الأداء الاصطناعية
تكون مقاييس الأداء الاصطناعي مفيدة لضمان توفُّر الوظائف الأساسية للجهاز. ومع ذلك، لا يُعدّ التعامل مع معايير الأداء كبديل لأداء الجهاز المُلاحظ مفيدًا.
استنادًا إلى التجارب التي تم إجراؤها على وحدات المعالجة المركزية (SOC)، لا تترافق الاختلافات في الأداء الاصطناعي لوحدة المعالجة المركزية مع اختلاف مماثل في الأداء الملموس لواجهة المستخدم (عدد اللقطات التي تم إسقاطها، ووقت اللقطة في الشريحة المئوية التسعين، وما إلى ذلك). المقاييس التركيبية هي مقاييس للسعة فقط، ولا يؤثّر التقلّب في الأداء المقاس لهذه المقاييس إلا من خلال سرقة الوقت من عملية تنفيذ المقياس. ونتيجةً لذلك، فإنّ نتائج اختبارات الأداء الاصطناعي هي في الغالب غير ذات صلة كمقياس للأداء الذي يلاحظه المستخدم.
لنفترض أنّ لدينا وحدتَي معالجة مركزية (SOC) تعملان على اختبار X الذي يعرض 1,000 لقطة لواجهة المستخدم ويُبلغ عن إجمالي وقت العرض (كلما انخفضت النتيجة، كان ذلك أفضل).
- يعرض SOC 1 كل لقطة من "مقياس الأداء X" في 10 مللي ثانية ويحصل على 10,000.
- يعرض SOC 2 99% من اللقطات في 1 ملي ثانية، ولكنّه يعرض% 1 من اللقطات في 100 ملي ثانية ويحقّق نتيجة 19,900، وهي نتيجة أفضل بكثير.
إذا كان مقياس الأداء يشير إلى الأداء الفعلي لواجهة المستخدم، لن يكون SOC 2 قابلاً للاستخدام. بافتراض معدّل تحديث يبلغ 60 هرتز، سيظهر إطار متقطّع في SOC 2 كل 1.5 ثانية من التشغيل. وفي الوقت نفسه، سيكون أداء وحدة المعالجة المركزية 1 (وحدة المعالجة المركزية الأبطأ وفقًا لمقياس الأداء X) سلسًا تمامًا.
استخدام تقارير الأخطاء
تكون تقارير الأخطاء مفيدة في بعض الأحيان لتحليل الأداء، ولكن بسبب أنّها ملفات كبيرة جدًا، نادرًا ما تكون مفيدة لتصحيح أخطاء الأداء المتقطع. وقد تقدّم هذه الرسائل بعض الإشارات حول ما كان يفعله النظام في وقت معيّن، خاصةً إذا كان الأداء المتقطّع يحدث أثناء انتقال التطبيق (الذي يتم تسجيله في تقرير الأخطاء). يمكن أن تشير تقارير الأخطاء أيضًا إلى حدوث مشكلة عامة في النظام قد تؤدي إلى خفض طاقته الفعالة (مثل التضييق الحراري أو تجزئة الذاكرة).
استخدام TouchLatency
تأتي العديد من الأمثلة على السلوك السيئ من TouchLatency، وهي
وحدة العمل الدورية المفضّلة المستخدَمة في هاتفَي Pixel وPixel XL. يتوفّر هذا الاختبار عند
frameworks/base/tests/TouchLatency ويتضمن وضعَين: وقت استجابة اللمس
والكرة المرتدة (لتبديل الأوضاع، انقر على الزر في ناحية
أعلى اليسار).
اختبار الكرة المرتدة بسيط تمامًا كما يبدو: ترتد الكرة حول الشاشة إلى الأبد، بغض النظر عن تدخل المستخدم. وعادةً ما يكون هذا الاختبار هو بالأحرى أصعب اختبار يمكن إجراؤه بشكلٍ مثالي، ولكن كلما اقترب من التشغيل بدون أي لقطات مفقودة، كان أداء جهازك أفضل. إنّ اختبار الكرة المرتدة صعب لأنّه عبء عمل بسيط ولكنه متسق تمامًا يُنفَّذ بمعدّل ساعة منخفض جدًا (يفترض ذلك أنّ الجهاز يحتوي على معالج تردد مُدار. إذا كان الجهاز يعمل بدلاً من ذلك بمعدّلات ساعة ثابتة، عليك خفض معدّل الساعة لوحدة المعالجة المركزية/وحدة معالجة الرسومات إلى أقرب حدّ أدنى عند إجراء اختبار الكرة المرتدة للمرة الأولى). عندما يصبح النظام في وضع السكون وينخفض معدّل الساعة إلى ما يقرب من وضع السكون، يزداد وقت المعالجة المطلوب لكل إطار من وحدة المعالجة المركزية/وحدة معالجة الرسومات. يمكنك مشاهدة الكرة ورصد التقطُّع، وسيكون بإمكانك الاطّلاع على اللقطات التي تم تخطّيها في systrace أيضًا.
ولأنّ حجم العمل متّسق جدًا، يمكنك تحديد معظم مصادر التشويش بسهولة أكبر بكثير من معظم أحمال العمل المرئية للمستخدمين من خلال تتبُّع العمليات التي تتم على النظام أثناء كل لقطة مفقودة بدلاً من مسار تدفق واجهة المستخدم. تزيد الساعات ذات الترددات المنخفضة من تأثيرات الارتعاش من خلال جعل احتمالية أن يؤدي أي ارتعاش إلى إسقاط اللقطة أكثر. نتيجةً لذلك، كلما كان مقياس TouchLatency أقرب إلى 60 لقطة في الثانية، قلّ احتمال حدوث سلوكيات سيئة للنظام تؤدي إلى حدوث تقطُّع متقطع يصعب إعادة إنتاجه في التطبيقات الكبيرة.
بما أنّ التقلّب غالبًا ما يكون (ولكن ليس دائمًا) ثابتًا بالنسبة إلى سرعة الساعة، استخدِم اختبارًا يتم تنفيذه باستخدام سرعات ساعة منخفضة جدًا لتشخيص التقلّب للأسباب التالية:
- لا يكون كل الاضطراب ثابتًا بالنسبة إلى سرعة الساعة، فالعديد من المصادر تستهلك فقط وقت معالجة وحدة المعالجة المركزية.
- من المفترض أن يضبط أداة التحكّم متوسط وقت عرض اللقطة بالقرب من الموعد النهائي من خلال تقليل السرعة، لكي يؤدي الوقت الذي يُستغرَق في تنفيذ المهام غير المتعلّقة بواجهة المستخدم إلى تجاوز الحدّ المسموح به ل إسقاط لقطة.