تقييم الأداء

استخدم Simpleperf لتقييم أداء الجهاز. Simpleperf هي أداة إنشاء ملفات تعريف أصلية لكل من التطبيقات والعمليات الأصلية على Android. استخدم ملف تعريف وحدة المعالجة المركزية لفحص استخدام وحدة المعالجة المركزية للتطبيق ونشاط مؤشر الترابط في الوقت الفعلي.

هناك نوعان من مؤشرات الأداء المرئية للمستخدم:

  • أداء ملموس يمكن التنبؤ به . هل تقوم واجهة المستخدم (UI) بإسقاط الإطارات أو عرضها باستمرار بمعدل 60 إطارًا في الثانية؟ هل يتم تشغيل الصوت بدون قطع أثرية أو فرقعة؟ ما هي المدة الزمنية بين لمس المستخدم الشاشة والتأثير الذي يظهر على الشاشة؟
  • طول الوقت المطلوب لعمليات أطول (مثل فتح التطبيقات).

الأول ملحوظ أكثر من الثاني. عادة ما يلاحظ المستخدمون وجود مشكلة ولكنهم لن يكونوا قادرين على معرفة وقت بدء تشغيل التطبيق 500 مللي ثانية مقابل 600 مللي ثانية ما لم ينظروا إلى جهازين جنبًا إلى جنب. يمكن ملاحظة زمن انتقال اللمس على الفور ويساهم بشكل كبير في إدراك الجهاز.

نتيجة لذلك ، في جهاز سريع ، يعد خط أنابيب واجهة المستخدم أهم شيء في النظام بخلاف ما هو ضروري للحفاظ على عمل خط أنابيب واجهة المستخدم. هذا يعني أن خط أنابيب واجهة المستخدم يجب أن يستبق أي عمل آخر غير ضروري لواجهة المستخدم السائلة. للحفاظ على واجهة مستخدم سلسة ، يجب تأجيل مزامنة الخلفية وتسليم الإشعارات والعمل المماثل إذا كان من الممكن تشغيل عمل واجهة المستخدم. من المقبول تداول أداء عمليات أطول (وقت تشغيل + HDR ، بدء تشغيل التطبيق ، وما إلى ذلك) للحفاظ على واجهة مستخدم سلسة.

القدرة مقابل الارتعاش

عند التفكير في أداء الجهاز ، تعتبر السعة وعدم الاستقرار مقياسين ذا مغزى.

الاهلية

السعة هي المقدار الإجمالي لبعض الموارد التي يمتلكها الجهاز خلال فترة زمنية معينة. يمكن أن يكون هذا موارد وحدة المعالجة المركزية ، أو موارد وحدة معالجة الرسومات ، أو موارد الإدخال / الإخراج ، أو موارد الشبكة ، أو عرض النطاق الترددي للذاكرة ، أو أي مقياس مشابه. عند فحص أداء النظام بالكامل ، قد يكون من المفيد تجريد المكونات الفردية وافتراض مقياس واحد يحدد الأداء (خاصة عند ضبط جهاز جديد لأن أحمال العمل التي يتم تشغيلها على هذا الجهاز من المحتمل أن تكون ثابتة).

تختلف قدرة النظام بناءً على موارد الحوسبة عبر الإنترنت. يعد تغيير تردد وحدة المعالجة المركزية / وحدة معالجة الرسومات الوسيلة الأساسية لتغيير السعة ، ولكن هناك وسائل أخرى مثل تغيير عدد أنوية وحدة المعالجة المركزية عبر الإنترنت. وفقًا لذلك ، تتوافق سعة النظام مع استهلاك الطاقة ؛ يؤدي تغيير السعة دائمًا إلى تغيير مماثل في استهلاك الطاقة.

يتم تحديد السعة المطلوبة في وقت معين بشكل كبير من خلال التطبيق قيد التشغيل. نتيجة لذلك ، لا يمكن للنظام الأساسي فعل الكثير لضبط السعة المطلوبة لحمل عمل معين ، ووسائل القيام بذلك تقتصر على تحسينات وقت التشغيل (إطار عمل Android ، ART ، Bionic ، برنامج التحويل البرمجي / برامج تشغيل GPU ، kernel).

تقطع

في حين أنه من السهل رؤية السعة المطلوبة لأعباء العمل ، فإن الارتعاش هو مفهوم أكثر غموضًا. للحصول على مقدمة جيدة للاهتزاز كعائق أمام الأنظمة السريعة ، ارجع إلى حالة فقدان أداء الكمبيوتر الفائق: تحقيق الأداء الأمثل على 8192 معالجًا لـ ASCl Q. (إنه تحقيق في سبب عدم تحقيق الكمبيوتر الفائق ASCI Q للأداء المتوقع وهو مقدمة رائعة لتحسين الأنظمة الكبيرة.)

تستخدم هذه الصفحة مصطلح jitter لوصف ما تسميه ورقة ASCI Q ضوضاء . الارتعاش هو سلوك النظام العشوائي الذي يمنع العمل الملموس من العمل. غالبًا ما يكون العمل الذي يجب تشغيله ، ولكن قد لا يكون لديه متطلبات توقيت صارمة تجعله يعمل في أي وقت معين. نظرًا لأنه عشوائي ، من الصعب للغاية دحض وجود الارتعاش بسبب عبء عمل معين. كما أنه من الصعب للغاية إثبات أن مصدرًا معروفًا للاهتزاز كان سبب مشكلة أداء معينة. يمكن للأدوات الأكثر شيوعًا لتشخيص أسباب الاهتزاز (مثل التتبع أو التسجيل) أن تؤدي إلى حدوث اهتزازات خاصة بها.

تتضمن مصادر الارتعاش التي تمت تجربتها في تطبيقات العالم الحقيقي لنظام Android ما يلي:

  • تأخير المجدول
  • معالجات المقاطعة
  • يعمل رمز برنامج التشغيل لفترة طويلة جدًا مع تعطيل الإجراءات الاستباقية أو المقاطعات
  • برامج طويلة الأمد
  • تنازع القفل (التطبيق ، الإطار ، برنامج تشغيل النواة ، قفل الموثق ، قفل mmap)
  • تنازع واصف الملف حيث يحتفظ مؤشر ترابط ذو أولوية منخفضة بقفل الملف ، مما يمنع تشغيل مؤشر ترابط ذي أولوية عالية
  • تشغيل التعليمات البرمجية لواجهة المستخدم الحرجة في قوائم قوائم العمل حيث يمكن أن تتأخر
  • انتقالات خمول وحدة المعالجة المركزية
  • تسجيل
  • تأخيرات I / O
  • إنشاء عملية غير ضرورية (على سبيل المثال ، عمليات البث CONNECTIVITY_CHANGE)
  • تحطم ذاكرة التخزين المؤقت للصفحة بسبب عدم كفاية الذاكرة الخالية

قد ينخفض ​​أو لا ينخفض ​​مقدار الوقت المطلوب لفترة معينة من الاهتزاز مع زيادة السعة. على سبيل المثال ، إذا ترك برنامج التشغيل المقاطعات معطلة أثناء انتظار القراءة من عبر ناقل i2c ، فسوف يستغرق الأمر مقدارًا ثابتًا من الوقت بغض النظر عما إذا كانت وحدة المعالجة المركزية عند 384 ميجاهرتز أو 2 جيجاهرتز. إن زيادة السعة ليست حلاً ممكنًا لتحسين الأداء عند وجود توتر. نتيجة لذلك ، لن تعمل المعالجات الأسرع عادةً على تحسين الأداء في المواقف التي تقيدها الاهتزازات.

أخيرًا ، على عكس السعة ، فإن الارتعاش يكون بالكامل تقريبًا ضمن مجال بائع النظام.

استهلاك الذاكرة

عادة ما يتم إلقاء اللوم على استهلاك الذاكرة لضعف الأداء. على الرغم من أن الاستهلاك في حد ذاته لا يمثل مشكلة في الأداء ، إلا أنه قد يتسبب في حدوث تذبذب بسبب الحمل المنخفض للذاكرة وإعادة تشغيل الخدمة وتحطم ذاكرة التخزين المؤقت للصفحة. يمكن أن يؤدي تقليل استهلاك الذاكرة إلى تجنب الأسباب المباشرة لضعف الأداء ، ولكن قد تكون هناك تحسينات أخرى مستهدفة تتجنب هذه الأسباب أيضًا (على سبيل المثال ، تثبيت إطار العمل لمنعه من الترحيل إلى صفحاته عندما يتم ترحيله بعد فترة وجيزة).

تحليل الأداء الأولي للجهاز

إن البدء من نظام وظيفي ولكن ضعيف الأداء ومحاولة إصلاح سلوك النظام من خلال النظر في الحالات الفردية للأداء الضعيف المرئي للمستخدم ليست استراتيجية سليمة. نظرًا لأن الأداء الضعيف عادةً لا يكون قابلاً للتكرار بسهولة (على سبيل المثال ، تذبذب) أو مشكلة في التطبيق ، فإن العديد من المتغيرات في النظام الكامل تمنع هذه الإستراتيجية من أن تكون فعالة. نتيجة لذلك ، من السهل جدًا تحديد الأسباب بشكل خاطئ وإجراء تحسينات طفيفة مع فقدان الفرص النظامية لإصلاح الأداء عبر النظام.

بدلاً من ذلك ، استخدم النهج العام التالي عند إحضار جهاز جديد:

  1. احصل على تمهيد النظام لواجهة المستخدم مع تشغيل جميع برامج التشغيل وبعض إعدادات حاكم التردد الأساسية (إذا قمت بتغيير إعدادات حاكم التردد ، كرر جميع الخطوات أدناه).
  2. تأكد من أن النواة تدعم نقطة sched_blocked_reason بالإضافة إلى نقاط التتبع الأخرى في خط أنابيب العرض التي تشير إلى وقت تسليم الإطار إلى الشاشة.
  3. خذ آثارًا طويلة لخط أنابيب واجهة المستخدم بالكامل (من تلقي المدخلات عبر IRQ إلى المسح النهائي) أثناء تشغيل عبء عمل خفيف الوزن ومتسق (على سبيل المثال ، UiBench أو اختبار الكرة في TouchLatency) .
  4. إصلاح قطرات الإطار المكتشفة في عبء العمل الخفيف والمتسق.
  5. كرر الخطوات من 3 إلى 4 حتى تتمكن من تشغيل بدون إطارات مسقطة لمدة تزيد عن 20 ثانية في المرة الواحدة.
  6. انتقل إلى مصادر المخادعة الأخرى المرئية للمستخدم.

تشمل الأشياء البسيطة الأخرى التي يمكنك القيام بها في وقت مبكر في إحضار الجهاز ما يلي:

  • تأكد من أن النواة الخاصة بك لديها التصحيح Schedule_blocked_reason tracepoint . يتم تمكين نقطة التتبع هذه مع فئة تتبع الجدولة في نظام systrace وتوفر الوظيفة المسؤولة عن السكون عندما يدخل هذا الخيط في وضع السكون غير المنقطع. إنه أمر بالغ الأهمية لتحليل الأداء لأن النوم غير المتقطع مؤشر شائع جدًا على الارتعاش.
  • تأكد من أن لديك ما يكفي من التتبع لوحدة معالجة الرسومات وعرض خطوط الأنابيب. في Qualcomm SOCs الأخيرة ، تم تمكين نقاط التتبع باستخدام:
  • adb shell "echo 1 > /d/tracing/events/kgsl/enable"
    adb shell "echo 1 > /d/tracing/events/mdss/enable"
    

    تظل هذه الأحداث ممكّنة عند تشغيل systrace حتى تتمكن من رؤية معلومات إضافية في التتبع حول خط أنابيب العرض (MDSS) في قسم mdss_fb0 . في Qualcomm SOCs ، لن ترى أي معلومات إضافية حول GPU في عرض النظام القياسي ، ولكن النتائج موجودة في التتبع نفسه (للحصول على التفاصيل ، راجع فهم النظام ).

    ما تريده من هذا النوع من تتبع العرض هو حدث واحد يشير مباشرة إلى أن الإطار قد تم تسليمه إلى الشاشة. من هناك ، يمكنك تحديد ما إذا كنت قد وصلت إلى الإطار الزمني الخاص بك بنجاح ؛ إذا حدث الحدث X n في أقل من 16.7 مللي ثانية بعد الحدث X n-1 (بافتراض عرض 60 هرتز) ، فأنت تعلم أنك لم تكن مزعجًا. إذا لم تقدم SOC الخاص بك مثل هذه الإشارات ، فاعمل مع البائع للحصول عليها. يعد تصحيح الارتعاش أمرًا صعبًا للغاية بدون إشارة محددة لإكمال الإطار.

استخدام معايير تركيبية

تعد المعايير التركيبية مفيدة لضمان وجود الوظائف الأساسية للجهاز. ومع ذلك ، فإن التعامل مع المعايير كبديل لأداء الجهاز المتصور ليس مفيدًا.

استنادًا إلى التجارب مع SOCs ، لا ترتبط الاختلافات في الأداء المعياري التركيبي بين SOCs باختلاف مماثل في أداء واجهة المستخدم الملموس (عدد الإطارات التي تم إسقاطها ، ووقت الإطار المئوي 99 ، وما إلى ذلك). المعايير الاصطناعية هي معايير مرجعية للقدرة فقط ؛ يؤثر الارتعاش على الأداء المقاس لهذه المعايير فقط عن طريق سرقة الوقت من التشغيل بالجملة للمعيار. نتيجةً لذلك ، فإن النتائج المعيارية التركيبية غالبًا ما تكون غير ذات صلة كمقياس للأداء الذي يدركه المستخدم.

ضع في اعتبارك وجود اثنين من SOCs يعملان على Benchmark X والذي يعرض 1000 إطار من واجهة المستخدم ويبلغ عن إجمالي وقت العرض (الدرجة الأقل أفضل).

  • يعرض SOC 1 كل إطار من Benchmark X في 10 مللي ثانية ويسجل 10000 نقطة.
  • يعرض SOC 2 99٪ من الإطارات في 1 مللي ثانية ولكن 1٪ من الإطارات في 100 مللي ثانية ويسجل 19،900 ، وهي نتيجة أفضل بشكل كبير.

إذا كان المعيار يشير إلى أداء واجهة المستخدم الفعلي ، فسيكون SOC 2 غير قابل للاستخدام. بافتراض معدل تحديث 60 هرتز ، سيكون لدى SOC 2 إطار رائع كل 1.5 ثانية من التشغيل. وفي الوقت نفسه ، سيكون SOC 1 (SOC الأبطأ وفقًا لـ Benchmark X) سائلاً تمامًا.

استخدام تقارير الأخطاء

أحيانًا تكون تقارير الأخطاء مفيدة لتحليل الأداء ، ولكن نظرًا لكونها ثقيلة الوزن ، فنادراً ما تكون مفيدة لتصحيح مشكلات الرسائل غير المرغوب فيها المتفرقة. قد يقدمون بعض التلميحات حول ما كان يفعله النظام في وقت معين ، خاصةً إذا كانت المشكلة غير المرغوب فيها تتعلق بانتقال تطبيق (يتم تسجيله في تقرير خطأ). يمكن أن تشير تقارير الأخطاء أيضًا إلى وجود خطأ ما في النظام بشكل عام مما قد يقلل من قدرته الفعالة (مثل الاختناق الحراري أو تجزئة الذاكرة).

باستخدام TouchLatency

تأتي العديد من الأمثلة على السلوك السيئ من TouchLatency ، وهو عبء العمل الدوري المفضل المستخدم في Pixel و Pixel XL. إنه متاح في frameworks/base/tests/TouchLatency وله وضعان: زمن اللمس والكرة المرتدة (للتبديل بين الأوضاع ، انقر فوق الزر في الزاوية العلوية اليمنى).

اختبار الكرة المرتدة بسيط تمامًا كما يبدو: ترتد الكرة حول الشاشة إلى الأبد ، بغض النظر عن مدخلات المستخدم. عادةً ما يكون أيضًا أصعب اختبار للتشغيل بشكل مثالي ، ولكن كلما اقترب من العمل بدون أي إطارات متساقطة ، كان جهازك أفضل. اختبار الكرة المرتدة صعب لأنه عبء عمل تافه ولكنه متسق تمامًا يتم تشغيله في ساعة منخفضة جدًا (يفترض هذا أن الجهاز به حاكم تردد ؛ إذا كان الجهاز يعمل بدلاً من ذلك بساعات ثابتة ، فقم بإلغاء قفل وحدة المعالجة المركزية / وحدة معالجة الرسومات إلى الحد الأدنى تقريبًا عند إجراء اختبار الكرة المرتدة لأول مرة). مع توقف النظام وانخفاض الساعات أقرب إلى الخمول ، يزداد الوقت المطلوب لوحدة المعالجة المركزية / وحدة معالجة الرسومات لكل إطار. يمكنك مشاهدة الكرة ورؤية الأشياء غير المرغوب فيها ، وستكون قادرًا على رؤية الإطارات المفقودة في النظام أيضًا.

نظرًا لأن عبء العمل متسق للغاية ، يمكنك تحديد معظم مصادر عدم الاستقرار بسهولة أكبر من معظم أحمال العمل المرئية للمستخدم عن طريق تتبع ما يتم تشغيله بالضبط على النظام أثناء كل إطار مفقود بدلاً من خط أنابيب واجهة المستخدم. تعمل الساعات السفلية على تضخيم تأثيرات الارتعاش من خلال زيادة احتمالية تسبب أي ارتعاش في سقوط الإطار. نتيجة لذلك ، كلما كان TouchLatency أقرب إلى 60 إطارًا في الثانية ، قل احتمال تعرضك لسلوكيات نظام سيئة تتسبب في حدوث أخطاء متفرقة يصعب إعادة إنتاجها في التطبيقات الأكبر حجمًا.

نظرًا لأن الارتعاش غالبًا (ولكن ليس دائمًا) ثابت على مدار الساعة ، استخدم اختبارًا يتم تشغيله في ساعات منخفضة جدًا لتشخيص الارتعاش للأسباب التالية:

  • ليست كل حالات الارتعاش غير ثابتة على مدار الساعة ؛ العديد من المصادر تستهلك فقط وقت وحدة المعالجة المركزية.
  • يجب أن يحصل الحاكم على متوسط ​​وقت الإطار قريبًا من الموعد النهائي عن طريق تسجيل الوقت ، لذا فإن الوقت الذي يتم قضاؤه في تشغيل عمل غير متعلق بواجهة المستخدم يمكن أن يدفعه إلى الحافة لإسقاط إطار.