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

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

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

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

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

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

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

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

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

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

تعطُّل التمرير

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

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

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

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

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

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

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

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

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

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

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

1. حدِّد رحلات المستخدم الأساسية التالية وافحصها:
   • عمليات بدء التشغيل الشائعة، بما في ذلك من مشغّل التطبيقات والإشعارات
   • الشاشات التي يتنقّل فيها المستخدم بين البيانات
   • الانتقالات بين الشاشات
   • عمليات طويلة الأمد، مثل التنقّل أو تشغيل الموسيقى
2. يمكنك فحص ما يحدث أثناء عمليات التدفق السابقة باستخدام أدوات تصحيح الأخطاء التالية:
   • Perfetto: تتيح لك هذه الأداة الاطّلاع على ما يحدث على مستوى الجهاز بالكامل من خلال بيانات التوقيت الدقيق.
   • أداة Memory Profiler: تتيح لك الاطّلاع على عمليات تخصيص الذاكرة التي تحدث في الذاكرة المؤقتة.
   • 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الوضع بيانات طرق التطبيق وفئاته وفقًا لملف شخصي لمسارات الرموز المستخدَمة التي يتم جمعها أثناء استخدام التطبيق. قد يكون من الصعب جمع الملفات الشخصية بشكل منتظم وصحيح، لذا إذا قررت استخدامها، تأكَّد من أنّها تجمع البيانات التي تتوقّعها. تتوفّر الملفات الشخصية في الموقع التالي:

/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 Studio.

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

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

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

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

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

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

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

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

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

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

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

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

   الشكل 8. عمليات جمع البيانات المهملة

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

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

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

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

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

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

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

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

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

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

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

     

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

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

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

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

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