שגיאות מסוג "האפליקציה לא מגיבה" (ANR) מופעלות כששרשור ה-UI של האפליקציה לא מגיב במשך יותר מ-5 שניות. מידע נוסף על מקרי ANR ועל אבחון של מקרי ANR זמין במסמכי התיעוד של Android.
בנוסף, Crashlytics יכול לעזור לזהות שרשורים ספציפיים שעלולים להיות בעייתיים. אנחנו מנתחים את מקרי ה-ANR, ואז, במרכז הבקרה של DevOps ומעורבות > Crashlytics, אנחנו מתייגים את השרשורים הרלוונטיים כדי לספק רמזים לניפוי באגים של ה-ANR.
בקטעים הבאים בדף הזה מוסבר מה המשמעות של כל תג ANR, מוצגת דוגמה ל-ANR עם התג הזה ומוצע פתרון מומלץ לניפוי באגים של ה-ANR.
Triggered ANR
שרשור שנחסם למשך זמן רב מדי והפעיל את ה-ANR מסומן בתג Triggered ANR.
השרשור הבעייתי יכול להיות השרשור הראשי של האפליקציה, או כל שרשור שלא מגיב. עם זאת, יכול להיות שהשרשור שמתויג בתור Triggered ANR הוא לא הסיבה האמיתית ל-ANR. כדי לספק תובנות לניפוי באגים ולתיקון מקרי ה-ANR האלה, Crashlytics מתייג גם את כל ה-threads האחרים שמעורבים ב-ANR. בקטעים הבאים בדף הזה מוסבר על התגים האחרים שאפשר להוסיף לשרשור.
Deadlocked
כל השרשורים שמעורבים במבוי סתום שהוביל ל-ANR מסומנים בתג Deadlocked.
מבוי סתום מתרחש כששרשור נכנס למצב המתנה כי משאב נדרש מוחזק על ידי שרשור אחר, שגם ממתין למשאב שמוחזק על ידי השרשור הראשון. אם ה-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)
המלצה
בודקים את השרשורים שמעורבים במבוי הסתום ואת המשאבים או הנעילות שהשרשורים האלה רכשו. במאמרים מבוי סתום ואלגוריתמים למניעת מבוי סתום מפורטים פתרונות אפשריים.
IO Root blocking
כל שרשור שביצע פעולות קלט/פלט איטיות וחסם את השרשור 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 )
המלצה
באופן כללי, האפליקציה לא אמורה לבצע פעולות קלט/פלט (I/O) שדורשות משאבים רבים ב-thread הראשי. אם ה-thread הראשי הוא IO Root blocking, אפשר גם להשתמש במצב קפדני כדי לזהות פעולות קלט/פלט לא מכוונות שמתרחשות ב-thread הראשי.
Root blocking
כל שרשור שחסם את השרשור שתויג בתג Triggered ANR מתויג בתג Root blocking. אם שרשור מתויג גם כ-Root blocking וגם כ-Triggered ANR, אין שרשורים אחרים שחוסמים אותו.
אם שרשורים כלשהם של Triggered ANR המתינו (אולי באופן טרנזיטיבי) לשרשורים אחרים, הם 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 )
המלצה
צמצמו את העבודה שדורשת משאבי מעבד (CPU) רבים ב-thread הראשי. השתמשו ב-worker threads או ב-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. לדוגמה, זהו את המקומות בקוד שבהם ה-thread הראשי של האפליקציה יכול להיות עסוק במשך יותר מ-5 שניות.
Waiting for binder call
כל שרשור שהמתין לקריאת Binder וחסם את השרשור Triggered ANR מסומן בתג Waiting for binder call. אם ה-thread Triggered ANR לא נחסם על ידי threads אחרים, אז ה-thread Waiting for binder call הוא גם thread Root blocking.
לצפייה בדוגמה
Thread main(THREAD_STATE_NATIVE_WAITING)
syscall
android::IPCThreadState::talkWithDriver(bool)
android::IPCThreadState::waitForResponse(android::Parcel*, int*)
android::IPCThreadState::transact(int, unsigned int, android::Parcel const&, android::Parcel*, unsigned int)
android::BpBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)
android_os_BinderProxy_transact(_JNIEnv*, _jobject*, int, _jobject*, _jobject*, int)
android.os.BinderProxy.transactNative( BinderProxy.java:0 )
android.os.BinderProxy.transact( BinderProxy.java:540 )
android.app.IActivityManager$Stub$Proxy.getContentProvider( IActivityManager.java:5945 )
android.app.ActivityThread.acquireProvider( ActivityThread.java:7138 )
android.app.ActivityThread$H.handleMessage( ActivityThread.java:1982 )
android.os.Handler.dispatchMessage( Handler.java:106 )
android.os.Looper.loop( Looper.java:236 )
android.app.ActivityThread.main( ActivityThread.java:8037 )
המלצה
הזמן שלוקח להפעיל את Binder יכול להיות לא צפוי, לכן כדאי להתייחס להפעלות של Binder כמו לפעולות קלט/פלט (I/O) ולהימנע מביצוע שלהן ב-thread הראשי כשאפשר. צריך להעביר ל-thread ברקע את הקוד שגורם להפעלות של Binder (כולל קריאות ל-API של הפלטפורמה שגורמות לטרנזקציות של Binder), או לשמור את התוצאות במטמון אם אין ברירה אלא להפעיל את Binder מה-thread הראשי.
