שגיאות מסוג 'האפליקציה לא מגיבה (ANR)' מופעלות כששרשור ה-UI של האפליקציה לא מגיב במשך יותר מ-5 שניות. מידע נוסף על מקרי ANR ועל אבחון שלהם זמין בתיעוד של Android.
בנוסף, Crashlytics יכול לעזור לזהות שרשורים ספציפיים שבהם יש בעיות. אנחנו מנתחים שגיאות ANR, ואז בלוח הבקרה DevOps & Engagement > Crashlytics, אנחנו מתייגים את השרשורים הרלוונטיים כדי לספק רמזים לגבי ניפוי הבאגים של שגיאות ה-ANR.
בקטעים הבאים בדף הזה מוסבר מה המשמעות של כל תג ANR, מוצגות דוגמאות ל-ANR עם התג הזה ומוצע פתרון מומלץ לניפוי באגים של ANR.
Triggered ANR
Thread שנחסם למשך זמן ארוך מדי והפעיל את ה-ANR מסומן בתג Triggered ANR.
השרשור הבעייתי יכול להיות השרשור הראשי של האפליקציה, או כל שרשור שלא מגיב. עם זאת, יכול להיות שהשרשור שתויג כ-Triggered ANR הוא הסיבה האמיתית ל-ANR, ויכול להיות שלא. כדי לספק תובנות לניפוי באגים ולתיקון של שגיאות ANR, Crashlytics מתייג גם את כל השרשורים האחרים שקשורים לשגיאת ה-ANR. בקטעים הבאים בדף הזה מוסבר על התגים האחרים שאפשר להוסיף לשרשור.
Deadlocked
כל השרשורים שנמצאו כמעורבים בקיפאון (deadlock) שהוביל ל-ANR מסומנים בתג Deadlocked.
מצב של קיפאון מתרחש כש-thread נכנס למצב המתנה כי משאב נדרש מוחזק על ידי thread אחר, שגם הוא נמצא בהמתנה למשאב שמוחזק על ידי ה-thread הראשון. אם ה-thread הראשי של האפליקציה נמצא במצב הזה, סביר להניח שיוצגו שגיאות ANR.
לצפייה בדוגמה
לפניכם שני שרשורים שמעורבים במצב של קיפאון:
main (unknown): tid=1 systid=1568
com.android.server.pm.PackageManagerService$PackageManagerInternalImpl.getPackage(PackageManagerService.java:22701)
com.android.server.pm.PackageManagerService$PackageManagerInternalImpl.filterOnlySystemPackages(PackageManagerService.java:22787)
...
com.android.server.SystemServer.main(SystemServer.java:368)
java.lang.reflect.Method.invoke(Native method)
com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:517)
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:934)
ActivityManager (unknown): tid=21 systid=1902
com.android.server.pm.PackageManagerService.getPackageSetting(PackageManagerService.java:23618)
com.android.server.pm.PackageManagerService.getPackageUid(PackageManagerService.java:4542)
...
android.os.Handler.handleCallback(Handler.java:907)
android.os.Handler.dispatchMessage(Handler.java:99)
android.os.Looper.loop(Looper.java:216)
android.os.HandlerThread.run(HandlerThread.java:67)
com.android.server.ServiceThread.run(ServiceThread.java:44)
המלצה
בודקים את השרשורים שמעורבים במבוי סתום ואת המשאבים או הנעילות שהשרשורים האלה קיבלו. כדי לראות פתרונות אפשריים, אפשר לעיין במאמרים בנושא קיפאון (deadlock) ואלגוריתמים למניעת קיפאון (deadlock).
IO Root blocking
כל thread שביצע פעולות קלט/פלט איטיות וחסימה של ה-thread Triggered ANR מתויג בתג IO Root blocking. אם ה-thread Triggered ANR לא נחסם על ידי threads אחרים, אז ה-thread IO Root blocking הוא גם thread Root blocking.
הצגת דוגמאות
Thread main(THREAD_STATE_TIMED_WAITING)
sun.misc.Unsafe.park( Unsafe.java:0 )
java.util.concurrent.locks.LockSupport.parkNanos( LockSupport.java:230 )
android.database.sqlite.SQLiteConnectionPool.waitForConnection( SQLiteConnectionPool.java:756 )
...
android.app.ActivityThread.main( ActivityThread.java:8192 )
Thread main(THREAD_STATE_NATIVE_WAITING)
Syscall
art::ConditionVariable::WaitHoldingLocks(art::Thread*)
art::GoToRunnable(art::Thread*)
art::JniMethodEnd(unsigned int, art::Thread*)
libcore.io.Linux.fdatasync( Linux.java:0 )
libcore.io.ForwardingOs.fdatasync( ForwardingOs.java:105 )
...
java.io.RandomAccessFile.write( RandomAccessFile.java:559 )
...
android.app.ActivityThread.main( ActivityThread.java:8192 )
המלצה
באופן כללי, האפליקציה לא צריכה לבצע פעולות קלט/פלט יקרות ב-thread הראשי. אם ה-thread הראשי הוא IO Root blocking, אפשר גם להשתמש במצב קפדני כדי לזהות פעולות קלט/פלט לא מכוונות שמתרחשות ב-thread הראשי.
Root blocking
כל שרשור שחסם את השרשור שתויג כ-Triggered ANR יקבל את התג Root blocking. אם שרשור מתויג גם כ-Root blocking וגם כ-Triggered ANR, סימן שלא קיימים שרשורים אחרים שחוסמים את השרשור הזה.
אם יש threads של Triggered ANR שנמצאים בהמתנה (אולי באופן טרנזיטיבי) ל-threads אחרים, הם Root blocking. יכולות להיות סיבות שונות לכך ששרשור הוא שורש הבעיה של ה-ANR.
הצגת דוגמאות
הנה כמה דוגמאות שמבוססות על מצב השרשור:
Thread main(THREAD_STATE_RUNNABLE)
android.os.Parcel.createTypedArray( Parcel.java:3086 )
android.content.pm.PackageInfo.<init>( PackageInfo.java:546 )
...
android.app.ActivityThread$H.handleMessage( ActivityThread.java:2166 )
android.os.Handler.dispatchMessage( Handler.java:106 )
android.os.Looper.loop( Looper.java:246 )
android.app.ActivityThread.main( ActivityThread.java:8633 )
Thread main(THREAD_STATE_BLOCKED)
DBHelper.runOnDB( DBHelper.java:97 )
DBHelper.runDb( DBHelper.java:125 )
...
java.lang.reflect.Method.invoke( Method.java:0 )
EventBus.invokeSubscriber( EventBus.java:510 )
postToSubscription( EventBus.java:437 )
...
android.os.Handler.handleCallback( Handler.java:938 )
android.os.Handler.dispatchMessage( Handler.java:99 )
android.os.Looper.loop( Looper.java:268 )
android.app.ActivityThread.main( ActivityThread.java:7904 )
המלצה
צריך לצמצם את העבודה שדורשת הרבה משאבי מעבד ב-thread הראשי. כדאי להשתמש ב-worker או ב-background threads כדי לבצע משימות שדורשות הרבה משאבים מהמעבד.
כדאי לצמצם את העבודה שדורשת הרבה קלט/פלט, כמו טעינה ממסד נתונים, ב-thread הראשי.
Unknown root cause
שרשור מתויג בתג Unknown root cause אם הוא השרשור שהפעיל את ה-ANR אבל היה במצב בלי פעילות בתהליך כשהתרחש ה-ANR. ל-Crashlytics אין מספיק מידע כדי לקבוע את הסיבה הבסיסית. לא ברור למה מקרה ה-ANR הזה קרה.
לצפייה בדוגמה
Thread main(THREAD_STATE_NATIVE_WAITING) __epoll_pwait
android::Looper::pollInner(int)
android::Looper::pollOnce(int, int*, int*, void**)
android::android_os_MessageQueue_nativePollOnce(_JNIEnv*, _jobject*, long, int)
android.os.MessageQueue.nativePollOnce( MessageQueue.java:0 )
android.os.MessageQueue.next( MessageQueue.java:335 )
android.os.Looper.loop( Looper.java:193 )
android.app.ActivityThread.main( ActivityThread.java:8019 )
המלצה
פועלים לפי העצות הכלליות למניעת ANR. לדוגמה, אפשר לזהות את המקומות בקוד שבהם השרשור הראשי של האפליקציה עשוי להיות עמוס במשך יותר מ-5 שניות.
