مراقبة الجودة الفنية لتطبيقك من خلال "مؤشرات Android الحيوية"

يمكنك استخدام "مؤشرات Android الحيوية" لفهم وتحسين ثبات تطبيقك وأدائه واستخدام البطارية وغير ذلك.

اختيار كيفية الوصول إلى بيانات تطبيقك

هناك طريقتان لاستخدام ميزة "مؤشرات Android الحيوية"، وهما: Play Console وواجهة برمجة التطبيقات Plaِy Developer Reporting API.

توفّر واجهة برمجة التطبيقات إمكانية الوصول الآلي إلى "مؤشرات Android الحيوية" للمطوّرين الذين يريدون دمج بيانات هذه المؤشرات مع مجموعات بيانات أخرى أو دمجها في سير عملهم. للتعرُّف أكثر على كيفية استخدام واجهة برمجة التطبيقات للوصول إلى "مؤشرات Android الحيوية"، يُرجى الانتقال إلى صفحة Google Play Developer Reporting API.

للاطّلاع على بيانات "مؤشرات Android الحيوية" الخاصة بتطبيقك ومراجعتها في Play Console، يُرجى اتّباع الخطوات التالية:

1. افتح Play Console.
2. اختر أحد التطبيقات.
3. في القائمة اليمنى، انقر على الجودة > مؤشرات Android الحيوية > نظرة عامة.
4. اختر نطاق البيانات الذي تريد الاطّلاع عليه باستخدام أداة اختيار النطاق الزمني في أعلى يسار الصفحة.

ملاحظة مهمة: إذا لم تتوفّر أي بيانات، يعني ذلك أنّ تطبيقك لا يحتوي على نقاطِ بيانات كافية ضِمن الفلاتر المحدّدة لتحديد أي مشاكل.

مراقبة مؤشرات الأداء الأساسية لتطبيقك

في أعلى صفحة نظرة عامة، يمكنك الاطِّلاع على بيانات عن مؤشرات الأداء الأساسية لتطبيقك. هذه هي أهم المقاييس الفنية التي تؤثر في قابلية اكتشاف تطبيقك على Google Play. تشمل مؤشرات الأداء الأساسية ما يلي:

• نسبة أخطاء ANR التي لاحظها المستخدمون
• نسبة الأعطال التي لاحظها المستخدمون

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

يمكنك استخدام قسم "مشاكل حرجة" للتعرف سريعًا على الجوانب التي يمكن تحسين تطبيقك فيها. هناك نوعان من المشاكل الحرجة:

• الأداء السيئ: المقاييس التي تتجاوز معايير تحديد الأداء السيئ
• القيم الشاذة: التغيرات المهمة في البيانات (على سبيل المثال، زيادة حادة في نسبة أخطاء ANR التي لاحظها المستخدمون)

لتلقّي إشعارات عبر البريد الإلكتروني، انتقِل إلى الإعداد > الإشعارات أو انقر على إدارة الإشعارات في زاوية قسم "مؤشرات الأداء الأساسية" (الجودة > مؤشرات Android الحيوية > نظرة عامة). تجدر الإشارة إلى أنّ الإشعارات لا تتوفّر حاليًا إلا للقيم الشاذة.

تصفُّح جميع المؤشرات الحيوية

في منتصف صفحة نظرة عامة، يمكنك عرض بيانات جميع المؤشرات الحيوية حسب مقياس الجودة.

في الجدول، يمكنك مراجعة المقاييس للفترتين الزمنيتين الحالية والسابقة. يمكنك أيضًا الاطِّلاع على مستوى أداء تطبيقك مقارنةً بالتطبيقات الأخرى على Google Play.

عرض المقاييس التفصيلية

للاطّلاع على تفاصيل إضافية عن مقياسٍ معيّن، انقر على رمز عرض التفاصيل () بجانبه. في الشاشة التالية، يمكنك مراجعة ما يلي:

• معايير تحديد الأداء السيئ
• مقاييس أداء الفئات
• مقارنات تفصيلية بين مقاييس الأداء
  • انتقِل إلى بطاقة مقارنة التطبيقات المشابهة في أعلى الصفحة، واختَر تعديل مجموعة التطبيقات المشابهة لتعديل مجموعة تطبيقات مشابهة مخصّصة. وبعد إنشاء مجموعة تطبيقات مشابهة مخصّصة، يمكنك معرفة مستوى تطبيقك مقارنةً بالتطبيقات الأخرى التي تختارها على Google Play.
• مؤشر المقياس بمرور الوقت

تحليل البيانات باستخدام السمات

لمساعدتك في تنظيم بياناتك وتقسيمها وتحليلها، يتم تقسيم المقاييس حسب عدد من السمات المختلفة. وتتضمّن جميع المقاييس التصنيفات التالية:

• العنصر: يشير ذلك إلى إصدار تطبيقك الذي حدثت فيه المشكلة.
• إصدار Android (حزمة تطوير البرامج (SDK)): يشير ذلك إلى إصدار نظام التشغيل Android الذي سجَّله جهاز المستخدم.
• شكل الجهاز: يشير ذلك إلى نوع الجهاز الذي تم تشغيل التطبيق عليه (على سبيل المثال، هاتف أو جهاز لوحي أو تلفزيون أو جهاز قابل للارتداء).
• طراز الجهاز: يشير ذلك إلى وصف عام للجهاز يتكون من علامة تجارية فريدة ومعرِّف الجهاز، على سبيل المثال "Google oriole". قد يكون لطراز الجهاز الواحد خيارات مختلفة من إصداراتِ Android أو ذاكرة الوصول العشوائي (RAM) أو سعة التخزين أو المنظومة على الرقاقة (SoC).
• البلد/المنطقة: يشير ذلك إلى الموقع الجغرافي الذي سجَّله جهاز المستخدم عند حدوث المشكلة.

ملاحظة: للاطِّلاع على تصنيفات حسب جوانب محدّدة من معدّات أو برامج الجهاز (على سبيل المثال، طراز الجهاز أو إصدار Android)، يمكنك النقر على الرمز () بجانب العنصر في الجدول.

تحتوي بعض المقاييس على تصنيفات إضافية:

• اسم قفل التنشيط: يشير ذلك إلى العلامات التي تم إعدادها آليًا عند استخدام PowerManager API في تطبيقك.
• اسم التنشيط: يشير ذلك إلى العلامات التي تم إعدادها آليًا عند استخدام AlarmManager API في تطبيقك.
• اسم نشاط ANR: يشير ذلك إلى اسم مؤهَّل بالكامل لفئة النشاط التي حدث فيها خطأ ANR (إذا كان متاحًا).
• نوع ANR: يشير ذلك إلى وقت حدوث خطأ ANR (أثناء تنفيذ خدمة مثلاً) (إذا كان متاحًا).

يمكنك الاطّلاع على المزيد من التفاصيل في حال توفّرها (على سبيل المثال، تفاصيل عن العطل أو مجموعات أخطاء ANR المرتبطة بهذا التصنيف) من خلال اختيار عرض التفاصيل () بجانب العنصر.

ملاحظة: يمكنك التبديل بين المقاييس في فئة واحدة باستخدام مفتاح التبديل أعلى الشاشة ومن ثمَّ فلترة الصفحة.

أنواع البيانات والمقاييس

تتوفر بيانات "مؤشرات Android الحيوية" لآخر 90 يومًا في Play Console ولمدة ثلاث سنوات في Play Developer Reporting API.

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

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

ملاحظة: تستبعد مقاييس "مؤشرات Android الحيوية" المشاكل الفنية التي تحدث على طُرز الأجهزة غير المعتمَدة أو في إصدارات تطبيقك التي لم يتم تثبيتها من خلال Google Play.

تصغير الكل توسيع الكل

الثبات

مقاييس نسبة أخطاء ANR

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

تتوفّر ثلاثة مقاييس لنسبة أخطاء ANR:

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

حل مشكلة

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

يقدّم موقع "مطوّرو تطبيقات Android" الإلكتروني إرشادات حول تشخيص أخطاء ANR وإصلاحها.

مقاييس نسبة الأعطال

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

تتوفّر ثلاثة مقاييس لنسبة الأعطال:

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

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

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

حل مشكلة

يقدّم موقع "مطوّرو تطبيقات Android" الإلكتروني إرشادات حول تشخيص الأعطال وإصلاحها.

مدة بدء التشغيل والتحميل

مدة بدء التشغيل (الوقت المُستغرَق للعرض الأولي)

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

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

تفاصيل جمع البيانات

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

تفاصيل المؤشر الحيوي

• الجلسات المتأثرة: النسبة المئوية للجلسات التي واجه خلالها المستخدمون تأخُّر بدء التشغيل في كل حالة للنظام ذات الصلة:
  • التشغيل على البارد المتأخِّر: 5 ثوانٍ أو أكثر
  • إعادة التشغيل البطيء المتأخِّر: ثانيتان أو أكثر
  • إعادة التشغيل السريع المتأخِّر: ثانية واحدة أو أكثر
• عدد الجلسات: يعرض العدد التقريبي للجلسات المسجّلة.
• الشريحة المئوية التسعون/التاسعة والتسعون: %10‏/1% من جلسات المستخدمين اليومية التي تأخَّر فيها بدء تشغيل تطبيقك.

حل مشكلة

إذا تم تسجيل العديد من مرات تأخُّر بدء تشغيل تطبيقك، انتقِل إلى موقع "مطوّرو تطبيقات Android" الإلكتروني للاطّلاع على الحلول المُقترَحة.

العرض

مقاييس جميع اللقطات المعروضة

معدّل الجلسات البطيئة (30 أو 20 لقطة في الثانية) [الألعاب فقط]

سبب أهمية ذلك

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

فهم بيانات تطبيقك

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

من المفترض أن تعمل معظم الألعاب على Google Play بمعدّل 30 لقطة في الثانية أو أكثر. وهذا يوفر تجربة معقولة للمستخدمين، بغض النظر عن نوع اللعبة التي يلعبونها (على الرغم من أنّ بعض المستخدمين يفضّلون 60 لقطة في الثانية على الأقل، خاصةً على الأجهزة المتطورة). راقِب مقياس معدّل الجلسات البطيئة (30 لقطة في الثانية) للتأكُّد من تحقيق هذا المعدّل. يُرجى العِلم أنّ هذا المقياس لا يشمل سوى الجلسات التي تكون فيها سرعة عرض أكثر من %25 من اللقطات متأخرة عن معدّل 30 لقطة في الثانية، وهذا يعني أنّ هناك بعض التساهل في هذا المقياس مع تغيُّر عدد اللقطات في الثانية.

على الرغم من أنّ معدّل 30 لقطة في الثانية يوفّر تجربة استخدام معقولة، ولكن قد يكون من المنطقي في بعض الأحيان أو في بعض أنواع الألعاب خفض عدد اللقطات إلى أقل من هذا المعدل، أو قد يرغب المستخدمون في تشغيل لعبتك على هواتف غير متوافقة مع معدّل 30 لقطة في الثانية. في هذه السيناريوهات، يجب أن تُعرَض على الأقل %75 من اللقطات في الجلسة الواحدة بمعدّل 20 لقطة في الثانية أو أعلى. راقِب مقياس معدّل الجلسات البطيئة (20 لقطة في الثانية) للتأكّد من تحقيق هذا المعدّل.

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

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

تفاصيل جمع البيانات

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

يتم جمع بيانات عدد اللقطات في الثانية بالنسبة إلى الجلسات البطيئة على الأجهزة التي تعمل بإصدار Android 9 والإصدارات الأحدث.

عرض لوحة البيانات

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

حل مشكلة

إذا تم تسجيل العديد من الجلسات البطيئة لتطبيقك، انتقِل إلى موقع "مطوّرو تطبيقات Android" الإلكتروني للاطّلاع على الحلول المُقترَحة.

عرض مجموعة أدوات واجهة المستخدم من Android

اللقطات البطيئة على نحو مُفرط [التطبيقات فقط]

فهم بيانات تطبيقك

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

تفاصيل جمع البيانات

تجمع Google بيانات الوقت المستغرق لعرض كل لقطة في تطبيقك عند استخدام إطار عمل أدوات واجهة المستخدم. ولا يتم جمع اللقطات المعروضة باستخدام OpenGL أو Vulkan بشكل مباشر.

عرض لوحة البيانات

عند تحديد صف، ستظهر لك البيانات مقسّمة إلى شرائحَ مئوية.

• الجلسات المتأثرة: تعرض النسبة المئوية لجلسات المستخدمين اليومية التي استغرق فيها عرض أكثر من %50 من اللقطات وقتًا أطول من 16 ملي ثانية. وتشير الجلسة اليومية إلى يوم معيّن تم خلاله استخدام تطبيقك. على سبيلِ المثال، إذا استخدم فردان التطبيق لمدة يومين، سينتج عن ذلك أربع جلسات يومية.
• عدد الجلسات: يعرض العدد التقريبي للجلسات المسجّلة.
• الشريحة المئوية التسعون/التاسعة والتسعون: استغرق عرض %90‏/99% من إجمالي اللقطات وقتًا أقل من الرقم الظاهر. تستند هذه الأرقام إلى جميع اللقطات التي تم جمعها.

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

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

• أحداث vsyncs التي تم تفويتها: بالنسبة إلى كل اللقطات التي تزيد مدة عرضها عن 16 ملي ثانية، يُحتسَب هذا المقياس بتسجيل عدد أحداث vsyncs التي تم تفويتها، وقسمة هذا العدد على عدد اللقطات.
• وقت استجابة إدخال مرتفع: بالنسبة إلى جميع اللقطات التي تزيد مدة عرضها عن 16 ملي ثانية، يُحتسَب هذا المقياس بتسجيل عدد أحداث الإدخال التي استغرقت أكثر من 24 ملي ثانية، وقسمة هذا العدد على عدد اللقطات.
• سلسلة واجهة المستخدم البطيئة: بالنسبة إلى كل اللقطات التي تزيد مدة عرضها عن 16 ملي ثانية، يُحتسَب هذا المقياس بتسجيل عدد المرات التي استغرق فيها إكمال سلسلة واجهة المستخدم أكثر من 8 ملي ثانية، وقسمة هذا العدد على عدد اللقطات.
• أوامر الرسم التي تم تنفيذها ببطء: بالنسبة إلى كل اللقطات التي تزيد مدة عرضها عن 16 ملي ثانية، يُحتسَب هذا المقياس بتسجيل عدد المرات التي استغرق فيها إرسال أوامر الرسم إلى وحدة معالجة الرسومات أكثر من 12 ملي ثانية، وقسمة هذا العدد على عدد اللقطات.
• عمليات تحميل الصور النقطية البطيئة: بالنسبة إلى كل اللقطات التي تزيد مدة عرضها عن 16 ملي ثانية، يُحتسَب هذا المقياس بتسجيل عدد المرات التي استغرق فيها تحميل الصورة النقطية إلى وحدة معالجة الرسومات أكثر من 3.2 ملي ثانية، وقسمة هذا العدد على عدد اللقطات.

حل مشكلة

إذا تم تسجيل العديد من اللقطات التي تزيد مدة عرضها في تطبيقك عن 16 ملي ثانية، انتقِل إلى موقع "مطوّرو تطبيقات Android" الإلكتروني للاطّلاع على الحلول المقترَحة.

اللقطات الثابتة على نحوٍ مفرط [التطبيقات فقط]

فهم بيانات تطبيقك

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

تفاصيل جمع البيانات

تجمع Google بيانات الوقت المستغرق لعرض كل لقطة في تطبيقك عند استخدام إطار عمل أدوات واجهة المستخدم. ولا يتم جمع اللقطات المعروضة باستخدام OpenGL أو Vulkan بشكل مباشر.

عرض لوحة البيانات

عند تحديد صف، ستظهر لك البيانات مقسّمة إلى شرائحَ مئوية.

• الجلسات المتأثرة: تعرض النسبة المئوية لجلسات المستخدمين اليومية التي استغرق فيها عرض أكثر من %50 من اللقطات وقتًا أطول من 16 ملي ثانية. وتشير الجلسة اليومية إلى يوم معيّن تم خلاله استخدام تطبيقك. على سبيلِ المثال، إذا استخدم فردان التطبيق لمدة يومين، سينتج عن ذلك أربع جلسات يومية.
• عدد الجلسات: يعرض العدد التقريبي للجلسات المسجّلة.
• الشريحة المئوية التسعون/التاسعة والتسعون: استغرق عرض %90‏/99% من إجمالي اللقطات وقتًا أقل من الرقم الظاهر. تستند هذه الأرقام إلى جميع اللقطات التي تم جمعها.

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

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

• أحداث vsyncs التي تم تفويتها: بالنسبة إلى كل اللقطات التي تزيد مدة عرضها عن 16 ملي ثانية، يُحتسَب هذا المقياس بتسجيل عدد أحداث vsyncs التي تم تفويتها، وقسمة هذا العدد على عدد اللقطات.
• وقت استجابة إدخال مرتفع: بالنسبة إلى جميع اللقطات التي تزيد مدة عرضها عن 16 ملي ثانية، يُحتسَب هذا المقياس بتسجيل عدد أحداث الإدخال التي استغرقت أكثر من 24 ملي ثانية، وقسمة هذا العدد على عدد اللقطات.
• سلسلة واجهة المستخدم البطيئة: بالنسبة إلى كل اللقطات التي تزيد مدة عرضها عن 16 ملي ثانية، يُحتسَب هذا المقياس بتسجيل عدد المرات التي استغرق فيها إكمال سلسلة واجهة المستخدم أكثر من 8 ملي ثانية، وقسمة هذا العدد على عدد اللقطات.
• أوامر الرسم التي تم تنفيذها ببطء: بالنسبة إلى كل اللقطات التي تزيد مدة عرضها عن 16 ملي ثانية، يُحتسَب هذا المقياس بتسجيل عدد المرات التي استغرق فيها إرسال أوامر الرسم إلى وحدة معالجة الرسومات أكثر من 12 ملي ثانية، وقسمة هذا العدد على عدد اللقطات.
• عمليات تحميل الصور النقطية البطيئة: بالنسبة إلى كل اللقطات التي تزيد مدة عرضها عن 16 ملي ثانية، يُحتسَب هذا المقياس بتسجيل عدد المرات التي استغرق فيها تحميل الصورة النقطية إلى وحدة معالجة الرسومات أكثر من 3.2 ملي ثانية، وقسمة هذا العدد على عدد اللقطات.

حل مشكلة

إذا تم تسجيل العديد من اللقطات التي تزيد مدة عرضها في تطبيقك عن 16 ملي ثانية، انتقِل إلى موقع "مطوّرو تطبيقات Android" الإلكتروني للاطّلاع على الحلول المقترَحة.

استخدام البطارية

عمليات قفل التنشيط المتوقفة وعمليات قفل التنشيط الجزئية المتوقفة (في الخلفية)

تعرض صفحتَا عمليات قفل التنشيط الجزئية المتوقفة وعمليات قفل التنشيط الجزئية المتوقفة (في الخلفية) عمليات قفل التنشيط الجزئية التي أحدثها تطبيقك من خلال فئة PowerManager. ويضمن قفل التنشيط الجزئي تشغيل وحدة المعالجة المركزية (CPU)، ولكن سيتم السماح بإطفاء الشاشة والإضاءة الخلفية للوحة المفاتيح.

تفاصيل جمع البيانات

• لأغراض الخصوصية، يتم إخفاء هوية علاماتِ تحديد قفل التنشيط الجزئي.
• يتم جمع البيانات عن عمليات قفل التنشيط الجزئي عندما لا يكون الجهاز قيد الشحن وتكون الشاشة مطفأة.
• لا يتم جمع بيانات عمليات قفل التنشيط الجزئية المتوقفة (في الخلفية) إلا عند تشغيل التطبيق في الخلفية.
• تحسب Google الحد الأقصى لمدة قفل التنشيط الجزئي لكل فترة عمل بطارية، لتوضيح عدد الجلسات المتأثرة بقفل التنشيط لفترة طويلة. على سبيل المثال، إذا شغّل المستخدم عمليات قفل تنشيط تبلغ مدتها ساعتين، ستستخدم Google الحد الأقصى لقيمة قفل التنشيط وهي ساعة واحدة.
• بالنسبة إلى التطبيقات التي تضبط sharedUserId في ملف البيان: لن تظهر لك البيانات إلا إذا تم تثبيت تطبيق واحد بحدٍ أقصى يحمل sharedUserId نفسه.

تفاصيل المؤشر الحيوي

• الجلسات المتأثرة: تشير إلى النسبة المئوية لفترات عمل البطارية التي لاحظ المستخدمون خلالها أنّه قد تم إجراء قفل تنشيط واحد على الأقل لمدة تزيد عن ساعة واحدة.
• عدد الجلسات: يعرض العدد التقريبي للجلسات المسجّلة.
• الشريحة المئوية التسعون/التاسعة والتسعون: %10‏/1% من جلسات المستخدمين اليومية التي حدث فيها قفل التنشيط الجزئي بمعدّل أكبر من الرقم المعروض.
• معيار تحديد الأداء السيئ: إذا كان تطبيقك يعرض معدل ورود يساوي أو يزيد عن المعيار الموضّح، يعني ذلك أنّه ضِمن الربع (%25) الأدنى في قائمة أعلى 1,000 تطبيق على Google Play (حسب عدد عمليات التثبيت).

حل مشكلة

إذا تم تسجيل العديد من عمليات قفل التنشيط الجزئية المتوقفة في تطبيقك، انتقِل إلى موقع "مطوّرو تطبيقات Android" الإلكتروني للاطّلاع على الحلول المُقترَحة.

عمليات التنشيط المفرطة

تعرض صفحة عمليات التنشيط المفرطة عمليات تنشيط Alarm Manager التي شغّلها تطبيقك. ستظهر لك بيانات التنشيط للفئة ELAPSED_REALTIME_WAKEUP أو RTC_WAKEUP.

تفاصيل جمع البيانات

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

تفاصيل المؤشر الحيوي

• الجلسات المتأثرة: تشير إلى النسبة المئوية لفترات عمل البطارية التي لاحظ المستخدمون خلالها أنّه قد تم إجراء أكثر من 10 عمليات تنشيط في الساعة. وفترة عمل البطارية هي تجميع لكل تقارير البطارية التي تم تلقّيها خلال فترة 24 ساعة معيّنة. ففي Android 10، يشير تقرير البطارية إلى الفترة التي تفصل بين عمليتَي شحن للبطارية إما من قيمة أقل من %20 إلى أعلى من %80 أو من أي قيمة إلى %100. أمّا في Android 11 والإصدارات الأحدث، يشير تقرير البطارية إلى مدة 24 ساعة ثابتة. ولا تجمع Google البيانات إلا عندما يكون الجهاز مفصولاً عن الشاحن.
• عدد الجلسات: يعرض العدد التقريبي للجلسات المسجّلة.
• الشريحة المئوية التسعون/التاسعة والتسعون: %10‏/1% من جلسات المستخدمين اليومية التي تم فيها إجراء عمليات تنشيط كل ساعة بمعدّل أكبر من القيمة المعروضة.
• معيار تحديد الأداء السيئ: إذا كان تطبيقك يعرض معدل ورود يساوي أو يزيد عن المعيار الموضّح، يعني ذلك أنّه ضِمن الربع (%25) الأدنى في قائمة أعلى 1,000 تطبيق على Google Play (حسب عدد عمليات التثبيت).

حل مشكلة

إذا كانت هناك عمليات تنشيط متكررة لتطبيقك، يُرجى الانتقال إلى الموقع الإلكتروني لمطوّري تطبيقات Android للاطّلاع على الحلول المُقترَحة.

عمليات البحث عن شبكة Wi-Fi الزائدة عن الحد (في الخلفية)

تعرض صفحة عمليات البحث عن شبكة Wi-Fi الزائدة عن الحد (في الخلفية) متى تؤدي عمليات البحث عن شبكات Wi-Fi إلى استهلاك البطارية بشكلٍ كبير.

تفاصيل جمع البيانات

يتم جمع بيانات متعلقة بالبحث عن شبكات Wi-Fi عندما لا يكون الجهاز قيد الشحن ويكون التطبيق في الخلفية.

تفاصيل المؤشر الحيوي

• الجلسات المتأثّرة: تشير إلى النسبة المئوية لفترات عمل البطارية التي لاحظ خلالها المستخدمون إجراء أكثر من 4 عمليات بحث عن شبكة Wi-Fi في الساعة الواحدة.
• عدد الجلسات: يعرض العدد التقريبي للجلسات المسجّلة.
• الشريحة المئوية التسعون/التاسعة والتسعون: %10‏/1% من جلسات المستخدمين اليومية التي شهدت عمليات بحث عن شبكة Wi-Fi في الخلفية كل ساعة بمعدّل أكبر من الرقم المعروض.

حل مشكلة

إذا كان تطبيقك لديه عدد كبير من عمليات البحث عن شبكة Wi-Fi في الخلفية، انتقِل إلى الموقع الإلكتروني لمطوّري تطبيقات Android للاطّلاع على الحلول المُقترَحة.

الاستخدام الزائد عن الحد للشبكة (في الخلفية)

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

تفاصيل جمع البيانات

يتم جمع البيانات عن استخدام شبكة الجوّال عندما لا يكون الجهاز قيد الشحن ويكون التطبيق مُشغَّلاً في الخلفية.

تفاصيل المؤشر الحيوي

• الجلسات المتأثرة: تشير إلى النسبة المئوية لفترات عمل البطارية التي لاحظ المستخدمون خلالها استهلاك أكثر من 50 ميغابايت من بيانات الشبكة في الخلفية في اليوم.
• عدد الجلسات: يعرض العدد التقريبي للجلسات المسجّلة.
• الشريحة المئوية التسعون/التاسعة والتسعون: %10‏/1% من جلسات المستخدمين اليومية التي زاد فيها معدل استخدام الشبكة اليومي في الخلفية عن الرقم المعروض.

حل مشكلة

إذا تم تسجيل معدّل مرتفع لاستخدام الشبكة في الخلفية من قِبل تطبيقك، انتقِل إلى موقع "مطوّرو تطبيقات Android" الإلكتروني للاطّلاع على الحلول المُقترَحة.

الأذونات

عمليات رفض الأذونات

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

تفاصيل جمع البيانات

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

تفاصيل المؤشر الحيوي

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

حل مشكلة

إذا تم تسجيل عدد كبير من عمليات رفض أذونات تطبيقك، انتقِل إلى موقع "مطوّرو تطبيقات Android" الإلكتروني للاطّلاع على الحلول المقترَحة.

معايير تحديد الأداء السيء لمؤشرات الأداء الأساسية

حدّد Google Play معايير تحديد الأداء السيئ في مؤشرات الأداء الأساسية لتطبيقك.

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

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

تصغير الكل توسيع الكل

الثبات

معايير تحديد نسبة أخطاء ANR التي لاحظها المستخدمون

حدّد Google Play معايير تحديد الأداء السيء من حيث نسبة أخطاء ANR التي لاحظها المستخدمون، وهي:

• الأداء السيء العام: يواجه ما لا يقل عن %0.47 من المستخدمين النشطين يوميًا خطأ ANR ملحوظًا لهم في جميع طُرز الأجهزة.

• الأداء السيئ حسب الجهاز: يواجه %8 على الأقل من المستخدمين النشطين يوميًا خطأ ANR ملحوظًا لهم في طراز جهاز معيّن.

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

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

معايير نسبة الأعطال التي لاحظها المستخدمون

وضع Google Play معاييرًا لتحديد الأداء السيء من حيث نسبة الأعطال التي لاحظها المستخدمون، وهي:

• الأداء السيء العام: يواجه ما لا يقل عن %1.09 من المستخدمين اليوميين عُطلاً ملحوظًا في جميع طُرز الأجهزة.

• الأداء السيئ حسب الجهاز: يواجه ما لا يقل عن %8 من المستخدمين اليوميين عُطلاً ملحوظًا في طراز جهاز معيّن.

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

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

محتوى ذو صلة

اطّلِع على أفضل الممارسات لاستخدام "مؤشرات Android الحيوية" لتحسين أداء تطبيقك وثباته.