يختلف ANR (التطبيق لا يستجيب) عن العطل حيث يحدث العطل عادةً عندما يواجه التطبيق خطأً أو استثناءً غير متوقع ويضطر إلى الإغلاق. من ناحية أخرى، يحدث ANR عندما لا يستجيب التطبيق ولكنه لم يتعطل. قياسًا على ذلك، يعني ANR أن التطبيق في غيبوبة ??، ويعني التعطل أن التطبيق ميت ؟.
تعد أخطاء ANR والأعطال نوعين مختلفين من المشكلات التي يمكن أن تحدث أثناء اختبار الهاتف المحمول.
يشير ANR إلى الموقف الذي يصبح فيه التطبيق غير مستجيب أو متجمد ولا يستجيب لإدخال المستخدم. يمكن أن يحدث هذا بسبب مجموعة متنوعة من العوامل، مثل عملية طويلة الأمد تحظر سلسلة الرسائل الرئيسية، أو مشكلة في تصميم التطبيق أو تنفيذه مما يتسبب في عدم استجابته.
من ناحية أخرى، تشير الأعطال إلى المواقف التي يواجه فيها التطبيق خطأً أو استثناءً غير متوقع ويضطر إلى الإغلاق. يمكن أن يحدث هذا بسبب مجموعة متنوعة من العوامل، مثل استثناء لم تتم معالجته، أو مرجع مؤشر فارغ، أو مشكلة في كود التطبيق أو تكوينه.
لاختبار ANR والأعطال، يستخدم المطورون والمختبرون عادةً مجموعة من أدوات الاختبار اليدوية والاختبار الآلي. يتضمن الاختبار اليدوي التفاعل يدويًا مع التطبيق والتحقق من أنه يعمل كما هو متوقع، بينما يتضمن الاختبار الآلي استخدام أدوات وأطر الاختبار لتنفيذ سلسلة من الاختبارات تلقائيًا على التطبيق.
لتحديد مشكلات ANR والتعطل واستكشاف أخطائها وإصلاحها، سيحتاج المطورون والمختبرون عادةً إلى تحليل سجلات التطبيق وبيانات الأداء لتحديد السبب الجذري للمشكلة. قد يتضمن ذلك تحليل سجلات النظام، وتحديد أداء التطبيق، والبحث عن الأنماط أو الاتجاهات التي يمكن أن تساعد في تحديد مصدر المشكلة.
بشكل عام، يمكن أن تكون مشكلات ANR محبطة للمستخدمين ويمكن أن تؤثر سلبًا على تجربة المستخدم للتطبيق. من المهم للمطورين والمختبرين اختبار تطبيقاتهم وتصحيح الأخطاء فيها بعناية للتأكد من أنها سريعة الاستجابة ومستقرة وتعمل بشكل جيد في ظل مجموعة متنوعة من الظروف.
أخطاء ANR
حوادث
قم بتصحيح أخطاء تطبيق Android الخاص بك استنادًا إلى علامات ANR في لوحة معلومات Crashlytics
ANR مقابل كراش | logcat مقابل تقرير الأخطاء
