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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ننصحك باتّباع سير العمل التالي لتحديد مشاكل الأداء ومعالجتها:

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

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

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

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

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

• نطاقات فلاتر الأهداف: أضِف autoVerify إلى فلاتر الأهداف لعناوين 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، وبالتالي مقدار الترجمة الفورية في الخلفية (JIT) التي يمكن أن تتسبّب في حدوث تداخل كبير. يؤدي استخدام 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 لـ Microbenchmarks. تنفّذ هذه البرامج النصية الإجراءات التالية، من بين إجراءات أخرى:

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

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

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

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

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

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

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

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

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

في المثال التالي، كل 10 ثوانٍ أثناء عملية طويلة الأمد هو مؤشر على أنّ التطبيق قد يخصّص الذاكرة بشكل غير ضروري ولكن بشكل ثابت بمرور الوقت:

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

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

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

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

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

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

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

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

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

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

يمكنك التدرب على تحديدها.

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

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

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

الأخطاء الشائعة في RecyclerView

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

راجِع مقالة عرض البيانات الديناميكية للتعرّف على طرق تجنُّب طلبات notifyDatasetChanged() المكلفة التي تؤدي إلى تعديل المحتوى بدلاً من استبداله بالكامل.

إذا لم يتم التعامل مع كل RecyclerView متداخل بشكل صحيح، قد يؤدي ذلك إلى إعادة إنشاء RecyclerView الداخلي بالكامل في كل مرة. يجب أن يحتوي كل RecyclerView داخلي ومتداخل على مجموعة RecycledViewPool للمساعدة في ضمان إمكانية إعادة استخدام طرق العرض بين كل RecyclerView داخلي.

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

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

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

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

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

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

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

ننصحك بتسجيل عمليات Systrace باستخدام تطبيق "تتبّع النظام" على الجهاز. على نظام التشغيل 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 عنصر من فئة تسمى "Vertex" كل ثانية، سيزيد عدد عمليات التخصيص بمقدار 2,000 كل ثانية، ويمكنك الاطّلاع على ذلك عند الترتيب حسب الفئة. إذا أردت إعادة استخدام هذه العناصر لتجنُّب إنشاء بيانات غير مرغوب فيها، عليك تنفيذ مجموعة ذاكرة.

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

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

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

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

     

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

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

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

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

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