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

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

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

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

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

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

اسعَ إلى تحقيق أهداف بدء التشغيل التالية في تطبيقاتك:

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

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

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

أعطال التمرير

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

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

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

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

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

نقاط قصور في الطاقة

يقلل أداء العمل من شحن البطارية، ويؤدي القيام بالأعمال غير الضرورية إلى تقليل عمر البطارية.

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

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

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

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

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

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

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

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

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

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

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

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

نقاط التتبّع

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

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

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

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

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

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

تجميع تطبيقك على الجهاز فقط لحالة معروفة، وهي عادةً speed أو speed-profile قد تكون أعباء العمل في الخلفية فقط (JIT) ناتجة عن زيادة كبيرة في الأداء، وتصل إلى هذا العدد كثيرًا في حال إعادة تثبيت حزمة APK بين عمليات الاختبار. فيما يلي أمر للقيام بذلك:

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

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

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

أما مقياس الأداء الماكرو، فيتيح لك تحديد وضع التجميع مباشرةً.

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

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

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

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

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

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

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

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

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

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

عمليات توزيع غير ضرورية تؤدي إلى تجميع البيانات المهملة بشكل متكرر

قد تلاحظ حدوث مجموعات البيانات المهملة (GCs) بشكل متكرر أكثر مما تتوقعه في 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

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

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

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

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

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

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

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

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

• I/O: ابحث عن بيانات مؤتمر I/O التي تم تنفيذها أثناء بدء التشغيل، وابحث عن الأكشاك الطويلة.

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

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

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

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

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

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

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

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

1. اكتشاف مشاكل الذاكرة

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

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

   الشكل 8. مجموعات القمامة

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

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

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

   الشكل 9. قيم التخصيصات والحجم الضحل

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

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

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

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

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

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

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

     

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

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

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

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

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

أفلام مُقترَحة لك

• ملاحظة: يظهر نص الرابط عند إيقاف JavaScript
• تحليل وتحسين بدء تشغيل التطبيقات {:#app-startup-analysis-optimization}
• الإطارات الثابتة
• كتابة مقياس ماكرو