ANR في أندرويد: ما هو، الأسباب وطرق الإصلاح

ما هو ANR في أندرويد

ANR (Application Not Responding) هو آلية حماية للمستخدم في أندرويد يتم تفعيلها عندما يتوقف التطبيق عن الاستجابة للإدخال. يتتبع النظام وقت معالجة الأحداث: إذا لم يكمل BroadcastReceiver onReceive خلال 10 ثوانٍ، أو لم يعد Service من onCreate خلال 20 ثانية، أو لم يستجب ContentProvider خلال 15 ثانية — يقوم أندرويد بتوليد ANR.

كيف يبدو ANR للمستخدم

عند حدوث ANR، يعرض أندرويد حوار نظام فوق جميع النوافذ: «التطبيق لا يستجيب. هل تريد إغلاقه أو الانتظار؟». يمكن للمستخدم إغلاق التطبيق أو انتظار استرداده. إذا تكرر ANR بشكل متكرر، يقوم المستخدم بإلغاء تثبيت التطبيق. يراعي Google Play معدل ANR — النسبة المئوية للجلسات مع ANR — في خوارزميات التصنيف الخاصة به.

الفرق بين ANR والتجميد في iOS

لا يوجد في iOS ما يعادل ANR مع حوار النظام. بدلاً من ذلك، تستخدم Apple Watchdog الذي ينهي العملية برمز الخروج 0x8badf00d. لا يرى المستخدم حواراً — يتم إغلاق التطبيق ببساطة إلى الشاشة الرئيسية. هذا يجعل ANR على أندرويد أكثر وضوحاً للمستخدم ولكنه يعطي النظام مزيداً من معلومات التشخيص.

الأسباب الرئيسية لـ ANR

يحدث ANR عندما يتتبع النظام مهلة لأحد أربعة أنواع من المكونات. لكل مكون حد زمني خاص به.

الحظر في BroadcastReceiver

BroadcastReceiver يتم تنفيذه في السلسلة الرئيسية. إذا بدأ onReceive طلب شبكة متزامن، أو كتابة طويلة في قاعدة البيانات، أو انتظر قفلاً — يحدث ANR خلال 10 ثوانٍ. الحل: استخدم goAsync() و WorkManager للمعالجة في الخلفية. السيناريو النموذجي هو استلام إشعار Push من FCM وحفظه بشكل متزامن في Room.

عملية طويلة في Service

Service.onCreate و Service.onStartCommand لهما حد 20 ثانية. إذا بدأ الخدمة تهيئة ثقيلة (تحميل المكتبات، قراءة التهيئة من الشبكة) في السلسلة الرئيسية — ANR أمر لا مفر منه. استخدم IntentService (قديم) أو WorkManager للتنفيذ المضمون في الخلفية.

ContentProvider مع تهيئة بطيئة

ContentProvider.onCreate يتم تنفيذه قبل Application.onCreate وله حد 15 ثانية. إذا قام المزود بترحيل قاعدة البيانات، أو تحميل القواميس، أو تهيئة SDK من الشبكة — فهذا يسبب ANR عند بدء تشغيل التطبيق. الحل: التهيئة البطيئة، تفريغ العمليات الثقيلة إلى WorkManager.

• BroadcastReceiver — 10 ثوانٍ لـ onReceive؛ استخدم goAsync() للمعالجة في الخلفية
• Service — 20 ثانية لـ onCreate/onStartCommand؛ استخدم WorkManager أو CoroutineWorker
• ContentProvider — 15 ثانية لـ onCreate؛ انقل التهيئة إلى Application.onCreate مع بدء مؤجل
• سلسلة واجهة المستخدم — 5 ثوانٍ بدون معالجة الأحداث؛ أي حظر أطول من 5 ثوانٍ يسبب ANR

كيفية تشخيص ANR

يوفر أندرويد عدة أدوات لتحليل ANR: من سجلات النظام إلى المكتبات المتخصصة.

تحليل traces.txt

عند كل ANR، يحفظ أندرويد الملف /data/anr/traces.txt مع تفريغ مكدس لجميع سلاسل التطبيق. ابحث عن السلسلة «main» — تشير آخر طريقة في المكدس إلى السبب. الأنماط النموذجية: Thread.sleep()، InputStream.read()، BinderProxy.transact(). لاستخراج الملف من الجهاز، استخدم adb بصلاحيات المستخدم المتميز.

Firebase Crashlytics مع تقارير ANR

Firebase Crashlytics يقوم تلقائياً بجمع ANR وعرضها في لوحة المعلومات مع التتبع. لأندرويد 11+، تأتي تقارير ANR مع مكدس كامل للسلسلة الرئيسية. يتطلب التكامل إضافة تبعية وتهيئة FirebaseApp في Application.onCreate.

Android Studio Profiler مع تتبع السلاسل

CPU Profiler في Android Studio يتيح لك تسجيل تتبع التطبيق ورؤية أي الطرق تستهلك وقت المعالجة. فعّل «Record with method traces» وأعد إنتاج السيناريو الذي يسبب ANR. سيظهر الجدول الزمني أي الطرق كانت تعمل في السلسلة الرئيسية في وقت التجميد.

مثال على دمج Firebase Crashlytics لجمع ANR على أندرويد:

class App : Application() {
    override fun onCreate() {
        super.onCreate()
        FirebaseApp.initializeApp(this)
        FirebaseCrashlytics.getInstance()
            .setCrashlyticsCollectionEnabled(true)
        StrictMode.setThreadPolicy(StrictMode.ThreadPolicy.Builder()
            .detectAll()
            .penaltyLog()
            .build())
    }
}

طرق إصلاح ANR

إصلاح ANR يعني بشكل أساسي نقل جميع العمليات الطويلة من السلسلة الرئيسية إلى سلاسل الخلفية. دعنا نلقي نظرة على تقنيات محددة لكل نوع من المكونات.

استخدام WorkManager للمهام الخلفية

WorkManager هو الحل الموصى به من Google للعمل في الخلفية. يضمن تنفيذ المهمة في سلسلة خلفية مع مراعاة حالة الجهاز. على عكس Service، لا يحظر WorkManager السلسلة الرئيسية وهو مقاوم لإعادة تشغيل التطبيق. بالنسبة لـ BroadcastReceiver، استخدم goAsync() ومرر PendingResult إلى WorkManager.

Kotlin Coroutines مع المرسلين المناسبين

قم بتشغيل جميع طلبات الشبكة وعمليات قاعدة البيانات وإدخال/إخراج الملفات باستخدام Dispatchers.IO. يجب أن تقوم السلسلة الرئيسية فقط بتحديث واجهة المستخدم. استخدم viewModelScope للإلغاء التلقائي للكوروتينات عند تدمير Activity. تجنب runBlocking() في أي سياق — فهو يحظر السلسلة الحالية بشكل متزامن.

التهيئة البطيئة لـ ContentProvider

إذا كان ContentProvider يقوم بتهيئة بطيئة، استخدم آلية التحميل البطيء: أنشئ مزوداً يعيد البيانات فوراً وابدأ التهيئة الثقيلة من خلال WorkManager مع تأخير. هذا يمنع ANR عند بدء تشغيل التطبيق، عندما يكون النظام أكثر حساسية للتأخيرات.

مثال على الاستخدام الصحيح لـ BroadcastReceiver مع goAsync في أندرويد:

class FcmReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context?, intent: Intent?) {
        val pendingResult = goAsync()
        WorkManager.getInstance(context!!)
            .enqueue(OneTimeWorkRequest.from(NotificationWorker::class.java))
        pendingResult.finish()
    }
}

الوقاية من ANR في التطوير

أفضل طريقة لمكافحة ANR هي منعها أثناء مرحلة التطوير من خلال الأدوات والقرارات المعمارية.

StrictMode للكشف عن حظر السلسلة الرئيسية

StrictMode مع السياسات المفعلة detectNetwork() و detectDiskReads()/detectDiskWrites() يحدد ANR المحتملة أثناء التطوير. في إصدارات Debug، قم بتعيين penaltyDeath — أي انتهاك سيؤدي إلى تعطل فوري وسيرى المطور المشكلة قبل الالتزام.

Firebase Performance Monitoring لمقاييس الإنتاج

Firebase Performance يتتبع وقت تنفيذ العمليات الرئيسية ويظهر أي السيناريوهات تتجاوز عتبة ANR. قم بإعداد تتبعات مخصصة لكل شاشة وطلب شبكة. إذا تجاوز وقت التنفيذ 3 ثوانٍ — فهذا ANR محتمل يتطلب تحسيناً.

الاختبار مع تأخير الشبكة والقرص

قم بمحاكاة الظروف البطيئة: حدد سرعة الشبكة باستخدام Network Link Conditioner على iOS أو Android Emulator. أبطئ قراءة القرص من خلال محاكاة الذاكرة البطيئة. ANR غالباً ما تظهر في هذه الظروف تحديداً، بينما تكون غير مرئية على أجهزة المطور السريعة.

• BroadcastReceiver — استخدم دائماً goAsync() للمعالجة التي تستغرق أكثر من ثانية واحدة
• Service — استبدله بـ WorkManager أو CoroutineWorker مع مرسل خلفية
• ContentProvider — تجنب الشبكة وقاعدة البيانات في onCreate، استخدم التهيئة البطيئة مع WorkManager
• سلسلة واجهة المستخدم — StrictMode مع penaltyDeath في Debug، Firebase Performance للمراقبة في الإنتاج