استخدام Simpleperf لتقييم أداء الجهاز. Simpleperf هي أداة تحليلية أصلية لكليهما وتطبيقات وعمليات أصلية على Android. استخدام أداة تحليل وحدة المعالجة المركزية (CPU) لفحص استخدام وحدة المعالجة المركزية (CPU) داخل التطبيق ونشاط سلاسل المحادثات في الوقت الفعلي.
هناك مؤشران للأداء مرئي للمستخدمين:
- الأداء المتوقّع والمتوقّع: هل يدرك المستخدم في واجهة المستخدم (UI) التي تجتاز الإطارات أو يتم عرضها باستمرار بمعدّل 60 لقطة في الثانية؟ هل يتم تشغيل الصوت؟ بدون العناصر أو الفرق؟ مدة التأخير بين لمس المستخدم الشاشة والتأثير الذي يظهر على الشاشة؟
- طول المدة الزمنية المطلوبة للعمليات الأطول (مثل فتح التطبيقات).
الأولى أكثر وضوحًا من الثانية. يلاحظ المستخدمون عادةً انقطاعات في الخدمة لكن لن تتمكن من تحديد مدة بدء تشغيل التطبيق بين 500 ملي ثانية و600 ملي ثانية ما لم إنّهما ينظران إلى جهازَين جنبًا إلى جنب. وقت استجابة اللمس على الفور ويساهم بشكل كبير في تصور الجهاز.
ونتيجة لذلك، في الأجهزة السريعة، يعد مسار واجهة المستخدم هو الشيء الأكثر أهمية في النظام بخلاف ما هو ضروري للحفاظ على عمل مسار واجهة المستخدم. هذا النمط أن مسار واجهة المستخدم يجب أن يقبل بشكل استباقي أي عمل آخر غير ضروري للحصول على واجهة مستخدم مرنة. للحفاظ على سلاسة واجهة المستخدم، أو المزامنة في الخلفية، أو عرض الإشعارات، وأي عمل مشابه يجب أن يتأخر إذا كان من الممكن تشغيل عمل واجهة المستخدم. من المهم أن يستبدل أداء العمليات الأطول مدة (وقت تشغيل HDR+ ، أو بدء تشغيل التطبيق أو غير ذلك) للحفاظ على سلاسة واجهة المستخدم.
السعة مقابل عدم الاستقرار
عند التفكير في أداء الجهاز، السعة وعدم الاستقرار هما مقياسان مفيدان.
السعة
السعة هي إجمالي مقدار بعض الموارد التي يمتلكها الجهاز قدرًا من الوقت. قد تشمل موارد وحدة المعالجة المركزية (CPU) وموارد وحدة معالجة الرسومات وموارد وحدات الإدخال والإخراج موارد الشبكة أو معدل نقل بيانات الذاكرة أو أي مقياس مشابه. عند فحص أداء النظام بأكمله، قد يكون من المفيد استخلاص الأجزاء الفردية ونفترض مقياسًا واحدًا يحدّد الأداء (خاصةً عند ضبط جهاز جديد لأنه من المحتمل أن تكون أعباء العمل التي تعمل على هذا الجهاز قد تم إصلاحها).
تختلف قدرة النظام بناءً على موارد الحوسبة عبر الإنترنت. يعد تغيير تردّد وحدة المعالجة المركزية (CPU)/وحدة معالجة الرسومات الوسيلة الأساسية لتغيير السعة، ولكن هناك وغيرها من الميزات مثل تغيير عدد نوى وحدة المعالجة المركزية (CPU) عبر الإنترنت. وبالتالي، تتجاوب قدرة النظام مع استهلاك الطاقة؛ تغيير السعة إلى تغيير مماثل في استهلاك الطاقة.
يتم تحديد القدرة المطلوبة في وقت معين بشكل كبير من قبل قيد التشغيل. نتيجةً لذلك، لا يمكن للنظام الأساسي فعل الكثير من أجل ضبط القدرة المطلوبة لأعباء عمل معينة، وتقتصر الوسائل اللازمة لذلك التحسينات في وقت التشغيل (إطار عمل Android وART وBIonic وبرنامج التجميع/برامج التشغيل لوحدة معالجة الرسومات kernel).
غير مستقر
وفي حين أنه من السهل رؤية القدرة المطلوبة لأعباء العمل، فإن عدم الاستقرار هو مفهوم غامض. للحصول على مقدمة جيدة عن التوتر كعائق للصيام الأنظمة، يشير إلى حالة ضعف الأداء في مجال الحوسبة الفائقة: تحقيق الأداء الأمثل في عدد معالجات ASCl Q البالغ 8,192 معالجًا. (إنه تحقيق في سبب وضع ASCI لم يحقق جهاز الكمبيوتر الخارق Q أداءه المتوقع، وهو الآن مقدمة لتحسين الأنظمة الكبيرة).
تستخدم هذه الصفحة مصطلح "عدم الاستقرار" لوصف ما تقوله صحيفة ASCI Q. الضوضاء. عدم الاستقرار هو سلوك النظام العشوائي الذي يمنع الملاحظة العمل من التشغيل. وغالبًا ما يكون العمل الذي يجب تنفيذه، ولكنه قد لا يكون حاصلاً على قيود متطلبات التوقيت التي تؤدي إلى تشغيله في أي وقت معين. لأنه عشوائيًا، فمن الصعب للغاية دحض وجود عدم استقرار عبء العمل المعين. كما أنه من الصعب للغاية إثبات أن مصدرًا معروفًا عدم الاستقرار كان سبب مشكلة معينة في الأداء. تُعد الأدوات الأكثر شيوعًا تُستخدم لتشخيص أسباب عدم الاستقرار (مثل التتبع أو التسجيل) التي يمكن أن تؤدي إلى عدم استقرارها.
مصادر عدم الاستقرار التي شهدتها عمليات التنفيذ الواقعية لنظام Android تشمل:
- تأخير أداة الجدولة
- معالِجات الإيقاف
- يتم تشغيل رمز السائق لفترة طويلة جدًا مع إيقاف الإجراءات الاستباقية أو المقاطعات.
- خوادم softirq طويلة الأمد
- قفل الطلب (التطبيق، إطار العمل، برنامج تشغيل النواة، قفل المربط، mmap قفل)
- اعتراض على واصف الملفات عندما تؤدي سلسلة المحادثات ذات الأولوية المنخفضة إلى تثبيت القفل على ، ما يمنع تشغيل سلسلة محادثات ذات أولوية عالية
- تشغيل رمز برمجي مهم لواجهة المستخدم في قوائم انتظار العمل حيث يمكن أن يتأخر
- عمليات الانتقال إلى وحدة المعالجة المركزية (CPU) غير نشِطة
- التسجيل
- حالات التأخير في وحدات الإدخال والإخراج
- إنشاء عملية غير ضرورية (على سبيل المثال،
CONNECTIVITY_CHANGEعمليات بث) - حدث خلل في ذاكرة التخزين المؤقت للصفحة بسبب عدم كفاية الذاكرة الخالية
والفترة الزمنية المطلوبة لفترة معينة من عدم الاستقرار قد تكون أو لا تنخفض مع زيادة السعة. على سبيل المثال، إذا ترك أحد السائقين مقاطعات أثناء التنقل تم الإيقاف أثناء انتظار قراءة من خلال حافلة i2c، سيستغرق الأمر وقتًا ثابتًا بغض النظر عما إذا كانت وحدة المعالجة المركزية (CPU) بسرعة 384 ميغاهرتز أو 2 غيغاهرتز. متزايد القدرة ليست حلاً عمليًا لتحسين الأداء عندما يكون عدم الاستقرار المشاركة. ونتيجةً لذلك، لن تحسِّن المعالِجات الأسرع عادةً الأداء في المواقف الصعبة القاسية
وأخيرًا، على عكس القدرة، فإن عدم الاستقرار يكون بالكامل تقريبًا داخل مجال مورد النظام.
استهلاك الذاكرة
في العادة، يرجع استهلاك الذاكرة إلى ضعف الأداء. بينما الاستهلاك نفسه ليس مشكلة في الأداء، بل يمكن أن يتسبب في عدم الاستقرار عبر استهلاك منخفض للذاكرة، وعمليات إعادة تشغيل الخدمة، وتعطل ذاكرة التخزين المؤقت للصفحة. متناقصة قد يؤدي استهلاك الذاكرة إلى تجنب الأسباب المباشرة لضعف الأداء، قد تكون تحسينات أخرى مستهدفة تتجنب هذه الأسباب أيضًا (على سبيل المثال، تثبيت إطار العمل لمنعه من التقسيم إلى صفحات عند تقسيمه إلى صفحات بعد فترة وجيزة).
تحليل الأداء الأولي للجهاز
البدء من نظام فعال ولكنه سيئ الأداء ومحاولة إصلاح سلوك النظام من خلال النظر إلى الحالات الفردية من ضعف عرض الإعلان للمستخدم الأداء لا يعتبر استراتيجية سليمة. بسبب ضعف الأداء لا يمكن تكرارها بسهولة (أي عدم الاستقرار) أو حدوث مشكلة في التطبيق أيضًا فإن العديد من المتغيرات في النظام الكامل تمنع هذه الإستراتيجية من أن تكون فعالة. بالنسبة ونتيجة لذلك، فمن السهل جدًا إساءة تحديد الأسباب وإجراء تحسينات طفيفة في حين فقدان الفرص المنهجية لإصلاح الأداء على مستوى النظام.
بدلاً من ذلك، استخدم النهج العام التالي عند إيجاد حل الجهاز:
- يتم تشغيل النظام على واجهة المستخدم مع تشغيل جميع برامج التشغيل وبعض البرامج إعدادات محافظ التكرار (إذا قمت بتغيير إعدادات محافظ التكرار، كرر جميع الخطوات أدناه).
- التأكد من توافق النواة مع نقطة تتبُّع "
sched_blocked_reason" بالإضافة إلى نقاط التتبع الأخرى في مسار العرض التي تشير إلى وقت ظهور يتم تسليمه إلى الشاشة. - إجراء آثار طويلة لمسار واجهة المستخدم بالكامل (من استلام الإدخالات عبر IRQ) إلى الفحص النهائي) أثناء إجراء عبء عمل خفيف ومتسق (على سبيل المثال، UiBench أو اختبار الكرة في TouchLatency).
- إصلاح حالات انخفاض اللقطات التي تم رصدها في الوزن الخفيف والمتسق عبء العمل.
- كرِّر الخطوات من 3 إلى 4 إلى أن تتمكّن من الجري بدون إفلات لقطات لمدة تزيد عن 20 ثانية. في كل مرة.
- انتقِل إلى مصادر أخرى مرئية للمستخدم من أجل إيقاف مؤقت.
تشمل الأشياء البسيطة الأخرى التي يمكنك تنفيذها مبكرًا أثناء ظهور الجهاز ما يلي:
- تأكد من احتواء النواة على sched_blocked_reason حزمة التتبع. تم تفعيل نقطة التتبُّع هذه مع فئة التتبُّع المجدولة في النظام يقدم الوظيفة المسئولة عن النوم عندما تدخل سلسلة المحادثات في وضع السكون غير المنقطع. تُعد أمرًا بالغ الأهمية لتحليل الأداء لأن النوم غير المنقطع هو مؤشر شائع جدًا على عدم الاستقرار.
- يُرجى التأكّد من توفّر بيانات تتبُّع كافية لوحدة معالجة الرسومات ومسارات العرض. مشغَّلة عناصر SOC الأخيرة في Qualcomm، يتم تفعيل نقاط التتبع باستخدام:
adb shell "echo 1 > /d/tracing/events/kgsl/enable"adb shell "echo 1 > /d/tracing/events/mdss/enable"
وتظل هذه الأحداث مفعّلة عند تشغيل سجل النظام لتتمكن من رؤية أحداث إضافية
معلومات في التتبع الخاص بمسار العرض (MDSS) في
قسم "mdss_fb0". لن تظهر لك أي حسابات أخرى في Qualcomm SOC
المعلومات حول وحدة معالجة الرسومات في عرض تتبع النظام القياسي، غير أن النتائج
موجودة في التتبع نفسه (لمزيد من التفاصيل، راجع
فهم
systrace).
ما تريده من هذا النوع من تتبع العرض هو حدث واحد يشير بشكل مباشر إلى تسليم إطار إلى الشاشة. من هناك، يمكنك تحديد ما إذا كنت قد بلغت وقت عرض اللقطة بنجاح إذا كان الحدث Xn يحدث في أقل من 16.7 ملي ثانية بعد الحدث Xn-1 (بافتراض عرض بتردد 60 هرتز)، فستعلم أنك لم تتعطل. إذا لم تقدّم شهادة SOC هذه الإشارات، يُرجى العمل مع البائع للحصول عليها. يُعد تصحيح عدم الاستقرار أمرًا صعبًا للغاية بدون إشارة محددة لاكتمال عرض الإطار.
استخدام مقاييس أداء اصطناعية
مقاييس الأداء الاصطناعية مفيدة لضمان توفير وظائف الجهاز الأساسية موجودة. ومع ذلك، فإنّ التعامل مع مقاييس الأداء كخادم وكيل للأجهزة التي يتم رصدها أدائه ليس مفيدًا.
بالاستناد إلى التجارب المتعلّقة بالمعاملات SOC، والاختلافات في مقاييس الأداء الاصطناعية أن أداء الوحدات التنظيمية بين الوحدات التنظيمية SOC لا يرتبط بفرق مماثل في أداء واجهة المستخدم الملموسة (عدد اللقطات المسقطة، نسبة 99 في المئة) والوقت وما إلى ذلك). أما مقاييس الأداء الاصطناعية، فتمثّل مقاييس أداء للسعة فقط. آثار عدم الاستقرار الأداء الذي تم قياسه لهذه المعايير من خلال خسارة الوقت من الحجم الإجمالي تشغيل المعيار. ونتيجةً لذلك، غالبًا ما تكون نتائج مقاييس الأداء الاصطناعية غير ذي صلة كمقياس للأداء الذي لاحظه المستخدمون.
ضع في الاعتبار اثنين من الوحدات التنظيمية التي تستخدم معيار 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": وقت استجابة اللمس
والكرة المرتدة (للتبديل بين الأوضاع، انقر على الزر في أعلى اليسار
العليا).
إنّ اختبار الكرة المرتدّة بسيط تمامًا كما يبدو: ترتد الكرة. على الشاشة إلى الأبد، بغض النظر عن إدخالات المستخدم. عادةً ما يكون بقدر كبير، تمثّل الاختبار الأصعب على أنّه يمكن تنفيذه بشكل مثالي، ولكن كلما اقترب بدون أي إطارات تم إسقاطها، سيكون جهازك أفضل. تشير رسالة الأشكال البيانية واختبار الكرة المرتدة هو لعبة بسيطة للغاية لكنها متسقة الذي يعمل في ساعة منخفضة جدًا (على افتراض أن الجهاز له تردد والحاكم إذا كان الجهاز يعمل بدلاً من ذلك مع ساعات ثابتة، وصول وحدة المعالجة المركزية (CPU)/وحدة معالجة الرسومات (GPU) إلى الحد الأدنى تقريبًا عند إجراء اختبار الكرة المرتدة لأول مرة). فمع مرور النظام واقتراب قُرب الساعات من عدم نشاط الجهاز، تصبح وحدة المعالجة المركزية (CPU)/وحدة معالجة الرسومات المطلوبة يزيد الوقت لكل إطار. يمكنك مشاهدة الكرة ورؤية الأمور غير الضرورية، ستتمكن أيضًا من رؤية الإطارات المفقودة في سجلّ النظام.
نظرًا لأن عبء العمل متسق للغاية، فيمكنك تحديد معظم مصادر غير المستقرة بسهولة أكبر من معظم أعباء العمل المرئية للمستخدم من خلال تتبع يعمل بالضبط على النظام أثناء كل إطار لم يتم رصده بدلاً من واجهة المستخدم المشروع. تضخم الساعات المنخفضة من أثر عدم الاستقرار عن طريق جعلها أن يؤدي عدم الاستقرار إلى إسقاط الإطار. وبالتالي، اقتراب معدل TouchLatency من 60 لقطة في الثانية، قل احتمال تعرضك لنظام سيئ التي تتسبب في تعطل متقطع ويصعب تكراره بصورة أكبر التطبيقات.
ونظرًا لأن عدم الاستقرار غالبًا (وليس دائمًا) هو متغير سرعة الساعة، فاستعن باختبار تعمل في ساعات منخفضة جدًا لتشخيص عدم الاستقرار للأسباب التالية:
- ليس كل عدم الاستقرار ثابتًا على مدار الساعة؛ مصادر عديدة تستهلك وحدة المعالجة المركزية (CPU) فقط الوقت.
- يجب أن يحصل الحاكم على متوسط وقت عرض اللقطة قريبًا من الموعد النهائي في الوقت المنقضي، وبالتالي فإن الوقت المستغرق في تشغيل أعمال غير واجهة المستخدم يمكن أن يدفعها إلى إسقاط إطار.