أداء تطبيقات الجوال

لماذا يهم

يحكم المستخدمون على التطبيق في ثوانيه الأولى ومع كل تمرير. فالبدء البطيء أو القائمة المتقطّعة أو الهاتف الذي يسخن ويفقد شحنه قد يؤدي إلى حذف التطبيق وتقييمات ضعيفة في المتجر. والمنصتان تقيسان ذلك أيضاً: فمؤشرات Android vitals في Google Play Console تعرض زمن بدء التشغيل والإطارات البطيئة والمتجمّدة والسلوك المرتبط بالبطارية من أجهزة حقيقية، وتعرض نافذة Organizer في Xcode زمن الإطلاق وحالات التعليق (Hangs) والذاكرة واستهلاك البطارية من المستخدمين الذين يشاركون بيانات التحليلات.

وبالنسبة إلى المختبِر، يسهل أن تفوته عيوب الأداء لأنها تعتمد على الظروف: جهاز رخيص، أو بدء بارد، أو جلسة طويلة، أو إشارة ضعيفة. كما أنها تتسلل قليلاً مع كل إصدار حتى يصبح التطبيق أبطأ بوضوح مما كان. وقياس السيناريوهات نفسها بالطريقة نفسها في كل إصدار يحوّل عبارة «يبدو بطيئاً» إلى أرقام يستطيع المطور العمل بها.

المقاييس الخمسة وما يعنيه كل منها

لكل مقياس تعريفه وطريقته الخاصة في الإخفاق. فتعلّم المفردات أولاً: التقرير الذي يقول «بدء التشغيل بطيء» أضعف بكثير من تقرير يقول «البدء البارد حتى أول إطار ارتفع من ⁦1.4⁩ ثانية إلى ⁦2.6⁩ ثانية».

• زمن بدء التشغيل: البدء البارد (Cold start) يُطلق التطبيق وعمليته غير قائمة، فيُنشأ كل شيء ويُحمَّل؛ والبدء الدافئ (Warm start) يعيد استخدام جزء مما هو موجود لكنه يعيد إنشاء الشاشة؛ والبدء الساخن (Hot start) يعيد فقط شاشة ما زالت في الذاكرة إلى الواجهة. ويسمّي Android لحظتين: زمن العرض الأولي (Time to initial display - TTID) أي أول إطار، وزمن العرض الكامل (Time to full display - TTFD) حين يصبح المحتوى الذي جاء المستخدم من أجله جاهزاً، ويُبلغ عنه التطبيق باستدعاء reportFullyDrawn(). وتقيس Android vitals زمن البدء حتى أول إطار (TTID)، وتَعُدّ زمناً مفرطاً كلَّ بدء بارد يستغرق ⁦5⁩ ثوانٍ أو أكثر، وكلَّ بدء دافئ يستغرق ثانيتين أو أكثر، وكلَّ بدء ساخن يستغرق ⁦1.5⁩ ثانية أو أكثر.
• معدّل الإطارات: عند ⁦60⁩ هرتز يملك التطبيق نحو ⁦16.7⁩ مللي ثانية لإنتاج كل إطار، وعند ⁦120⁩ هرتز نحو ⁦8.3⁩ مللي ثانية. والإطارات التي تتجاوز هذه الميزانية تظهر تقطّعاً يسمى Jank (وتتحدث Apple عن «hitches»). وتعرض Android vitals العرض البطيء (Slow rendering) والإطارات المتجمّدة (Frozen frames)؛ والإطار المتجمّد هو الذي يستغرق عرضه أكثر من ⁦700⁩ مللي ثانية. والسبب المعتاد عمل طويل على الخيط الرئيسي (Main thread)، وهو الخيط نفسه الذي يؤدي انسداده إلى حالة ANR التي رأيتها في درس Android وiOS.
• الذاكرة: راقب الذروة التي يحتاجها المسار، وهل تعود الذاكرة إلى خط الأساس (Baseline) عند انتهائه؛ فالذاكرة التي تنمو مع كل تكرار تعني تسرّباً (Memory leak). والاستهلاك المرتفع يؤدي إلى إنهاء التطبيق: في الخلفية يُنهيه النظام أسرع، فقد يعود المستخدم إلى تطبيق أُعيد تشغيله وفقد ما أدخله؛ وفي المقدمة يُنهيه تجاوزُ حدّه على شكل انهيار بسبب نفاد الذاكرة (Out of memory).
• البطارية: تذهب الطاقة إلى الشاشة والمعالج وأجهزة الاتصال اللاسلكي والمستشعرات مثل GPS. والعيوب المعتادة عمل لا يتوقف: تحديثات الموقع بعد مغادرة المستخدم للخريطة، وأقفال الإيقاظ (Wake locks) التي تُبقي المعالج مستيقظاً، والاستعلام من الخادم كل بضع ثوانٍ، ومهام الخلفية التي تتجاهل وضع الخمول Doze في Android أو وضع الطاقة المنخفضة (Low Power Mode) في iOS. وتعرض إعدادات البطارية في كل منصة حصة كل تطبيق.
• ظروف الشبكة: ينتقل المستخدمون بين Wi-Fi وبيانات جوال سريعة وبطيئة وانعدام الإشارة. والكمون (Latency)، أي زمن كل رحلة ذهاب وإياب، يعاقب الشاشات التي ترسل طلبات كثيرة واحداً تلو الآخر؛ وعرض النطاق (Bandwidth) المنخفض يعاقب الصور والاستجابات الكبيرة؛ وفقدان الحزم (Packet loss) يفرض إعادة إرسال البيانات المفقودة فيزيد التأخير.

القياس الموثوق: الظروف قبل الأرقام

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

كرّر كل قياس (عشرة تشغيلات خيار شائع) وأبلغ عن الوسيط (Median)، أي القيمة الوسطى بعد ترتيب التشغيلات، مع مدى التفاوت من أدنى تشغيل إلى أعلاه؛ فتشغيل واحد لا يثبت شيئاً. وقارن بالإصدار السابق مقيساً بالطريقة نفسها، فهذا يكشف الانحدار حتى حين لم يضع أحد هدفاً. وأرقام مختبرك تعيد إنتاج المشكلات وتؤكد الإصلاحات، أما البيانات الميدانية في Android vitals وOrganizer في Xcode فتُظهر ما يعيشه المستخدمون الحقيقيون على أجهزة كثيرة.

# Android: release build on a real device, adb from the SDK platform tools
adb shell am force-stop com.example.shop          # the next launch is a cold start
adb shell am start -W -n com.example.shop/.MainActivity
#   TotalTime: 1873                                 # ms to the first frame, about TTID
adb logcat -d | grep "Fully drawn"                  # TTFD, if the app reports it
#   ... Fully drawn com.example.shop/.MainActivity: +2s105ms
adb shell dumpsys gfxinfo com.example.shop reset    # clear the frame statistics
#   ...scroll the list for 30 seconds...
adb shell dumpsys gfxinfo com.example.shop          # janky frames, frame percentiles
adb shell dumpsys meminfo com.example.shop          # memory used by the app process
adb shell dumpsys batterystats --reset              # start a battery session
#   ...unplug the phone, use the app for 30 minutes, plug it back in...
adb shell dumpsys batterystats com.example.shop     # the app's use since the reset

# iOS: Xcode > Product > Profile opens Instruments with templates such as
#   App Launch, Time Profiler, Animation Hitches, Allocations, Leaks, Network

جرّبها: محوّل البايت / KB / MB / GB

الاختبار في ظروف شبكة حقيقية

عرض دليل السيناريوهات كيف تبدّل الشبكات وتفرض حالات انعدام الاتصال. أما في الأداء فالسؤالان هما: كم ينتظر المستخدم، وكم من البيانات يستهلك التطبيق على اتصال ضعيف؟ استخدم مجموعة ثابتة من ملفات تعريف الشبكة (Profiles) لتبقى النتائج قابلة للمقارنة، مثل Wi-Fi جيد و4G معتاد وملف ضعيف يشبه 3G بكمون مرتفع وبعض الفقد. يضبط محاكي Android السرعة والتأخير، ويقدّم Network Link Conditioner في iOS ملفات مثل 3G وEdge و«Very Bad Network»، ويغطي وكيلٌ (Proxy) يُبطئ الاتصال أو شبكة Wi-Fi اختبارية مقيّدة أجهزةَ Android الحقيقية.

يتراكم الكمون مع الطلبات المتتابعة: ستة استدعاءات واحداً بعد الآخر بزمن ⁦300⁩ مللي ثانية لكل رحلة ذهاب وإياب تكلّف ⁦1.8⁩ ثانية على الأقل من انتظار الشبكة وحده. وعرض النطاق يعاقب الحجم: استجابة بحجم ⁦2⁩ ميغابايت لا يلاحظها أحد على Wi-Fi المكتب تستغرق ثوانيَ على اتصال بطيء. اسأل كم طلباً ترسل كل شاشة رئيسية وما حجمها، وتحقّق من أن الاستجابات مضغوطة وأن الصور تصل بالحجم الذي تعرضه الشاشة.

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

جرّبها: محلّل حجم الاستجابة جرّبها: محاكي رموز حالة API جرّبها: محلّل زمن الاستجابة

مثال تطبيقي: قائمة مطاعم تتقطّع

يستعد تطبيق لتوصيل الطعام لإصدار ⁦3.2⁩، ويقول زملاء يجرّبون النسخة المرشحة للإصدار (Release candidate) إن قائمة المطاعم «ثقيلة» على الهواتف الأرخص. يثبّت المختبِر النسخة المرشحة، وللمقارنة الإصدار الحالي ⁦3.1.4⁩، على أضعف هاتف Android مدعوم (شاشة ⁦60⁩ هرتز)، ويسجّل الدخول بحساب الاختبار المعتمد، ويمرّر القائمة حتى نهايتها ويعود لمدة ⁦30⁩ ثانية، ويجمع إحصاءات الإطارات والذاكرة. ثلاثة تشغيلات لكل إصدار تعطي القيم الوسيطة أدناه.

تؤكد إحصاءات الإطارات الشكوى: فالإصدار الجديد يعرض إطارات أقل في الثواني الثلاثين نفسها، ويتجاوز عدد أكبر بكثير منها الميزانية؛ فالمئين التسعون (90th percentile) البالغ ⁦38⁩ مللي ثانية يعني أن إطاراً من كل عشرة استغرق ⁦38⁩ مللي ثانية أو أكثر. وتكشف حركة الشبكة سبباً محتملاً: كل بطاقة مطعم تنزّل الآن صورة بحجم ⁦600⁩ كيلوبايت يصغّرها الهاتف إلى صورة مصغّرة صغيرة، وفكّ ترميز الصور الكبيرة وتصغيرها يكلّفان وقتاً من المعالج وذاكرةً، مما يؤخّر الإطارات.

• الحكم: انحدار في الأداء مقارنةً بالإصدار ⁦3.1.4⁩ في كل مقاييس الإطارات وفي الذاكرة؛ فقد ارتفعت الإطارات المتقطّعة من ⁦4.1%⁩ إلى ⁦27.8%⁩.
• عنوان تقرير الخطأ: «تمرير قائمة المطاعم: ⁦27.8%⁩ إطارات متقطّعة على Android منخفض المواصفات مقابل ⁦4.1%⁩ في ⁦3.1.4⁩»، مع الجهاز والنسخة والخطوات والجدول وتسجيل للشاشة ورابط صورة مع حجمها.
• تأكيد السبب المحتمل مسؤولية المطور؛ والإصلاح المتوقع صور مصغّرة تُرسَل بحجم العرض.
• يكرر اختبار التأكيد السيناريو نفسه على الجهاز نفسه ويقارن كل الصفوف، ثم ينضم السيناريو إلى قائمة فحص الأداء في كل إصدار.

Device:   lowest-end supported Android phone, 60 Hz display, release builds
Scenario: restaurant list, scroll to the end and back for 30 s, median of 3 runs

                              3.1.4 (current)    3.2.0-rc1
Total frames rendered              1,710            1,240
Janky frames                       4.1 %            27.8 %
90th percentile frame time         14 ms            38 ms
99th percentile frame time         31 ms            160 ms
Memory after scroll (meminfo)      160 MB           410 MB
Photo per restaurant card          45 KB            600 KB

جرّبها: محلّل حجم الاستجابة

أسئلة شائعة

المراجع

• Android vitalsAndroid Developers (Google)مقاييس جودة التطبيقات التي يجمعها Google Play من أجهزة المستخدمين — ومنها معدّلا الأعطال وعدم الاستجابة (ANR) كما يلحظهما المستخدم ضمن المؤشرات الأساسية — وحدود السلوك السيئ التي تؤثر في ظهور التطبيق.
• Certified Tester Mobile Application Testing (CT-MAT)ISTQB · 2019منهج ISTQB التخصصي لاختبار تطبيقات الجوال: أنواع التطبيقات وتحديات الأجهزة والمنصات وأنواع الاختبار والأدوات.
• ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023نموذج جودة المنتج: الملاءمة الوظيفية وكفاءة الأداء والتوافق وقابلية التفاعل والموثوقية والأمان وقابلية الصيانة والمرونة.
• XCTestAppleإطار Apple لاختبارات الوحدة والأداء والواجهة لمشاريع Xcode على iOS وبقية منصات Apple.