الحفاظ على استجابة تطبيقك

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

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

مشغِّلات ANR

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

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

في Android، يتم مراقبة استجابة التطبيق من خلال خدمتَي النظام ActivityManager وWindowManager. يعرض Android مربع حوار ANR لتطبيق عندما يرصد أحد الحالات التالية:

• عدم الاستجابة لحدث إدخال، مثل الضغط على المفتاح أو أحداث النقر على الشاشة، في غضون 5 ثوانٍ
• لا ينتهي تنفيذ BroadcastReceiver خلال مدة تتراوح بين 10 و20 ثانية، وذلك لأغراض في المقدّمة. لمزيد من المعلومات، يُرجى الاطّلاع على مهلة جهاز استقبال البث.

تجنُّب أخطاء ANR

في ما يلي نصائح عامة لتجنّب أخطاء ANR. ولمزيد من التفاصيل حول تشخيص الأنواع المختلفة من أخطاء ANR وتصحيحها، يُرجى الاطّلاع على الصفحات الأخرى في هذا القسم.

• أبقِ سلسلة التعليمات الرئيسية غير محظورة في جميع الأوقات، واستخدِم سلاسل المحادثات بشكل استراتيجي.

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

  • حاول تقليل أي تزايد زائد بين سلسلة التعليمات الرئيسية والسلاسل الأخرى.

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

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

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

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

  • إذا كنت تستخدم goAsync()، تأكَّد من استدعاء PendingResult.finish بسرعة قبل انتهاء مهلة خطأ ANR.

أخطاء ANR في BroadcastBroadcastr

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

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

تعزيز الاستجابة

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

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

• بالنسبة إلى الألعاب على وجه التحديد، عليك إجراء عمليات حسابية للحركات في سلسلة التعليمات.

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

• استخدم أدوات الأداء مثل Perfetto وCPU Profiler لتحديد المؤثِّرات السلبية في استجابة تطبيقك.