نظرة عامة على قياس أداء التطبيق

يساعدك هذا المستند في تحديد مشاكل الأداء الرئيسية في تطبيقك وحلّها.

مشاكل الأداء الرئيسية

هناك العديد من المشاكل التي يمكن أن تساهم في ضعف أداء التطبيق، ولكن في ما يلي بعض المشاكل الشائعة التي يجب البحث عنها:

وقت استجابة بدء التشغيل

وقت الاستجابة عند بدء التشغيل هو مقدار الوقت الذي يستغرقه ظهور بيانات المستخدم على الشاشة منذ النقر على رمز التطبيق أو الإشعار أو نقطة الدخول الأخرى.

استهدِف أهداف بدء التشغيل التالية في تطبيقاتك:

• التشغيل على البارد في أقل من 500 ملي ثانية يحدث بدء التشغيل على البارد عندما لا يكون التطبيق الذي يتم تشغيله متوفّرًا في ذاكرة النظام. ويحدث ذلك عند تشغيل التطبيق للمرة الأولى بعد إعادة التشغيل أو بعد أن أوقف المستخدم أو النظام عملية التطبيق. يتطلّب التشغيل على البارد أكبر قدر من العمل من النظام، لأنّه يجب تحميل كل شيء من وحدة التخزين وتهيئة التطبيق. حاوِل أن يستغرق التشغيل على البارد 500 ملي ثانية أو أقل.
• إعادة تشغيل بطيء في أقل من 200 ملي ثانية وإعادة تشغيل سريع في أقل من 150 ملي ثانية. يحدث بدء التشغيل السريع عندما تكون عملية التطبيق قيد التشغيل في الخلفية، ولكن يحتاج النظام إلى إعادة تهيئة واجهة المستخدم أو إعادة النشاط إلى المقدّمة، مثلما يحدث عندما يخرج المستخدم من التطبيق ويعيد فتحه بعد فترة قصيرة. يكون إعادة تشغيل سريع أسرع لأنّ نشاط التطبيق يكون مخزّنًا مؤقتًا في الذاكرة، ولا يحتاج سوى إلى الانتقال إلى المقدّمة، بدون الحاجة إلى إعادة إنشاء هيكلية طرق العرض. احرص على أن تكون مدة عمليات البدء الدافئ أقل من 200 ملي ثانية وعمليات البدء السريع أقل من 150 ملي ثانية.
• وقت الاستجابة في المئويَّين 95 و99 قريب جدًا من متوسط وقت الاستجابة. يمثّل P95 وP99 النسبة المئوية الخامسة والتسعين والنسبة المئوية التاسعة والتسعين من أوقات بدء التشغيل، بينما يمثّل الوسيط النسبة المئوية الخمسين. عندما يستغرق التطبيق وقتًا طويلاً لبدء التشغيل، يؤدي ذلك إلى توفير تجربة سيئة للمستخدم. قد تحدث مشكلة تعارض القفل في عمليات الاتصال بين العمليات (IPC) وعمليات الإدخال/الإخراج غير الضرورية أثناء المسار الحرج لبدء تشغيل التطبيق، ما يؤدي إلى حدوث حالات عدم اتساق.

إيقاف مؤقت لعرض واجهة المستخدم عند التمرير

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

استهداف معدّلات إعادة تحميل بمقدار 90 هرتز في تطبيقاتك تبلغ معدّلات العرض التقليدية 60 هرتز، ولكن تعمل العديد من الأجهزة الأحدث بوضع 90 هرتز أثناء تفاعلات المستخدم، مثل التمرير. تتيح بعض الأجهزة معدّلات أعلى تصل إلى 120 هرتز.

لمعرفة معدّل التحديث الذي يستخدمه الجهاز في وقت معيّن، فعِّل تراكبًا باستخدام خيارات المطوّرين > عرض معدّل التحديث في قسم تصحيح الأخطاء.

الانتقالات غير السلسة

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

عدم كفاءة استهلاك الطاقة

يؤدي تنفيذ المهام إلى تقليل شحن البطارية وعمرها في النهاية.

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

أصبحت عملية تخصيص الذاكرة وجمع البيانات المُهمَلة أسرع وأكثر كفاءة، خاصةً بالنسبة إلى العناصر المؤقتة. على الرغم من أنّ أفضل الممارسات كانت تتطلّب تجنُّب تخصيص عناصر كلما أمكن ذلك، ننصحك باتّباع الأسلوب الذي يتناسب أكثر مع تطبيقك وبنيته. إنّ توفير الذاكرة المخصّصة على حساب كتابة رمز برمجي يصعب صيانته ليس أفضل ممارسة، نظرًا لما يمكن أن يفعله ART.

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

تحديد المشاكل

لحلّ مشاكل الأداء، حدِّد مسارات المستخدمين المهمة التالية وافحصها:

• عمليات بدء التشغيل الشائعة، بما في ذلك من مشغّل التطبيقات والإشعارات
• الشاشات التي يتنقّل فيها المستخدم بين البيانات
• عمليات الانتقال بين الشاشات
• عمليات طويلة الأمد، مثل التنقّل أو تشغيل الموسيقى

بالنسبة إلى كل تدفق من هذه التدفقات، افحص ما يحدث باستخدام أدوات تصحيح الأخطاء التالية:

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

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

• مسارات الإعداد في الشركات الناشئة
  • مقاييس الحقل: وقت بدء التشغيل في Play Console
  • الاختبارات المعملية: اختبار بدء التشغيل باستخدام Macrobenchmark
• Jank
  • بيانات مقاييس تجارب المستخدمين الحقيقيين
    • مؤشرات الأداء المتعلقة بمعدل عرض اللقطات في Play Console: لا يمكنك في Play Console تضييق نطاق المقاييس لتشمل رحلة مستخدم معيّنة. ولا يسجّل إلا معدّل بطء عرض اللقطات في التطبيق.
    • القياس المخصّص باستخدام FrameMetricsAggregator: يمكنك استخدام FrameMetricsAggregator لتسجيل مقاييس إيقاف مؤقت لعرض واجهة المستخدم أثناء سير عمل معيّن.
  • الاختبارات المعملية
    • التمرير باستخدام Macrobenchmark
    • تجمع Macrobenchmark بيانات توقيت اللقطات باستخدام أوامر dumpsys gfxinfo تضع رحلة مستخدم واحدة بين قوسين. هذه طريقة لفهم التفاوت في jank خلال رحلة مستخدم معيّنة. تُعد مقاييس RenderTime، التي توضّح المدة التي تستغرقها اللقطات في العرض، أكثر أهمية من عدد اللقطات غير السلسة لتحديد حالات التراجع أو التحسّن.

مشاكل متعلّقة بالتحقّق من روابط التطبيق

روابط التطبيقات هي روابط لصفحات في التطبيق تستند إلى عنوان URL لموقعك الإلكتروني ويتم التحقّق من أنّها تابعة لموقعك الإلكتروني. قد يتعذّر إكمال عمليات التحقّق من App Link للأسباب التالية:

• نطاقات فلاتر intent غير صحيحة: أضِف autoVerify إلى فلاتر intent لعناوين URL التي يمكن لتطبيقك الاستجابة لها فقط.
• عمليات تبديل البروتوكول التي لم يتم التحقّق منها: تُعد عمليات إعادة التوجيه من جهة الخادم ومن النطاق الفرعي التي لم يتم التحقّق منها من المخاطر الأمنية، ولا يمكن التحقّق منها. وهي تتسبّب في تعذُّر عمل جميع روابط autoVerify. على سبيل المثال، قد يؤدي إعادة توجيه الروابط من HTTP إلى HTTPS، مثل example.com إلى www.example.com، بدون إثبات ملكية روابط HTTPS إلى تعذُّر إثبات الملكية. احرص على التحقّق من روابط التطبيقات من خلال إضافة فلاتر الأهداف.
• الروابط التي لا يمكن التحقّق منها: يمكن أن يؤدي إضافة روابط لا يمكن التحقّق منها لأغراض الاختبار إلى عدم تحقّق النظام من "روابط التطبيق" لتطبيقك.
• الخوادم غير الموثوق بها: تأكَّد من أنّ خوادمك يمكنها الاتصال بتطبيقات العميل.

إعداد تطبيقك لتحليل الأداء

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

نقاط التتبُّع

يمكن للتطبيقات تزويد الرمز البرمجي الخاص بها بأحداث تتبُّع مخصّصة.

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

اعتبارات حِزم APK

يمكن أن تكون متغيرات تصحيح الأخطاء مفيدة في تحديد المشاكل ووضع رموز لعينات سلسلة استدعاء الدوال البرمجية، ولكنّها تؤثر بشكل كبير في الأداء. يمكن للأجهزة التي تعمل بالإصدار 10 من نظام التشغيل Android (المستوى 29 من واجهة برمجة التطبيقات) والإصدارات الأحدث استخدام profileable android:shell="true" في ملف البيان لتفعيل إنشاء الملفات الشخصية في الإصدارات العلنية.

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

موسيقى مجمّعة

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

يقلّل كل من speed وspeed-profile مقدار الرمز البرمجي الذي يتم تنفيذه من dex، وبالتالي مقدار الترجمة الفورية في الخلفية، ما قد يؤدي إلى حدوث تداخل كبير. يؤدي استخدام speed-profile فقط إلى تقليل تأثير تحميل فئات وقت التشغيل من ملف dex.

يؤدي الأمر التالي إلى تجميع التطبيق باستخدام الوضع speed:

adb shell cmd package compile -m speed -f com.example.packagename

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

/data/misc/profiles/ref/[package-name]/primary.prof

اعتبارات النظام

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

على الأجهزة التي تم عمل روت لها، ننصحك باستخدام نص برمجي lockClocks خاص باختبارات الأداء الدقيقة. من بين أمور أخرى، تنفّذ هذه البرامج النصية ما يلي:

• ضَع وحدات المعالجة المركزية بتردد ثابت.
• إيقاف النوى الصغيرة وإعداد وحدة معالجة الرسومات
• إيقاف التقييد الحراري

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

ننصحك، عند الإمكان، باستخدام إطار عمل للاختبار، مثل Macrobenchmark، الذي يمكن أن يقلّل من التشويش في القياسات ويمنع عدم دقة القياس.

مشكلة بطء التطبيق عند بدء تشغيله: نشاط غير ضروري

يمكن أن يؤدي نشاط الترامبولين إلى إطالة وقت بدء تشغيل التطبيق بدون داعٍ، ومن المهم معرفة ما إذا كان تطبيقك يستخدمه. كما هو موضّح في مثال التتبُّع التالي، يتبع أحد الرمزين activityStart رمزًا آخر activityStart مباشرةً بدون أن يرسم النشاط الأول أي إطارات.

الشكل 1. رسم بياني يوضّح نشاط الترامبولين

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

عمليات تخصيص غير ضرورية تؤدي إلى عمليات جمع البيانات غير المستخدَمة بشكل متكرر

قد تلاحظ عمليات جمع البيانات غير الضرورية (GC) تحدث بوتيرة أكبر من المتوقّع في Systrace.

في المثال التالي، يشير جمع البيانات المُهمَلة كل 10 ثوانٍ أثناء عملية طويلة الأمد إلى أنّ التطبيق قد يخصّص مساحة تخزين بشكل غير ضروري ولكن بشكل منتظم بمرور الوقت:

الشكل 2. عملية تتبُّع تعرض المسافة بين أحداث جمع البيانات غير الضرورية.

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

اللقطات غير السلسة

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

عندما يتم رسم اللقطات مع الحاجة إلى القليل من العمل من التطبيق، تحدث نقاط التتبُّع Choreographer.doFrame() بمعدّل تكرار يبلغ 16.7 ملي ثانية على جهاز بمعدّل 60 لقطة في الثانية:

الشكل 3. تتبُّع يعرض اللقطات السريعة المتكرّرة

إذا صغّرت العرض وتنقّلت خلال التتبُّع، ستلاحظ أحيانًا أنّ إكمال اللقطات يستغرق وقتًا أطول قليلاً، ولكن ليس أكثر من الوقت المخصّص لها وهو 16.7 ملي ثانية. هذه اللقطات مقبولة:

الشكل 4. تتبُّع يعرض لقطات سريعة متكررة مع دفعات دورية من العمل.

عندما تلاحظ حدوث انقطاع في هذا التسلسل المنتظم، يكون ذلك بسبب إطار غير سلس، كما هو موضّح في الشكلين 5 و6:

الشكل 5. تتبُّع يعرض إطارًا غير سلس.

الشكل 6. تتبُّع يعرض المزيد من اللقطات غير السلسة

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

لمزيد من المعلومات عن تحسين أداء Compose، يمكنك الاطّلاع على أداء Jetpack Compose. لمزيد من المعلومات حول تحديد اللقطات غير السلسة وتصحيح أسبابها، يُرجى الاطّلاع على العرض البطيء.

الأخطاء الشائعة في التصميم الكسول

يمكن أن يؤدي إبطال حالة التخزين المؤقت الكاملة للتنسيق الكسول بدون داعٍ إلى عمليات إعادة التكوين المفرطة، وأوقات عرض طويلة للإطارات، وحدوث إيقاف مؤقت لعرض واجهة المستخدم. لتقليل عدد عناصر القائمة التي تحتاج إلى تعديل، استخدِم مفاتيح العناصر لعناصرك وعدِّل فقط عناصر الحالة المحدّدة التي تتغيّر.

راجِع استخدام مفاتيح التنسيق الكسول للتعرّف على طرق تجنُّب عمليات إعادة التخصيص الكاملة والمكلفة للقوائم، والتي تؤدي إلى تعديل المحتوى بدلاً من استبداله بالكامل.

يمكن أن يؤدي التنفيذ غير السليم لقوائم التمرير المتداخلة إلى انخفاض الأداء. تجنَّب دمج تخطيط كسول قابل للتمرير داخل حاوية أخرى قابلة للتمرير بدون قيود صريحة. لمزيد من المعلومات، يُرجى الاطّلاع على تجنُّب تضمين مكوّنات قابلة للتمرير في الاتجاه نفسه.

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

تصحيح أخطاء تطبيقك

في ما يلي طرق لتصحيح أخطاء أداء تطبيقك.

تصحيح أخطاء بدء تشغيل التطبيق باستخدام Systrace

راجِع مقالة وقت بدء تشغيل التطبيق للحصول على نظرة عامة على عملية بدء تشغيل التطبيق، وشاهِد الفيديو التالي للحصول على نظرة عامة على تتبُّع النظام واستخدام أداة تحليل الأداء في "استوديو Android".

يمكنك إزالة الغموض عن أنواع الشركات الناشئة في المراحل التالية:

• التشغيل على البارد: يبدأ بإنشاء عملية جديدة بدون حالة محفوظة.
• إعادة التشغيل البطيء: إما إعادة إنشاء النشاط مع إعادة استخدام العملية أو إعادة إنشاء العملية مع الحالة المحفوظة
• إعادة تشغيل سريع: يعيد تشغيل النشاط ويبدأ من التضخّم.

ننصحك بتسجيل عمليات تتبُّع النظام باستخدام تطبيق "تتبُّع النظام" على الجهاز. على نظام التشغيل Android 10 والإصدارات الأحدث، استخدِم أداة Perfetto. في نظام التشغيل Android 9 والإصدارات الأقدم، استخدِم أداة Systrace. ننصحك أيضًا بعرض ملفات التتبُّع باستخدام أداة عرض Perfetto المستندة إلى الويب. لمزيد من المعلومات، يُرجى الاطّلاع على نظرة عامة على تتبُّع النظام.

في ما يلي بعض الأمور التي يجب البحث عنها:

• مراقبة التنازع: يمكن أن يؤدي التنافس على الموارد المحمية بواسطة المراقبة إلى تأخير كبير في بدء تشغيل التطبيق.

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

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

• عمليات الإدخال والإخراج: تحقَّق من عمليات الإدخال والإخراج التي تم تنفيذها أثناء بدء التشغيل، وابحث عن حالات التوقف الطويل.

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

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

استخدام "تتبُّع نشاط النظام" على الجهاز

يمكنك استخدام تطبيق على مستوى النظام يُسمى "تتبُّع نشاط النظام" لتسجيل تتبُّع نشاط النظام على أحد الأجهزة. يتيح لك هذا التطبيق تسجيل عمليات تتبُّع من الجهاز بدون الحاجة إلى توصيله أو ربطه بخدمة adb.

استخدام "محلّل الذاكرة" في "استوديو Android"

يمكنك استخدام محلّل الذاكرة في "استوديو Android" لفحص ضغط الذاكرة الذي قد يكون ناتجًا عن تسرُّب الذاكرة أو أنماط الاستخدام السيئة. ويوفّر عرضًا مباشرًا لعمليات تخصيص الكائنات.

يمكنك حلّ مشاكل الذاكرة في تطبيقك باستخدام أداة Memory Profiler لتتبُّع سبب حدوث عمليات جمع البيانات غير الضرورية وعدد مرات حدوثها.

لتحديد ملف تعريف ذاكرة التطبيق، اتّبِع الخطوات التالية:

1. رصد مشاكل الذاكرة

   سجِّل جلسة لتحديد المشاكل في الذاكرة في رحلة المستخدم التي تريد التركيز عليها. ابحث عن زيادة في عدد العناصر، كما هو موضّح في الشكل 7، ما يؤدي في النهاية إلى عمليات جمع البيانات غير الضرورية، كما هو موضّح في الشكل 8.

   الشكل 7. زيادة عدد العناصر

   الشكل 8. عمليات جمع البيانات غير الضرورية

   بعد تحديد رحلة المستخدم التي تزيد من ضغط الذاكرة، حلِّل الأسباب الجذرية لضغط الذاكرة.

2. تشخيص نقاط الضغط المرتفع في الذاكرة

   اختَر نطاقًا في المخطط الزمني لعرض كل من عمليات التخصيص والحجم السطحي، كما هو موضّح في الشكل 9.

   الشكل 9. قيم عمليات التخصيص والحجم السطحي

   تتوفّر عدة طرق لترتيب هذه البيانات. في ما يلي بعض الأمثلة على كيفية مساعدة كل طريقة عرض في تحليل المشاكل.

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

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

   • الترتيب حسب سلسلة استدعاء الدوال البرمجية: مفيد عندما تريد العثور على مسار سريع يتم فيه تخصيص الذاكرة، مثلاً داخل حلقة أو داخل دالة معيّنة تنفّذ الكثير من عمليات التخصيص.

   • الحجم السطحي: يتتبّع فقط ذاكرة العنصر نفسه. ويكون ذلك مفيدًا لتتبُّع الفئات البسيطة التي تتألف في معظمها من قيم أولية.

   • الحجم المحتفظ به: يعرض إجمالي الذاكرة بسبب العنصر نفسه بالإضافة إلى أي مراجع يشير إليها العنصر فقط. وهي مفيدة لتتبُّع ضغط الذاكرة الناتج عن الكائنات المعقّدة. للحصول على هذه القيمة، عليك إجراء تفريغ كامل للذاكرة، كما هو موضّح في الشكل 10. تمت إضافة المساحة المستعادة في الذاكرة كعمود، كما هو موضّح في الشكل 11.

     الشكل 10. تفريغ كامل للذاكرة

     

3. قياس تأثير التحسين

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

   لقياس تأثير التحسين، قِس في المخطط الزمني لأداة Profiler الوقت بين عمليات جمع البيانات غير الضرورية. تؤدي التأثيرات الإيجابية إلى إطالة الفترة الزمنية بين عمليات جمع البيانات غير الضرورية.

   في ما يلي التأثيرات النهائية لتحسينات الذاكرة:

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