ليش بنقيس على أجهزة حقيقية

هاتف Android اقتصاديّ عمره أربع سنوات يقول الحقيقة. جهاز التطوير لديك يقول لك ما تريد سماعه. الفجوة بين هذَين الصوتَين هي حيث تعيش معظم انحدارات الأداء، غير مكتشفة، حتّى يرسل عميل فيديو للتطبيق يتجمّد.

هذا المقال عن أسطول الأجهزة الذي نختبر عليه، لماذا اخترنا كلّ منها، وما الذي التقطته ولم تفعله الـ emulators.

لماذا تكذب الـ emulators#

emulator Android على Mac حديث يشغّل كود ARM على Apple Silicon مع تسريع عتاد. سريع. يستخدم RAM المضيف. يستخدم IO تخزين المضيف. هو، بنيويّاً، أسرع برتبة من أيّ هاتف Android حقيقيّ شُحن في هذا العقد.

عمل الأداء المُقاس على الـ emulator يجتاز. نفس الكود، مشحون إلى Galaxy A series من ٢٠٢١، يتجمّد لثلاث ثوانٍ عند الإقلاع.

نفس الشيء صحيح لـ iOS. الـ simulator يشغّل كود native x86_64 / ARM على المضيف، مع ميزانيّة CPU وذاكرة المضيف. ليس الجهاز.

شحنّا إصلاحات «عملت على simulator» خمس مرّات تحوّلت إلى تقارير bugs خلال أسبوع. توقّفنا عن الثقة بالـ simulator للأداء. نستخدمه للرسم والسلوك؛ أرقام الأداء تأتي من عتاد حقيقيّ.

الأسطول#

نحتفظ بأربعة أجهزة ماديّة على مكتب قرب فريق التطوير. كلّ منها يمثّل شريحة عملاء حقيقيّة.

الأوّل هو الأهمّ. إن شعرت ميزة جيّدة على A12، ستشعر جيّدة على كلّ شيء. العكس ليس صحيحاً.

ما التقطته الأجهزة الحقيقيّة#

bugs حقيقيّة من إنتاج حقيقيّ:

تجمّد ٣٨٠ مللي ثانية عند الإقلاع#

أوّل رسم لعرض القائمة تضمّن استعلام Drift متزامن قرأ ٨٠٠٠ جهة اتّصال لبناء فهرس البحث. على M1 Mac، ١٢ مللي ثانية. على A12، ٣٨٠ مللي ثانية. نقلنا بناء الفهرس إلى isolate ما-بعد-الرسم وذهب التجمّد.

تذبذب تمرير لم تستطع الـ emulators رؤيته#

قائمة فواتير استخدمت widgets Builder التي أعادت البناء أكثر من اللازم. على أيّ جهاز حديث، ٦٠ fps. على A12 مع نصّ غنيّ بـ Emoji، انخفضت القائمة إلى ٣٥ fps وشعر بها المستخدم. استبدال Builder بـ widgets مُخزَّنة مع تجاوزات == أعادنا إلى ٥٨ fps.

استنزاف بطّاريّة ١٤٪ في ٣٠ دقيقة من الاستخدام الخامل#

التطبيق كان يقوم بـ polling لنقطة نهاية المزامنة كلّ ٥ ثوانٍ بدون فحص الظهور. على iPhone 8 ببطّاريّة قديمة، كان هذا مرئيّاً في تقرير بطّاريّة النظام خلال ساعة. انتقلنا إلى polling واعٍ للظهور وانخفض الاستنزاف إلى ٤٪.

استنفاد connection-pool تحت خفض الأداء الحراريّ#

حين يضرب iPhone 8 خفض الأداء الحراريّ، sockets الشبكة تحصل على timeout أسرع. منطق إعادة المحاولة لدينا لم يحسب لهذا وكان يفتح sockets جديدة أسرع ممّا تستطيع الإغلاق، مستنفداً الحدّ لكلّ تطبيق. رأيناه لأنّ الجهاز سخن في اختبار إجهاد.

كيف نشغّل الاختبارات#

ثلاث طبقات.

١. smoke يدويّ على الجهاز البطيء#

قبل كلّ إصدار، المهندس on-call يمشي عبر سيناريو smoke ١٥ دقيقة على A12 تحديداً: إقلاع بارد، تنقّل إلى أربع شاشات مفتاحيّة، إنشاء واحد، بحث واحد، offline-ثمّ-إعادة-اتّصال واحد. نجاح/فشل بالإحساس، لا بالرقم.

٢. مقاييس آليّة من أسطول الأجهزة#

نشغّل تدفّق Maestro ليلياً على كلّ جهاز يلتقط:

• إقلاع بارد إلى أوّل إطار مللي ثانية
• الزمن إلى التفاعليّة على عرض القائمة
• ذاكرة عند الخمول بعد ٥ دقائق
• ذاكرة بعد ٥٠ تنقّل عبر التطبيق
• delta البطّاريّة خلال جلسة مكتوبة ١٠ دقائق

الأرقام تذهب إلى لوحة معلومات. الانحدارات مقابل وسيط الأسبوع الماضي تُطلق تنبيهاً.

٣. telemetry مستخدم حقيقيّ#

في الإنتاج، نأخذ عيّنة من توقيت الإجراءات المفتاحيّة ونشحنها إلى متجر مقاييس، مُعلَّمة بفئة جهاز. نستطيع مقارنة «أوّل-رسم-عرض-القائمة p95» بين Galaxy A series و iPhone 13. الأسطول يتنبّأ بما سنراه في RUM؛ RUM هو مصدر الحقيقة.

ماذا يعني «فئة الجهاز» في telemetry لدينا#

لا نسجّل نماذج أجهزة محدّدة في telemetry (مخاوف PII). بدلاً من ذلك، كلّ حدث يحمل فئة خشنة:

type DeviceClass =
  | 'budget-android'   // <٤ GB RAM أو eMMC بطيء معروف
  | 'mid-android'      // ٤-٨ GB RAM
  | 'flagship-android' // >٨ GB RAM
  | 'old-ios'          // <iPhone 11
  | 'mid-ios'          // iPhone 11-13
  | 'flagship-ios';    // >iPhone 13

ستّ فئات تغطّي العالم لأغراضنا. نُطبِّق المقاييس بالفئة لأنّ التجميع عبرها يخفي الصورة. p95 على «flagship-android» مختلف عن p95 على «budget-android» بمقدار رتبة.

ماذا يكلّف هذا الانضباط#

الوقت، في الغالب. التشغيل الليليّ للأسطول يستغرق حوالي ٤٠ دقيقة (بالتوازي عبر الأجهزة) ويُظهر ضوضاء يجب فرزها. الـ smoke اليدويّ قبل كلّ إصدار هو ١٥ دقيقة لكلّ إصدار. الأجهزة تحتاج للاستبدال مع تدهور بطّاريّاتها ومع تحديث الـ OS بعد ما يدعمه التطبيق.

الكلفة منخفضة مقارنة بكلفة شحن انحدار يجعل التطبيق يشعر مكسوراً على شريحة Android الاقتصاديّة، حيث معظم نمونا.

المبدأ الأكبر#

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

اشترِ الهاتف البطيء. أبقِه على مكتبك. شغّل التطبيق عليه قبل الشحن. معظم ما يبدو «فرصة تحسين أداء» هو في الواقع عدم تطابق ميزانيّة بين الجهاز الذي كُتب الكود عليه والجهاز الذي سيُستخدم عليه.

المنشور التالي عن الكلفة المنسيّة لإعداد الاتّصال. أو تصفّح فهرس الكتابة لاتّجاهات أخرى.