استخدِم Simpleperf لتقييم أداء الجهاز. Simpleperf هي أداة تتبُّع أصلية لكلّ من التطبيقات والعمليات الأصلية على Android. استخدِم أداة CPU Profiler لفحص استخدام وحدة المعالجة المركزية (CPU) في التطبيق ونشاط سلسلة المحادثات في الوقت الفعلي.
هناك مؤشّران مرئيّان للمستخدم بشأن الأداء:
- الأداء المتوقّع والملموس : هل تسقط واجهة المستخدم إطارات أو تعرضها باستمرار بمعدّل 60 لقطة في الثانية؟ هل يتم تشغيل الصوت بدون أي تشويش أو ضوضاء؟ ما هي مدة التأخير بين لمس المستخدم للشاشة وظهور التأثير على الشاشة؟
- المدة الزمنية اللازمة للعمليات الأطول (مثل فتح التطبيقات)
يكون المؤشّر الأول أكثر وضوحًا من المؤشّر الثاني. عادةً ما يلاحظ المستخدمون التقطّع، ولكن لن يتمكّنوا من التمييز بين وقت بدء تشغيل التطبيق الذي يبلغ 500 ملّي ثانية ووقت بدء تشغيله الذي يبلغ 600 ملّي ثانية ما لم يكونوا ينظرون إلى جهازَين جنبًا إلى جنب. يكون تأخير اللمس ملحوظًا على الفور ويساهم بشكل كبير في إدراك المستخدم للجهاز.
نتيجةً لذلك، في الجهاز السريع، يكون خط أنابيب واجهة المستخدم هو الأهم في النظام، باستثناء ما هو ضروري للحفاظ على عمل خط أنابيب واجهة المستخدم. يعني ذلك أنّ خط أنابيب واجهة المستخدم يجب أن يسبق أي عمل آخر غير ضروري لواجهة المستخدم السلسة. للحفاظ على واجهة مستخدم سلسة، يجب تأخير المزامنة في الخلفية وإرسال الإشعارات والأعمال المماثلة إذا كان من الممكن تشغيل عمل واجهة المستخدم. من المقبول استبدال أداء العمليات الأطول (وقت تشغيل HDR+ وبدء تشغيل التطبيق وما إلى ذلك) للحفاظ على واجهة مستخدم سلسة.
السعة مقابل التقطّع
عند تقييم أداء الجهاز، يكون السعة والتقطّع مقياسَين مهمّين.
السعة
السعة هي إجمالي مقدار بعض الموارد التي يمتلكها الجهاز خلال فترة زمنية معيّنة. يمكن أن تكون هذه الموارد موارد وحدة المعالجة المركزية أو وحدة معالجة الرسومات أو الإدخال والإخراج أو الشبكة أو معدّل نقل البيانات للذاكرة أو أي مقياس مشابه. عند فحص أداء النظام بأكمله، قد يكون من المفيد تجريد المكوّنات الفردية وافتراض مقياس واحد يحدّد الأداء (خاصةً عند ضبط جهاز جديد لأنّ أحمال العمل التي يتم تشغيلها على هذا الجهاز من المحتمل أن تكون ثابتة).
تختلف سعة النظام استنادًا إلى موارد الحوسبة المتاحة على الإنترنت. يُعد تغيير تردد وحدة المعالجة المركزية/وحدة معالجة الرسومات الوسيلة الأساسية لتغيير السعة، ولكن هناك وسائل أخرى، مثل تغيير عدد نوى وحدة المعالجة المركزية المتاحة على الإنترنت. وفقًا لذلك، تتوافق سعة النظام مع استهلاك الطاقة، ويؤدي تغيير السعة دائمًا إلى تغيير مماثل في استهلاك الطاقة.
يتم تحديد السعة المطلوبة في وقت معيّن بشكل كبير من خلال التطبيق قيد التشغيل. نتيجةً لذلك، لا يمكن للمنصة فعل الكثير لضبط السعة المطلوبة لحمل عمل معيّنة، وتقتصر وسائل إجراء ذلك على تحسينات وقت التشغيل (إطار عمل Android وART وBionic ومبرمج/برامج تشغيل وحدة معالجة الرسومات والنواة).
التقطّع
في حين أنّه من السهل الاطّلاع على السعة المطلوبة لحمل عمل، فإنّ التقطّع هو مفهوم أكثر غموضًا. للحصول على مقدّمة جيدة عن التقطّع كعائق أمام الأنظمة السريعة، ننصحك بقراءة الورقة البحثية بعنوان The Case of the Missing Supercomputer Performance: Achieving Optimal Performance on the 8,192 processors of ASCI Q. (هذا تحقيق في سبب عدم تحقيق الكمبيوتر الخارق ASCI Q للأداء المتوقّع، وهو مقدّمة رائعة لتحسين الأنظمة الكبيرة.)
تستخدم هذه الصفحة مصطلح التقطّع لوصف ما تسمّيه ورقة ASCI Q الضوضاء. التقطّع هو سلوك النظام العشوائي الذي يمنع تشغيل العمل المرئي. غالبًا ما يكون هذا العمل مطلوبًا، ولكن قد لا تكون له متطلبات توقيت صارمة تؤدي إلى تشغيله في أي وقت معيّن. بما أنّه عشوائي، فمن الصعب للغاية دحض وجود التقطّع لحمل عمل معيّنة. من الصعب أيضًا إثبات أنّ مصدرًا معروفًا للتقطّع كان سبب مشكلة في الأداء معيّنة. يمكن أن تؤدي الأدوات الأكثر استخدامًا لتشخيص أسباب التقطّع (مثل التتبُّع أو التسجيل) إلى حدوث التقطّع بنفسها.
تشمل مصادر التقطّع التي يتم رصدها في عمليات تنفيذ Android الواقعية ما يلي:
- تأخير أداة الجدولة
- معالجات المقاطعة
- تشغيل رمز برنامج التشغيل لفترة طويلة جدًا مع إيقاف الإيقاف المؤقت أو المقاطعات
- softirqs طويلة الأمد
- تزايد الطلب على دالة الاستبعاد المتبادل (التطبيق وإطار العمل وبرنامج تشغيل النواة وقفل Binder وقفل mmap)
- تزايد الطلب على واصف الملفات حيث تحتفظ سلسلة محادثات منخفضة الأولوية بالقفل على ملف، ما يمنع تشغيل سلسلة محادثات عالية الأولوية
- تشغيل رمز مهم لواجهة المستخدم في قوائم انتظار العمل حيث يمكن تأخيره
- عمليات الانتقال إلى وضع عدم نشاط وحدة المعالجة المركزية
- تسجيل
- تأخيرات الإدخال والإخراج
- إنشاء عمليات غير ضرورية (على سبيل المثال، عمليات البث
CONNECTIVITY_CHANGE) - احتدام ذاكرة التخزين المؤقت للصفحات الناتج عن عدم توفّر مساحة كافية في الذاكرة
قد تنخفض أو لا تنخفض المدة الزمنية المطلوبة لفترة معيّنة من التقطّع مع زيادة السعة. على سبيل المثال، إذا أوقف برنامج التشغيل المقاطعات أثناء انتظار عملية قراءة من ناقل i2c، فسيستغرق ذلك مدة زمنية ثابتة بغض النظر عمّا إذا كانت وحدة المعالجة المركزية تعمل بتردد 384 ميغاهرتز أو 2 غيغاهرتز. لا يُعدّ زيادة السعة حلاً مناسبًا لتحسين الأداء عند حدوث التقطّع. نتيجةً لذلك، لن تؤدي المعالجات الأسرع عادةً إلى تحسين الأداء في الحالات التي يكون فيها التقطّع هو العامل المحدد للأداء.
أخيرًا، على عكس السعة، يقع التقطّع بالكامل تقريبًا ضمن نطاق مسؤولية مورّد النظام.
استهلاك الذاكرة
يُعزى الأداء الضعيف تقليديًا إلى استهلاك الذاكرة. في حين أنّ الاستهلاك نفسه ليس مشكلة في الأداء، يمكن أن يؤدي إلى التقطّع من خلال النفقات العامة لبرنامج lowmemorykiller وعمليات إعادة تشغيل الخدمة وتدهور أداء ذاكرة التخزين المؤقت للصفحات. يمكن أن يؤدي تقليل استهلاك الذاكرة إلى تجنُّب الأسباب المباشرة للأداء الضعيف، ولكن قد تكون هناك تحسينات مستهدَفة أخرى تتجنّب هذه الأسباب أيضًا (على سبيل المثال، تثبيت إطار العمل لمنعه من الانتقال إلى الذاكرة الثانوية عندما سيتم نقله إلى الذاكرة الرئيسية بعد فترة قصيرة).
تحليل الأداء الأولي للجهاز
إنّ البدء بنظام عملي ولكن ضعيف الأداء ومحاولة إصلاح سلوك النظام من خلال النظر إلى حالات فردية من الأداء الضعيف المرئي للمستخدم ليس استراتيجية سليمة. نظرًا لأنّه ليس من السهل عادةً إعادة إنتاج الأداء الضعيف (أي التقطّع) أو مشكلة التطبيق، فإنّ عددًا كبيرًا جدًا من المتغيّرات في النظام الكامل يمنع هذه الاستراتيجية من أن تكون فعّالة. نتيجةً لذلك، من السهل جدًا تحديد الأسباب بشكل غير صحيح وإجراء تحسينات طفيفة مع تفويت فرص تحسين الأداء على مستوى النظام.
بدلاً من ذلك، استخدِم النهج العام التالي عند إعداد جهاز جديد:
- اجعل النظام يبدأ التشغيل إلى واجهة المستخدم مع تشغيل جميع برامج التشغيل وبعض إعدادات أداة تنظيم التردد الأساسية (إذا غيّرت إعدادات أداة تنظيم التردد، كرِّر جميع الخطوات أدناه).
- تأكَّد من أنّ النواة تتيح نقطة التتبُّع
sched_blocked_reasonبالإضافة إلى نقاط التتبُّع الأخرى في خط أنابيب العرض التي تشير إلى وقت تسليم الإطار إلى الشاشة. - خذ عمليات تتبُّع طويلة لخط أنابيب واجهة المستخدم بالكامل (بدءًا من تلقّي الإدخال من خلال طلب مقاطعة (IRQ) وصولاً إلى عملية المسح النهائية) أثناء تشغيل حمل عمل خفيفة ومتسقة (على سبيل المثال، 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، لا يرتبط الاختلاف في أداء مقاييس الأداء الاصطناعية بين أنظمة SOC باختلاف مماثل في أداء واجهة المستخدم الملموس (عدد الإطارات التي تم إسقاطها ووقت الإطار في المئوي التاسع والتسعين وما إلى ذلك). مقاييس الأداء الاصطناعية هي مقاييس أداء للسعة فقط، ويؤثر التقطّع في الأداء المقاس لهذه المقاييس فقط من خلال سرقة الوقت من العملية المجمّعة لمقياس الأداء. نتيجةً لذلك، تكون نتائج مقاييس الأداء الاصطناعية غير ذات صلة إلى حد كبير كمقياس للأداء الذي يلاحظه المستخدم.
لنفترض أنّ هناك نظامَي SOC يشغّلان مقياس الأداء X الذي يعرض 1000 إطار من واجهة المستخدم ويُبلغ عن إجمالي وقت العرض (النتيجة الأقل أفضل).
- يعرض نظام SOC 1 كل إطار من مقياس الأداء X في 10 ملّي ثانية ويحصل على نتيجة 10,000.
- يعرض نظام SOC 2% 99 من الإطارات في 1 ملّي ثانية و% 1 من الإطارات في 100 ملّي ثانية ويحصل على نتيجة 19,900، وهي نتيجة أفضل بكثير.
إذا كان مقياس الأداء يشير إلى أداء واجهة المستخدم الفعلي، فسيكون نظام SOC 2 غير قابل للاستخدام. بافتراض معدّل تحديث يبلغ 60 هرتز، سيعرض نظام SOC 2 إطارًا متقطّعًا كل 1.5 ثانية من التشغيل. في المقابل، سيكون نظام SOC 1 (نظام SOC الأبطأ وفقًا لمقياس الأداء X) سلسًا تمامًا.
استخدام تقارير الأخطاء
تكون تقارير الأخطاء مفيدة أحيانًا لتحليل الأداء، ولكن نظرًا لأنّها ثقيلة جدًا، فمن النادر أن تكون مفيدة لتصحيح أخطاء مشاكل التقطّع المتقطّع. قد تقدّم بعض المؤشرات حول ما كان يفعله النظام في وقت معيّن، خاصةً إذا كان التقطّع يحدث أثناء انتقال التطبيق (الذي يتم تسجيله في تقرير الأخطاء). يمكن أن تشير تقارير الأخطاء أيضًا إلى حدوث خطأ أوسع نطاقًا في النظام يمكن أن يقلّل من سعته الفعّالة (مثل التقييد الحراري أو تجزئة الذاكرة).
استخدام TouchLatency
تأتي العديد من الأمثلة على الأداء السيئ من TouchLatency، وهو حجم المعالجة الدوري المفضّل المستخدَم في Pixel وPixel XL. يتوفّر في frameworks/base/tests/TouchLatency وله وضعان: تأخير اللمس والكرة المرتدة (للتبديل بين الوضعَين، انقر على الزر في أعلى يسار الصفحة).
اختبار الكرة المرتدة بسيط تمامًا كما يبدو: ترتد الكرة على الشاشة إلى الأبد، بغض النظر عن إدخال المستخدم. عادةً ما يكون أيضًا إلى حد كبير الاختبار الأصعب لتشغيله بشكل مثالي، ولكن كلما اقترب من التشغيل بدون أي إطارات تم إسقاطها، كان جهازك أفضل. اختبار الكرة المرتدة صعب لأنّه حمل عمل بسيط ولكنه متسق تمامًا يتم تشغيله بتردد منخفض جدًا (يفترض ذلك أنّ الجهاز يتضمّن أداة تنظيم التردد. إذا كان الجهاز بدلاً من ذلك يعمل بترددات ثابتة، فقلِّل تردد وحدة المعالجة المركزية/وحدة معالجة الرسومات إلى الحد الأدنى تقريبًا عند تشغيل اختبار الكرة المرتدة لأول مرة). عندما يهدأ النظام وينخفض التردد إلى ما يقارب وضع عدم النشاط، يزداد وقت وحدة المعالجة المركزية/وحدة معالجة الرسومات المطلوب لكل إطار. يمكنك مشاهدة الكرة ورصد التقطّع، وستتمكّن أيضًا من الاطّلاع على الإطارات التي تم إسقاطها في systrace.
نظرًا لأنّ حمل العمل متسق جدًا، يمكنك تحديد معظم مصادر التقطّع بسهولة أكبر بكثير من معظم أحمال العمل المرئية للمستخدم من خلال تتبُّع ما يتم تشغيله بالضبط على النظام أثناء كل إطار تم إسقاطه بدلاً من خط أنابيب واجهة المستخدم. تؤدي الترددات المنخفضة إلى تضخيم آثار التقطّع من خلال زيادة احتمال أن يؤدي أي تقطّع إلى إسقاط إطار. نتيجةً لذلك، كلما اقترب TouchLatency من 60 لقطة في الثانية، قلّ احتمال حدوث سلوكيات سيئة في النظام تؤدي إلى تقطّع متقطّع يصعب إعادة إنتاجه في التطبيقات الأكبر.
بما أنّ التقطّع غالبًا (ولكن ليس دائمًا) لا يتأثر بسرعة التردد، استخدِم اختبارًا يتم تشغيله بترددات منخفضة جدًا لتشخيص التقطّع للأسباب التالية:
- لا يتأثر التقطّع بالكامل بسرعة التردد، فالعديد من المصادر تستهلك وقت وحدة المعالجة المركزية فقط.
- يجب أن تجعل أداة التنظيم متوسط وقت عرض اللقطة قريبًا من الموعد النهائي من خلال تقليل التردد، لذا يمكن أن يؤدي الوقت الذي يتم قضاؤه في تشغيل عمل غير مرتبط بواجهة المستخدم إلى تجاوز الحدّ الأقصى لإسقاط إطار.