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

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

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

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

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

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

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

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

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

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

الانتقال غير السلس للأسفل أو للأعلى

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

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

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

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

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

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

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

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

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

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

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

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

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

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

مشاكل في إثبات ملكية روابط التطبيقات

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

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

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

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

نقاط التتبّع

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

أثناء تسجيل عمليات التتبّع، يتسبب التتبّع في زيادة طفيفة في وقت الاستجابة تبلغ تقريبًا 5μs لكل قسم، لذا لا تضعه حول كل طريقة. يمكن أن يؤدي تتبُّع أجزاء أكبر من العمل التي تزيد مدتها عن 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 لإجراء قياسات الأداء الدقيقة. وتشمل هذه النصوص البرمجية، من بين أمور أخرى، ما يلي:

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

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

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

بطء بدء تشغيل التطبيق: نشاط غير ضروري في أداة Trampoline

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

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

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

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

قد تلاحظ أنّ عمليات جمع المهملات تحدث بمعدلٍ أعلى مما هو متوقّع في Systrace.

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

الشكل 2: تتبُّع يعرض المساحة بين أحداث جمع القمامة

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

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

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

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

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

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

الشكل 4. تتبع يعرض لقطات سريعة متكررة مع ذروات دورية للعمل

عندما تلاحظ انقطاعًا في هذا الإيقاع المنتظم، يعني ذلك أنّ هناك لقطة متقطعة، كما هو موضّح في الشكل 5:

الشكل 5: تتبع يعرض إطارًا متقطّعًا

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

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

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

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

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

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

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

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

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

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

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

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

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

يمكنك توضيح أنواع تطبيقات التشغيل في المراحل التالية:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   الشكل 8: عمليات جمع البيانات

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

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

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

   الشكل 9: قيم التوزيعات وShallow Size

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

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

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

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

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

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

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

     

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

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

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

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

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