يُعدّ ANR (Application Not Responding) حالة الخطأ في Android التي يتوقف فيها التطبيق عن الاستجابة لإدخال المستخدم لفترة ممتدة. وعندما يحدث ذلك، قد يعرض النظام مربع حوار يمنح المستخدم خيار الانتظار أو إغلاق التطبيق. والسبب المعتاد أن الخيط الرئيسي للتطبيق، الذي يُسمى أيضًا خيط واجهة المستخدم، منشغل بعمل مستهلك للوقت مثل الاستدعاءات الشبكية أو استعلامات قواعد البيانات الكبيرة أو الحسابات الثقيلة، أو أنه ينتظر قفلًا يحتفظ به خيط آخر.
ومن بين حالات أخرى، يُطلق Android حالة ANR إذا لم يستجب التطبيق لحدث إدخال، مثل نقرة على الشاشة، خلال خمس ثوانٍ، أو إذا لم ينته مستقبل البث أو خدمة ضمن الحدود الزمنية المحددة. وتُعدّ حالات ANR مؤشر جودة مهمًا لأنها تخلق تجربة مستخدم سيئة، وتراقب Google Play معدل ANR عبر Android vitals، حيث قد يؤثر المعدل المرتفع في ظهور التطبيق في المتجر. ويمنع المطورون حالات ANR بنقل العمل الثقيل بعيدًا عن الخيط الرئيسي، مثلًا باستخدام الروتينات المشتركة في Kotlin أو WorkManager.
يُعدّ ANR (Application Not Responding) حالة في تطبيقات Android لا يستجيب فيها التطبيق لإدخال المستخدم ضمن إطار زمني معين، هو عادة 5 ثوانٍ. وقد ينتج ذلك عن عمليات طويلة على الخيط الرئيسي تحجب واجهة المستخدم. ولتجنب حالات ANR، ينبغي للمطورين ضمان تنفيذ المهام الثقيلة في الخلفية، ما يحسّن أداء التطبيق وتجربة المستخدم.
More about ANR
يُعدّ ANR (Application Not Responding) حالة في تطبيقات Android لا يستجيب فيها التطبيق لإجراءات المستخدم أو أحداث النظام ضمن حد زمني معين. وعندما تحدث حالة ANR بينما يكون التطبيق في المقدمة، يعرض Android مربع حوار يستطيع فيه المستخدم اختيار الانتظار أو إغلاق التطبيق. ويختبرها المستخدم كشاشة متجمدة، لذا تُعدّ حالات ANR، إلى جانب الأعطال، من أخطر مشكلات الاستقرار في تطبيق Android.
من الناحية التقنية، تنتج حالة ANR دائمًا تقريبًا عن حجب الخيط الرئيسي للتطبيق. فالخيط الرئيسي يتولى رسم واجهة المستخدم ومعالجة الإدخال معًا، لذا إذا كان منشغلًا بعمل طويل، لا يستطيع التطبيق الاستجابة. ومن الأسباب المعتادة الاستدعاءات الشبكية أو عمليات الملفات وقواعد البيانات على الخيط الرئيسي، والحسابات الثقيلة، والحالات التي ينتظر فيها الخيط الرئيسي قفلًا يحتفظ به خيط خلفي، والجمود بين الخيوط.
يُطلق Android حالة ANR في عدة مواقف، لكل منها حده الزمني الخاص:
أحداث الإدخال: إذا لم يستجب التطبيق لحدث إدخال، مثل نقرة أو ضغطة مفتاح، خلال خمس ثوانٍ.
مستقبلات البث: إذا لم ينته مستقبل البث من معالجة رسالة ضمن الحد الزمني للنظام، الذي يكون أقصر لعمليات البث في المقدمة منه لعمليات البث في الخلفية.
الخدمات: إذا لم تُكمل الخدمة توابع دورة حياتها في الوقت المحدد، أو إذا لم تستدعِ خدمة المقدمة startForeground() بعد وقت قصير من بدئها.
ولاكتشاف حالات ANR وتحليلها، يستطيع المطورون استخدام Android vitals في Google Play Console، الذي يعرض معدل ANR وتتبعات المكدس من أجهزة المستخدمين. وأثناء التطوير، يستطيع StrictMode كشف عمليات القرص والشبكة غير المقصودة على الخيط الرئيسي، بينما تُظهر أدوات التحليل في Android Studio أين يُستهلك الوقت. كما تستطيع أدوات مثل Firebase Crashlytics جمع تقارير ANR.
وأنجع طريقة لتجنب حالات ANR هي إبقاء الخيط الرئيسي حرًا. فينبغي أن تعمل الاستدعاءات الشبكية والوصول إلى قواعد البيانات والحسابات الثقيلة في الخلفية، مثلًا باستخدام الروتينات المشتركة في Kotlin على مُوزِّع مناسب، ويمكن جدولة المهام الأطول باستخدام WorkManager. ومن المهم أيضًا تجنب الأقفال المحتفظ بها طويلًا التي يضطر الخيط الرئيسي إلى انتظارها، وإبقاء العمل في مستقبلات البث وتوابع دورة الحياة قصيرًا.
وتتجاوز أهمية حالات ANR المستخدم الفرد. إذ تستخدم Google Play معدل ANR كأحد مقاييس الجودة الأساسية في Android vitals، والتطبيقات التي تتجاوز عتبات السلوك السيئ قد يُقلَّص ظهورها في المتجر. خلاصة القول، تُعدّ حالة ANR إشارة إلى أن التطبيق يؤدي عملًا في المكان الخطأ، وتُعدّ المراقبة المنهجية لحالات ANR والوقاية منها جزءًا مهمًا من تطوير تطبيقات Android مستقرة.
Frequently asked questions about ANR
ما الذي يرمز إليه ANR في سياق تطبيقات الأجهزة المحمولة؟
يرمز ANR إلى «Application Not Responding»، وهو مصطلح من Android. وتحدث هذه الظاهرة عندما لا يستجيب تطبيق على جهاز Android لإدخال المستخدم ضمن إطار زمني معين، هو عادة 5 ثوانٍ. وعندما يتعرض التطبيق لحالة ANR، قد يرجع ذلك إلى عدة عوامل، مثل العمليات الطويلة على الخيط الرئيسي التي تحجب واجهة المستخدم، أو انتظار أقفال تحتفظ بها خيوط أخرى.
ولتجنب حالات ANR، يُنصح المطورون بنقل الحسابات الثقيلة وعمليات الشبكة إلى خيوط خلفية، حتى يبقى الخيط الرئيسي مستجيبًا لتفاعلات المستخدم. ويمكن تحقيق ذلك بتقنيات البرمجة غير المتزامنة مثل الروتينات المشتركة في Kotlin أو WorkManager، أما واجهة AsyncTask القديمة فقد أُهملت منذ Android 11 وينبغي عدم استخدامها في الشيفرة الجديدة.
ومقارنة بأنواع الأخطاء الأخرى التي قد تحدث في تطبيقات الأجهزة المحمولة، تُعدّ حالة ANR حالة حرجة، إذ تؤثر مباشرة في تجربة المستخدم بمنع التفاعل مع التطبيق، ما قد يؤدي إلى الإحباط وربما فقدان المستخدمين. لذا من المهم أن يراقب المطورون تطبيقاتهم ويحسّنوها لتقليل خطر حالات ANR إلى أدنى حد.
كيف يمكن لحالة ANR أن تؤثر في تجربة المستخدم للتطبيق؟
في Android، يرمز ANR إلى Application Not Responding. وتحدث هذه الحالة عندما يُحجب الخيط الرئيسي للتطبيق لفترة طويلة جدًا، عادة نحو خمس ثوانٍ، بينما ينبغي أن يستجيب التطبيق لإدخال المستخدم. ثم يعرض النظام مربع حوار يستطيع فيه المستخدم اختيار الانتظار أو إغلاق التطبيق. وإذا اختار المستخدم إغلاقه، يُنهى التطبيق بالطريقة نفسها كما في الإغلاق القسري.
ويختبر المستخدم ذلك كتطبيق يتجمد ولا يستجيب للنقرات. وهذا محبط وقد يدفع المستخدمين إلى إلغاء تثبيت التطبيق أو ترك تقييم سيئ. وحتى التأخيرات الأقصر التي لا تُطلق مربع حوار ANR تجعل التطبيق يبدو بطيئًا. لذا ينبغي دائمًا نقل المهام الثقيلة بعيدًا عن الخيط الرئيسي.
ما الأدوات التي يستطيع المطورون استخدامها لاكتشاف مشكلات ANR وتحليلها؟
يستطيع المطورون استخدام مجموعة من الأدوات لاكتشاف مشكلات ANR (Application Not Responding) وتحليلها، ما قد يحسّن أداء التطبيق وتجربة المستخدم. وإليكم ثلاث أدوات رئيسية وخصائصها:
- Android vitals في Google Play Console: تُعدّ Android vitals ميزة في Google Play Console تمنح المطورين رؤية لأداء التطبيق، بما في ذلك أحداث ANR. فبتحليل البيانات من مستخدمين حقيقيين، يستطيع المطورون تحديد الأنماط والمواقف المحددة التي تحدث فيها حالات ANR. وتوفر الأداة نظرة شاملة على استقرار التطبيق وتساعد على ترتيب أولويات أخطر المشكلات.
- أدوات التحليل في Android Studio: توفر أدوات التحليل في Android Studio بيانات عن استهلاك المعالج والذاكرة والشبكة والطاقة. وبتحليل المعالج، يستطيع المطورون تتبع الخيوط وتحديد الانسدادات التي قد تؤدي إلى حالات ANR. والأداة أساسية لفهم كيفية تنفيذ شيفرة التطبيق ولتحسين الأداء.
- Firebase Crashlytics: تُعدّ Firebase Crashlytics خدمة للإبلاغ عن الأعطال تستطيع أيضًا المساعدة على اكتشاف مشكلات ANR. فهي توفر تقارير مفصلة عن أحداث ANR، بما في ذلك تتبعات المكدس والمعلومات السياقية التي تساعد المطورين على فهم سبب المشكلة. وبفضل التنبيهات في الوقت الفعلي، يستطيع المطورون الاستجابة بسرعة لحالات ANR الجديدة وتنفيذ الإصلاحات.
ويمكّن الجمع بين الرؤية التفصيلية من Android vitals والتحليل بأدوات Android Studio والتقارير الشاملة من Firebase Crashlytics المطورين من اكتشاف مشكلات ANR وحلها بفعالية، ما ينتج عنه تطبيق أكثر استقرارًا واستجابة.
ما الاستراتيجيات التي يمكن تنفيذها لتقليل حدوث ANR في التطبيق؟
يمكن تنفيذ عدة استراتيجيات لتقليل حدوث ANR (Application Not Responding) في التطبيق. إذ تحدث حالة ANR عندما لا يستجيب التطبيق لإدخال المستخدم ضمن إطار زمني معين، ما قد يؤدي إلى تجربة مستخدم سيئة. وإليكم بعض الاستراتيجيات الفعالة لتقليل حالات ANR إلى أدنى حد:
- المعالجة غير المتزامنة: ينبغي نقل العمليات الثقيلة، مثل الطلبات الشبكية وعمليات قواعد البيانات، إلى خيوط خلفية بالمعالجة غير المتزامنة. وهذا يضمن بقاء الخيط الرئيسي مستجيبًا لإدخال المستخدم.
- إبقاء خيط واجهة المستخدم حرًا: ينبغي عدم تنفيذ العمليات الطويلة على خيط واجهة المستخدم. فالروتينات المشتركة في Kotlin أو WorkManager أو، عند الحاجة، Handler على خيط خلفي تبقي خيط واجهة المستخدم خاليًا من الانسدادات، أما AsyncTask فمُهمَلة.
- تجنب التنافس على الأقفال: ينبغي ألا ينتظر الخيط الرئيسي أقفالًا تحتفظ بها خيوط خلفية، وينبغي تجنب الاستدعاءات المتزامنة بين الخيوط حيثما أمكن. كما تمنع المعالجة المتينة للأخطاء الحالات غير المتوقعة، مثل مهلة زمنية لا تُعالج أبدًا.
- استخدام ViewModel: يتولى ViewModel، مع الروتينات المشتركة أو Flow، جلب البيانات وتحديثها بطريقة فعالة لا تحجب خيط واجهة المستخدم. أما واجهة Loaders القديمة فقد أُهملت منذ Android 9.
- التحليل وتحسين الأداء: تساعد أدوات مثل أدوات التحليل في Android Studio على تحديد الاختناقات في أداء التطبيق وتحسينها. ويمكن لذلك المساعدة على اكتشاف الشيفرة غير الفعالة التي قد تؤدي إلى حالات ANR وإصلاحها.
- تقليل تعقيد التخطيط: يقلل تبسيط بنية التخطيط الوقت الذي يستغرقه عرض مكونات واجهة المستخدم. ويمكن استخدام ConstraintLayout أو أنواع التخطيط الفعالة الأخرى لتحسين أداء واجهة المستخدم.
- التحميل المسبق والتخزين المؤقت: يقلل التحميل المسبق للبيانات وتخزينها مؤقتًا وقت الانتظار عند جلب البيانات، ما قد يحسّن استجابة التطبيق.
إجمالًا، يستطيع الجمع بين المعالجة غير المتزامنة وخيط واجهة مستخدم حر والاستخدام الحذر للأقفال وتحسين الأداء تقليل حدوث حالات ANR في التطبيق بشكل ملحوظ. وتساعد هذه الاستراتيجيات على ضمان بقاء التطبيق مستجيبًا وتقديمه تجربة مستخدم أفضل.
كيف يمكن لحالات ANR أن تؤثر في ترتيب التطبيق في متاجر التطبيقات؟
يمكن لحالات ANR (Application Not Responding) أن تؤثر تأثيرًا كبيرًا في ترتيب التطبيق على Google Play، إذ تؤثر مباشرة في تجربة المستخدم والتقييم الإجمالي للتطبيق. فحالة ANR تحدث عندما لا يستجيب التطبيق لإدخال المستخدم ضمن إطار زمني معين، ما ينتج عنه كثيرًا الإحباط وربما المراجعات السلبية.
وتقيس Google Play معدل ANR الذي يلمسه المستخدم في Android vitals، والتطبيقات التي تتجاوز عتبة السلوك السيئ قد تُعرض بشكل أقل بروزًا وقد يظهر تحذير في صفحتها في المتجر. ومع أن ANR مصطلح خاص بـ Android، فإن Apple App Store يتأثر أيضًا بشكل غير مباشر، إذ تؤدي حالات التجمد على iOS إلى تقييمات أدنى ومراجعات سلبية، ما قد يؤثر بدوره في ظهور التطبيق وترتيبه في نتائج البحث.
ولتقليل حالات ANR إلى أدنى حد وتحسين ترتيب التطبيق في متاجر التطبيقات، ينبغي للمطورين التركيز على تحسين أداء التطبيق. وقد يشمل ذلك:
- تحسين شيفرة التطبيق لضمان عمله بكفاءة ودون تأخيرات غير ضرورية.
- تنفيذ المعالجة غير المتزامنة لمنع حجب الخيط الرئيسي بعمليات ثقيلة.
- اختبار أداء التطبيق ومراقبته بانتظام لاكتشاف المشكلات المحتملة وإصلاحها قبل أن تؤثر في المستخدمين.
وباتخاذ هذه الخطوات، لا يستطيع المطورون تحسين تجربة المستخدم فحسب، بل يستطيعون أيضًا زيادة فرص الحصول على ترتيب أعلى في متاجر التطبيقات، ما قد يؤدي إلى مزيد من التنزيلات وقاعدة مستخدمين أكبر.
ما أفضل الممارسات التي ينبغي اتباعها لتجنب ANR في مشاريع تطوير التطبيقات المستقبلية؟
لتجنب ANR (Application Not Responding) في مشاريع تطوير التطبيقات المستقبلية، من المهم اتباع عدد من أفضل الممارسات التي تضمن تجربة مستخدم مستجيبة وفعالة. إذ تحدث حالة ANR عادة عندما لا يستجيب التطبيق لإدخال المستخدم ضمن إطار زمني معين، ما قد يؤدي إلى الإحباط وربما فقدان المستخدمين. وإليكم بعض الاستراتيجيات التي تساعد على تقليل خطر حالات ANR إلى أدنى حد:
ومن أنجع الطرق لتجنب حالات ANR ضمان تنفيذ جميع العمليات الثقيلة، مثل الطلبات الشبكية واستعلامات قواعد البيانات ومعالجة الملفات، في الخلفية. ويمكن تحقيق ذلك بمهام غير متزامنة أو خيوط تمنع حجب الخيط الرئيسي. فبنقل هذه العمليات بعيدًا عن الخيط الرئيسي، يستطيع التطبيق البقاء مستجيبًا لإدخال المستخدم، حتى أثناء تنفيذ مهام معقدة.
ومن الممارسات المهمة الأخرى تحسين أداء التطبيق بتقليل الحسابات غير الضرورية واستخدام الموارد بكفاءة. وقد يشمل ذلك التخزين المؤقت للبيانات المستخدمة كثيرًا لتقليل الحسابات المتكررة إلى أدنى حد، واستخدام خوارزميات وبنى بيانات فعالة. وفضلًا عن ذلك، ينبغي للمطورين الحرص على تحرير الموارد التي لم تعد مطلوبة لمنع تسربات الذاكرة، التي قد تسبب توقفات متكررة لجمع المهملات وأعطالًا بسبب نفاد الذاكرة.
وأخيرًا، من الحاسم تنفيذ معالجة شاملة للأخطاء وتسجيل في التطبيق، إلى جانب StrictMode أثناء التطوير. وهذا يتيح اكتشاف المشكلات المحتملة وإصلاحها قبل أن تؤدي إلى حالات ANR. فبمراقبة أداء التطبيق والاستجابة السريعة للأخطاء، يستطيع المطورون ضمان بقاء التطبيق مستقرًا وموثوقًا. إجمالًا، تساعد أفضل الممارسات هذه على إنشاء تطبيق متين يقدم تجربة مستخدم سلسة دون انقطاع.
ANR for dummies
يرمز ANR إلى «Application Not Responding»، وهو أمر قد يحدث للتطبيقات على هاتف Android. تخيّلوا محاولة استخدام تطبيق، لكنه يتجمد ويتوقف عن الاستجابة للنقرات والسحب. ويشبه ذلك قليلًا تعطل الحاسوب وعدم استجابته مهما فُعل. ويحدث هذا عندما يكون التطبيق منشغلًا بمهمة ثقيلة في المكان الخطأ أو فيه خطأ يمنعه من العمل بشكل صحيح. وعندما تحدث حالة ANR، كثيرًا ما يعرض الهاتف رسالة تسأل عما إذا كان ينبغي انتظار عودة التطبيق إلى العمل أو إغلاقه. وهذه طريقة الهاتف للقول إن شيئًا ما لا يعمل كما ينبغي، وإنه قد يفيد المحاولة مرة أخرى لاحقًا أو تحديث التطبيق.