تقييم الأداء

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

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

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

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

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

القدرة مقابل غضب

عند النظر في أداء الجهاز، فإن السعة والارتعاش هما مقياسان مهمان.

سعة

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

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

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

تقطع

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

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

تتضمن مصادر الارتعاش التي تحدث في تطبيقات Android الواقعية ما يلي:

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

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

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

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

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

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

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

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

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

تشمل الأشياء البسيطة الأخرى التي يمكنك القيام بها مبكرًا عند إظهار الجهاز ما يلي:

  • تأكد من أن النواة لديك تحتوي على تصحيح نقطة التتبع sched_blocked_reason . يتم تمكين نقطة التتبع هذه باستخدام فئة التتبع المجدول في 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، لن ترى أي معلومات إضافية حول وحدة معالجة الرسومات في طريقة عرض systrace القياسية، ولكن النتائج موجودة في التتبع نفسه (لمزيد من التفاصيل، راجع فهم systrace ).

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

باستخدام المعايير الاصطناعية

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

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

ضع في اعتبارك شركتي SOC تقومان بتشغيل 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 الأبطأ وفقًا للمعيار X) سيكون سلسًا تمامًا.

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

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

باستخدام TouchLatency

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

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

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

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

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