استخدِم أداة Simpleperf لتقييم أداء الجهاز. Simpleperf هي أداة تحليل أداء أصلية لكل من التطبيقات والعمليات الأصلية على Android. استخدِم أداة فحص استخدام وحدة المعالجة المركزية لفحص استخدام التطبيق لوحدة المعالجة المركزية ونشاط سلاسل التعليمات في الوقت الفعلي.
هناك مؤشّران مرئيان للمستخدمين حول الأداء:
- أداء يمكن توقّعه وإدراكه: هل تتجاهل واجهة المستخدم بعض اللقطات أو تعرضها باستمرار بمعدل 60 لقطة في الثانية؟ هل يتم تشغيل الصوت بدون تشويش أو تقطّع؟ ما هو مقدار التأخير بين لمس المستخدم للشاشة وظهور التأثير على الشاشة؟
- مدة الوقت المطلوبة لإجراء العمليات الأطول (مثل فتح التطبيقات)
الأول أكثر وضوحًا من الثاني. عادةً ما يلاحظ المستخدمون التشويش، ولكن لن يتمكّنوا من التمييز بين وقت بدء تشغيل التطبيق الذي يبلغ 500 مللي ثانية ووقت بدء التشغيل الذي يبلغ 600 مللي ثانية إلا إذا كانوا ينظرون إلى جهازَين جنبًا إلى جنب. يمكن ملاحظة تأخُّر الاستجابة للمس على الفور، وهو يؤثّر بشكل كبير في تجربة استخدام الجهاز.
نتيجةً لذلك، في الأجهزة السريعة، تكون سلسلة نقل بيانات واجهة المستخدم هي الأهم في النظام، باستثناء ما هو ضروري للحفاظ على عمل سلسلة نقل بيانات واجهة المستخدم. وهذا يعني أنّ مسار عرض واجهة المستخدم يجب أن يسبق أي عمل آخر غير ضروري لعرض واجهة مستخدم سلسة. للحفاظ على سلاسة واجهة المستخدم، يجب تأخير المزامنة في الخلفية وعرض الإشعارات والمهام المشابهة إذا كان من الممكن تنفيذ مهام واجهة المستخدم. من المقبول التضحية بأداء العمليات الأطول (وقت تشغيل HDR+، وبدء تشغيل التطبيق، وما إلى ذلك) للحفاظ على سلاسة واجهة المستخدم.
السعة مقابل التشويش
عند التفكير في أداء الجهاز، يُعدّ السعة والارتعاش مقياسَين مهمَّين.
السعة
السعة هي إجمالي مقدار أحد الموارد التي يمتلكها الجهاز خلال فترة زمنية معيّنة. يمكن أن تكون هذه الموارد موارد وحدة المعالجة المركزية أو وحدة معالجة الرسومات أو موارد الإدخال/الإخراج أو موارد الشبكة أو معدل نقل البيانات للذاكرة أو أي مقياس مشابه. عند فحص أداء النظام بأكمله، قد يكون من المفيد تجريد المكوّنات الفردية وافتراض مقياس واحد يحدّد الأداء (خاصةً عند ضبط جهاز جديد لأنّ أحمال العمل التي يتم تشغيلها على هذا الجهاز من المحتمل أن تكون ثابتة).
تختلف سعة النظام استنادًا إلى موارد الحوسبة المتاحة على الإنترنت. يُعد تغيير سرعة وحدة المعالجة المركزية (CPU) أو وحدة معالجة الرسومات (GPU) الوسيلة الأساسية لتغيير السعة، ولكن هناك وسائل أخرى، مثل تغيير عدد نوى وحدة المعالجة المركزية المتاحة. وبناءً على ذلك، تتوافق سعة النظام مع استهلاك الطاقة، ويؤدي تغيير السعة دائمًا إلى تغيير مماثل في استهلاك الطاقة.
يتم تحديد السعة المطلوبة في وقت معيّن بشكل كبير من خلال التطبيق قيد التشغيل. ونتيجةً لذلك، لا يمكن للنظام الأساسي إجراء الكثير لتعديل السعة المطلوبة لعبء عمل معيّن، وتقتصر وسائل إجراء ذلك على تحسينات وقت التشغيل (إطار عمل 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 في العالم الحقيقي ما يلي:
- مهلة المجدوِل
- معالجات المقاطعة
- تشغيل رمز برنامج التشغيل لفترة طويلة جدًا مع إيقاف ميزة الأولوية أو المقاطعات
- Long-running softirqs
- تزايد الطلب على دالة الاستبعاد المتبادل (التطبيق، وإطار العمل، وبرنامج تشغيل النواة، وقفل Binder، وقفل mmap)
- تضارب واصفات الملفات حيث يحتفظ مؤشر ترابط منخفض الأولوية بقفل على ملف، ما يمنع مؤشر ترابط عالي الأولوية من التشغيل
- تشغيل الرمز البرمجي المهم لواجهة المستخدم في قوائم انتظار العمل حيث يمكن تأخيره
- انتقالات وحدة المعالجة المركزية (CPU) غير النشطة
- التسجيل
- تأخيرات I/O
- إنشاء عمليات غير ضرورية (مثل عمليات البث
CONNECTIVITY_CHANGE) - حدوث تدهور في أداء ذاكرة التخزين المؤقت للصفحات بسبب عدم توفّر مساحة كافية في الذاكرة
قد تنخفض المدة الزمنية المطلوبة لفترة زمنية معيّنة من التفاوت في وقت الوصول أو لا تنخفض مع زيادة السعة. على سبيل المثال، إذا ترك برنامج التشغيل المقاطعات غير مفعّلة أثناء انتظار القراءة من خلال ناقل i2c، سيستغرق ذلك مقدارًا ثابتًا من الوقت بغض النظر عما إذا كانت وحدة المعالجة المركزية تعمل بسرعة 384 ميغاهرتز أو 2 غيغاهرتز. زيادة السعة ليس حلاً مجديًا لتحسين الأداء عند حدوث تفاوت زمني. نتيجةً لذلك، لن تؤدي المعالِجات الأسرع عادةً إلى تحسين الأداء في الحالات التي يكون فيها التفاوت الزمني محدودًا.
أخيرًا، على عكس السعة، يقع عدم الاستقرار بالكامل تقريبًا ضمن نطاق مورّد النظام.
استهلاك الذاكرة
يُعزى ضعف الأداء عادةً إلى استهلاك الذاكرة. مع أنّ الاستهلاك بحد ذاته ليس مشكلة في الأداء، إلا أنّه قد يتسبب في حدوث تشويش بسبب الحمل الزائد الذي تفرضه أداة lowmemorykiller، وإعادة تشغيل الخدمات، وإفراط في استخدام ذاكرة التخزين المؤقت للصفحات. يمكن أن يؤدي تقليل استهلاك الذاكرة إلى تجنُّب الأسباب المباشرة لانخفاض الأداء، ولكن قد تكون هناك تحسينات مستهدَفة أخرى تتجنّب هذه الأسباب أيضًا (على سبيل المثال، تثبيت الإطار لمنعه من الانتقال إلى الذاكرة الافتراضية عندما سيتم نقله إليها بعد فترة وجيزة).
تحليل الأداء الأوّلي للجهاز
إنّ البدء بنظام يعمل بشكل جيد ولكن أدائه ضعيف ومحاولة إصلاح سلوك النظام من خلال النظر إلى حالات فردية من الأداء الضعيف الذي يلاحظه المستخدم ليس استراتيجية سليمة. وبما أنّ الأداء الضعيف لا يمكن عادةً إعادة إنتاجه بسهولة (أي التشويش) أو أنّه يرجع إلى مشكلة في التطبيق، فإنّ العدد الكبير جدًا من المتغيرات في النظام الكامل يمنع فعالية هذه الاستراتيجية. نتيجةً لذلك، من السهل جدًا تحديد الأسباب بشكل خاطئ وإجراء تحسينات طفيفة مع تفويت فرص منهجية لإصلاح الأداء على مستوى النظام.
بدلاً من ذلك، اتّبِع الأسلوب العام التالي عند إعداد جهاز جديد:
- اجعل النظام يبدأ التشغيل إلى واجهة المستخدم مع تشغيل جميع برامج التشغيل وبعض إعدادات حاكم التردد الأساسية (في حال تغيير إعدادات حاكم التردد، كرِّر جميع الخطوات أدناه).
- تأكَّد من أنّ النواة تتوافق مع نقطة التتبُّع
sched_blocked_reason، بالإضافة إلى نقاط التتبُّع الأخرى في مسار عرض الشاشة التي تشير إلى وقت تسليم الإطار إلى الشاشة. - تسجيل عمليات تتبُّع طويلة لمسار عرض واجهة المستخدم بالكامل (بدءًا من تلقّي الإدخال عبر طلب مقاطعة (IRQ) وصولاً إلى عملية المسح النهائية) أثناء تنفيذ عبء عمل خفيف ومتسق (على سبيل المثال، UiBench أو اختبار الكرة في TouchLatency).
- عليك إصلاح حالات انخفاض عدد اللقطات التي تم رصدها في أحمال العمل الخفيفة والمتسقة.
- كرِّر الخطوات من 3 إلى 4 إلى أن تتمكّن من التسجيل بدون أي لقطات تم إسقاطها لمدة 20 ثانية أو أكثر في المرة الواحدة.
- انتقِل إلى مصادر أخرى مرئية للمستخدمين تؤدي إلى حدوث بطء.
تشمل الإجراءات البسيطة الأخرى التي يمكنك اتّخاذها في المراحل الأولى من إعداد الجهاز ما يلي:
- تأكَّد من أنّ النواة تتضمّن تصحيح sched_blocked_reason لنقطة التتبُّع. يتم تفعيل نقطة التتبُّع هذه باستخدام فئة تتبُّع الجدولة في systrace، وتوفّر الدالة المسؤولة عن وضع السكون عندما يدخل هذا مؤشر الترابط في وضع السكون غير القابل للمقاطعة. وهو أمر بالغ الأهمية لتحليل الأداء، لأنّ النوم غير المتقطّع هو مؤشر شائع جدًا على التفاوت.
- تأكَّد من توفّر عمليات تتبُّع كافية لخطوط أنابيب وحدة معالجة الرسومات والعرض. في أحدث أنظمة Qualcomm على الرقاقة، يتم تفعيل نقاط التتبُّع باستخدام:
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 باختلاف مماثل في أداء واجهة المستخدم الملحوظ (عدد اللقطات التي تم إسقاطها، ووقت اللقطة في الشريحة المئوية الـ 99، وما إلى ذلك). مقاييس الأداء الاصطناعية هي مقاييس أداء خاصة بالسعة فقط، ويؤثر التفاوت في التوقيت في الأداء المقاس لهذه المقاييس فقط من خلال استقطاع الوقت من عملية التشغيل المجمّع للمقياس. ونتيجةً لذلك، تكون نتائج قياس الأداء الاصطناعية غير ذات صلة في الغالب كمقياس للأداء الذي يلاحظه المستخدم.
لنفترض أنّ هناك شريحتَي نظام على لوحة واحدة (SOC) تعملان على تشغيل Benchmark X الذي يعرض 1,000 لقطة من واجهة المستخدم ويُبلغ عن إجمالي وقت العرض (كلما كانت النتيجة أقل، كان ذلك أفضل).
- تعرض شهادة SOC 1 كل إطار من Benchmark X في 10 مللي ثانية وتحصل على 10,000 نقطة.
- تعرض SOC 2% 99 من اللقطات في 1 ملّي ثانية، ولكن% 1 من اللقطات في 100 ملّي ثانية، وتحصل على النتيجة 19,900، وهي نتيجة أفضل بكثير.
إذا كان مقياس الأداء يشير إلى أداء واجهة المستخدم الفعلي، لن يكون SOC 2 قابلاً للاستخدام. بافتراض معدّل تحديث يبلغ 60 هرتز، سيحدث إطار متقطّع في SOC 2 كل 1.5 ثانية من التشغيل. في المقابل، سيكون SOC 1 (الأبطأ وفقًا لـ Benchmark X) سلسًا تمامًا.
استخدام تقارير الأخطاء
تكون تقارير الأخطاء مفيدة أحيانًا لتحليل الأداء، ولكن نظرًا لأنّها تتضمّن الكثير من البيانات، نادرًا ما تكون مفيدة لتصحيح أخطاء مشاكل التشويش المتقطّع. وقد تقدّم بعض التلميحات حول ما كان يفعله النظام في وقت معيّن، خاصةً إذا كان التشويش مرتبطًا بانتقال التطبيق (الذي يتم تسجيله في تقرير خطأ). يمكن أن تشير تقارير الأخطاء أيضًا إلى حدوث مشكلة على نطاق أوسع في النظام قد تؤدي إلى خفض سعته الفعالة (مثل الحد من سرعة المعالج بسبب ارتفاع درجة الحرارة أو تجزئة الذاكرة).
استخدام TouchLatency
تأتي عدة أمثلة على السلوك السيئ من TouchLatency، وهو عبء العمل الدوري المفضّل المستخدَم في Pixel وPixel XL. يمكنك الوصول إلى هذه الأداة من خلال الرابط frameworks/base/tests/TouchLatency، وهي تتضمّن وضعَين: وقت استجابة اللمس وكرة مرتدة (للتبديل بين الوضعَين، انقر على الزرّ في أعلى يسار الصفحة).
اختبار الكرة النطاطة بسيط تمامًا كما يبدو: ترتد الكرة على الشاشة إلى الأبد، بغض النظر عن إدخال المستخدم. وعادةً ما يكون هذا الاختبار الأصعب على الإطلاق من حيث إجرائه بشكل مثالي، ولكن كلما اقترب من إجرائه بدون أي لقطات تم إسقاطها، كان أداء جهازك أفضل. يصعب إجراء اختبار الكرة المرتدة لأنّه عبارة عن عبء عمل بسيط ولكن متسق تمامًا يتم تنفيذه بسرعة منخفضة جدًا (يفترض ذلك أنّ الجهاز يتضمّن أداة تحكّم في التردد؛ وإذا كان الجهاز يعمل بترددات ثابتة، يجب خفض تردد وحدة المعالجة المركزية/وحدة معالجة الرسومات إلى الحد الأدنى تقريبًا عند إجراء اختبار الكرة المرتدة للمرة الأولى). مع توقّف النظام عن العمل وانخفاض سرعة المعالجة إلى مستوى قريب من وضع الخمول، يزداد وقت وحدة المعالجة المركزية/وحدة معالجة الرسومات المطلوب لكل إطار. يمكنك مشاهدة الكرة وملاحظة حدوث تشوّش، كما يمكنك أيضًا ملاحظة الإطارات التي لم يتم عرضها في systrace.
وبما أنّ عبء العمل ثابت جدًا، يمكنك تحديد معظم مصادر التشويش بسهولة أكبر بكثير من معظم أحمال العمل المرئية للمستخدمين، وذلك من خلال تتبُّع ما يتم تشغيله بالضبط على النظام أثناء كل إطار تم تفويته بدلاً من مسار واجهة المستخدم. تؤدي معدلات نقل البيانات المنخفضة إلى تضخيم تأثيرات التشويش، ما يزيد من احتمال أن يؤدي أي تشويش إلى حذف إطار. نتيجةً لذلك، كلما اقترب TouchLatency من 60 لقطة في الثانية، قلّت احتمالية حدوث سلوكيات سيئة في النظام تؤدي إلى حدوث تشوّش متقطع يصعب إعادة إنتاجه في التطبيقات الأكبر حجمًا.
بما أنّ التفاوت الزمني غالبًا (وليس دائمًا) لا يتأثر بسرعة الساعة، استخدِم اختبارًا يعمل بسرعات ساعة منخفضة جدًا لتشخيص التفاوت الزمني للأسباب التالية:
- ولا يكون كل التشويش ثابتًا بغض النظر عن سرعة الساعة، بل تستهلك العديد من المصادر وقت وحدة المعالجة المركزية.
- يجب أن يحصل نظام التشغيل على متوسط وقت عرض اللقطة بالقرب من الموعد النهائي من خلال خفض سرعة المعالجة، وبالتالي يمكن أن يؤدي الوقت المستغرَق في تنفيذ مهام غير مرتبطة بواجهة المستخدم إلى تجاوز الموعد النهائي وعرض لقطة غير مكتملة.