ANR ใน Android: มันคืออะไร สาเหตุ และวิธีแก้ไข

ANR ใน Android คืออะไร

ANR (Application Not Responding) เป็นกลไกการป้องกันผู้ใช้ใน Android ที่ทำงานเมื่อแอพหยุดตอบสนองต่ออินพุต ระบบจะติดตามเวลาการประมวลผลเหตุการณ์: หาก BroadcastReceiver ไม่เสร็จ onReceive ภายใน 10 วินาที, Service ไม่กลับจาก onCreate ภายใน 20 วินาที หรือ ContentProvider ไม่ตอบสนองภายใน 15 วินาที — Android จะสร้าง ANR

ANR แสดงอย่างไรต่อผู้ใช้

เมื่อเกิด ANR, Android จะแสดงกล่องโต้ตอบสนองระบบเทอบหน้าต่างทั้งหมด: “แอปไม่ตอบสนอง คุณต้องการปิดหรือรอเผ้าชมากละ?” ผู้ใช้สามารถปิดแอพหรือรอให้มันกลับมาใช้งานได้ หากเกิด ANR บ่อยครั้ง ผู้ใช้จะถอนแอพออก Google Play พิจารณา อัตรา ANR — เปอร์เซนต์ของเซสชั่นที่มี ANR — ในอัลกอริทึมการจัดอันดับ

ความแตกต่างระหว่าง ANR และการค้างของ iOS

iOS ไม่มีสิ่งที่เทียบเท่ากับ ANR ที่มีกล่องโต้ตอบสนองระบบ แทนนั้น Apple ใช้ Watchdog ซึ่งจะสิ้นสุดกระบวนการด้วยรหัสออก 0x8badf00d ผู้ใช้จะไม่เห็นกล่องโต้ตอบสนอง — แอพจะปิดกลับไปยังหน้าจอหลัก ทำให้ ANR บน Android สังเกตแก่ผู้ใช้มากกว่า แต่ให้ข้อมูลการวิจัยแก่ระบบมากขึ้น

สาเหตุหลักของ 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 โดยเริ่มต้นที่ล่าช้า
• เธรด UI — 5 วินาทีโดยไม่มีการประมวลผลเหตุการณ์; การบล็อกใดๆ ที่นานกว่า 5 วินาทีจะทริเกอร์ ANR

วิธีการวิจัย ANR

Android มีเครื่องมือหลายอย่างสำหรับการวิเคราะฮ์ ANR: ตั้งแต่บันทึกระบบไปจนถึงไลบรารีเฉพาะทาง

การวิเคราะฮ์ traces.txt

ในแต่ละ ANR, Android จะบันทึกไฟล์ /data/anr/traces.txt พร้อมการดัมพ์สแต็กของเธรดทั้งหมดของแอพ ค้นหาเธรด “main” — เมธอดสุดท้ายในสแต็กบ่งบอกสาเหตุ รูปแบบทั่วไป: Thread.sleep(), InputStream.read(), BinderProxy.transact() สำหรับการแยกไฟล์จากอุปกรณ์, ใช้ adb โดยมีสิทธิผู้ใช้ระดับสูง

Firebase Crashlytics กับรายงาน ANR

Firebase Crashlytics จะรวบรวม ANR โดยอัตโนมัติและแสดงในแดสบอร์ดพร้อมการติดตาม สำหรับ Android 11+ รายงาน ANR จะมาพร้อมกับสแต็กเต็มของเธรดหลัก การผนวการต้องเพิ่มการพึ่งพาและเริ่มต้น FirebaseApp ใน Application.onCreate

Android Studio Profiler กับการติดตามเธรด

CPU Profiler ใน Android Studio ช่วยให้คุณบันทึกการติดตามแอพและดูว่าเมธอดใดใช้เวลา CPU เปิดใช้งาน “Record with method traces” และจำลองสถานการณ์ที่ทำให้เกิด ANR เส้นเวลาจะแสดงว่าเมธอดใดที่กำลังทำงานในเธรดหลักขณะที่เกิดการค้าง

ตัวอย่างการผนวก Firebase Crashlytics สำหรับการรวบรวม ANR บน Android:

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 กับตัวจัดส่งที่เหมาะสม

เริ่มคำขอเครือข่ายทั้งหมด, การดำเนินการฐานข้อมูล และ I/O ไฟล์ด้วย Dispatchers.IO เธรดหลักควรอัพเดต UI เท่านั้น ใช้ viewModelScope สำหรับการยกเลิก coroutine โดยอัตโนมัติเมื่อ Activity ถูกทำลาย หลีกเลี่ยง runBlocking() ในทุกบริบท — มันบล็อกเธรดปัจจุบันแบบซิงโครนัส

การเริ่มต้นแบบขีเฉือยของ ContentProvider

หาก ContentProvider ทำการเริ่มต้นที่ช้า, ใช้กลไกการโหลดแบบขีเฉือย: สร้างโปรไวเดอร์ที่ส่งคืนข้อมูลทันทีและเริ่มการเริ่มต้นที่หนักผ่าน WorkManager โดยการหน่วงเวลา ซึ่งป้องกัน ANR ในการเริ่มต้นแอพ เมื่อระบบอ่อนไหวต่อความล่าช้ามากที่สุด

ตัวอย่างการใช้งาน BroadcastReceiver กับ goAsync ใน Android อย่างถูกต้อง:

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() เสมอสำหรับการประมวลผลที่นานกว่า 1 วินาที
• Service — แทนที่ด้วย WorkManager หรือ CoroutineWorker ที่มีตัวจัดส่งเบื้องหลัง
• ContentProvider — หลีกเลี่ยงเครือข่ายแลฐานข้อมูลใน onCreate, ใช้ lazy-init กับ WorkManager
• เธรด UI — StrictMode กับ penaltyDeath ใน Debug, Firebase Performance สำหรับการตรวจสอบการผลิต