Android进阶知识：ANR的定位与解决
1、前言
ANR對于Android開發者來說一定不會陌生，從剛開始學習Android時的一不注意就ANR，到后來知道主線程不能進行耗時操作注意到這點后，程序出現ANR的情況就大大減少了，甚至于消失了。那么真的是只要在主線程做耗時操作就會產生ANR嗎？為什么在有時候明明覺得自己沒在主線程做耗時操作也出現了ANR呢？一旦出現莫名其妙的ANR，怎么定位導致ANR的產生的位置和解決問題呢？那么接下來就來一個個的解決這些問題。
2、ANR是什么？
ANR全稱Application Not Responding即應用程序無響應。在Android中如果應用程序有一段時間無法響應用戶操作，系統會彈出彈窗，讓用戶選擇是繼續等待還是強制關閉程序。一款良好應用APP是不應該出現這個彈窗的。
3、ANR的產生原因
ANR產生原因和類型有以下幾種：
1、Activity在5秒鐘之內無法響應屏幕觸摸事件揮著鍵盤輸入事件就會產生ANR。
KeyDispatchTimeout
Reason：Input event dispatching timed out
2、BroadcastReceiver在10秒鐘之內還未執行完成就會產生ANR。
BroadcastTimeout
Reason：Timeout of broadcast BroadcastRecord
3、Service各個生命周期在20秒鐘之內沒有執行完成就會產生ANR。
ServiceTimeout
Reason：Timeout executing service
4、ContentProvider在10秒鐘之內沒有執行完成就會產生ANR。
ContentProviderTimeout
Reason：timeout publishing content providers
在以上這幾種原因中出現最多的一般是第一種，而且往往都是因為在寫代碼時不注意，在主線程做了耗時的操作。
4、ANR的定位與解決
關于ANR的定位這里舉一個例子來看。這是我之前遇到的一次出現ANR的時候所解決問題的情況和解決步驟。
從日志第一行開始看，可以看到發生錯誤的應用包名和類名，這里是ANR in com.xxxx.performance (com.xxxx.performance/.view.home.activity.MainActivity)。接著看到進程號PID為7398。發生ANR的Reason是Input dispatching timed out就是上面提到的第一種。再往下就是活躍進程的CPU占用率日志。
124% 7398/com.xxxx.performance82% 819/system_server10% 996/com.android.systemui4.6% 2215/com.android.phone...... 復制代碼光看Logcat中的日志只能看到這些信息，大概知道是在MainActivity出現了問題，但還是不能清楚的定位到發生ANR的代碼行，想要獲得進一步的錯誤信息只能通過查看ANR過程中生成的堆棧信息文件traces.txt了。
traces.txt文件位置在/data/anr/目錄下，可以通過以下adb命令將其拷貝到sd卡目錄下獲取查看。
adb shell cat /data/anr/traces.txt >/mnt/sdcard/traces.txt exit 復制代碼traces.txt里的信息：
DALVIK THREADS (42): "main" prio=5 tid=1 Native| group="main" sCount=1 dsCount=0 obj=0x75ceafb8 self=0x55933ae7e0| sysTid=7398 nice=0 cgrp=default sched=0/0 handle=0x7f7ddae0f0| state=S schedstat=( 101485399944 3411372871 31344 ) utm=9936 stm=212 core=1 HZ=100| stack=0x7fc8d40000-0x7fc8d42000 stackSize=8MB| held mutexes=kernel: __switch_to+0x74/0x8ckernel: futex_wait_queue_me+0xcc/0x158kernel: futex_wait+0x120/0x20ckernel: do_futex+0x184/0xa48kernel: SyS_futex+0x88/0x19ckernel: cpu_switch_to+0x48/0x4cnative: #00 pc 00017750 /system/lib64/libc.so (syscall+28)native: #01 pc 000d1584 /system/lib64/libart.so (_ZN3art17ConditionVariable4WaitEPNS_6ThreadE+140)native: #02 pc 00388098 /system/lib64/libart.so (_ZN3artL12GoToRunnableEPNS_6ThreadE+1068)native: #03 pc 000a5db8 /system/lib64/libart.so (_ZN3art12JniMethodEndEjPNS_6ThreadE+24)native: #04 pc 000280e4 /data/dalvik-cache/arm64/system@framework@boot.oat (Java_android_graphics_Paint_native_1init__+156)at android.graphics.Paint.native_init(Native method)at android.graphics.Paint.<init>(Paint.java:435)at android.graphics.Paint.<init>(Paint.java:425)at android.text.TextPaint.<init>(TextPaint.java:49)at android.text.Layout.<init>(Layout.java:160)at android.text.StaticLayout.<init>(StaticLayout.java:111)at android.text.StaticLayout.<init>(StaticLayout.java:87)at android.text.StaticLayout.<init>(StaticLayout.java:66)at android.widget.TextView.makeSingleLayout(TextView.java:6543)at android.widget.TextView.makeNewLayout(TextView.java:6383)at android.widget.TextView.checkForRelayout(TextView.java:7096)at android.widget.TextView.setText(TextView.java:4082)at android.widget.TextView.setText(TextView.java:3940)at android.widget.TextView.setText(TextView.java:3915)at com.xxxx.performance.view.home.fragment.AttendanceCheckInFragment.onNowTimeSuccess(AttendanceCheckInFragment.java:887)at com.xxxx.performance.presenter.attendance.AttendanceFragmentPresenter$6.onNext(AttendanceFragmentPresenter.java:214)at com.xxxx.performance.presenter.attendance.AttendanceFragmentPresenter$6.onNext(AttendanceFragmentPresenter.java:205)at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.drainNormal(ObservableObserveOn.java:198)at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.run(ObservableObserveOn.java:250)at io.reactivex.android.schedulers.HandlerScheduler$ScheduledRunnable.run(HandlerScheduler.java:109)............ 復制代碼還是從頭開始看，來看每個字段對應的含義：
線程名：main
線程優先級：prio=5
線程鎖ID： tid=1
線程狀態：Native 線程組名稱：group="main"
線程被掛起的次數：sCount=1
線程被調試器掛起的次數：dsCount=0
線程的java的對象地址：obj=0x75ceafb8
線程本身的Native對象地址：self=0x55933ae7e0
線程調度信息：
Linux系統中內核線程ID: sysTid=7398與主線程的進程號相同
線程調度優先級：nice=0
線程調度組：cgrp=default
線程調度策略和優先級：sched=0/0
線程處理函數地址：handle=0x7f7ddae0f0
線程的上下文信息：
線程調度狀態：state=S
線程在CPU中的執行時間、線程等待時間、線程執行的時間片長度：schedstat=(101485399944 3411372871 31344 )
線程在用戶態中的調度時間值：utm=9936
線程在內核態中的調度時間值：stm=212
最后執行這個線程的CPU核序號：core=1
線程的堆棧信息：
堆棧地址和大小：stack=0x7fc8d40000-0x7fc8d42000 stackSize=8MB
最后看到堆棧信息里的這一行：
這里就看清楚了是在AttendanceCheckInFragment中的887行出現的問題，再到對應代碼行中就很容易發現ANR的原因了。
5、ANR的相關問題
- 在Activity的onCreate方法里調用sleep方法會發生ANR嗎？
以前一直認為在主線程做了耗時操作就會發生ANR，那么真的是這樣嗎？在Activity的onCreate方法里調用Thread.sleep(60 * 1000)讓主線程sleep60秒，會導致應用程序ANR嗎？寫個Demo測試一下。
public class MainActivity extends AppCompatActivity {@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.activity_main);try {Log.d("ANR","開始sleep");Thread.sleep(60*1000);Log.d("ANR","sleep完成");} catch (InterruptedException e) {e.printStackTrace();}} } 復制代碼如上代碼，運行程序，結果應用沒有發生ANR,在sleep了60秒后正常打印日志。
再次運行程序，這回在程序運行后按下返回鍵查看現象： 這次果然就ANR了。通過這個例子，顯而易見的得到了這個問題的正確答案。在Activity的onCreate方法里調用sleep方法或者說做耗時操作，不一定會產生ANR。其實從ANR本身意為應用程序沒有響應，同時根據上面總結的ANR原因就可以看出，耗時操作本身是不會產生ANR的，導致ANR的根本還是應用程序無法在一定時間內響應用戶的操作。所以因為主線程被耗時操作占用了，主線成程無法對下一個操作進行響應才會ANR，沒有需要響應的操作自然就不會產生ANR，或者應該這樣說:主線程做耗時操作，非常容易引發ANR。6、總結
- 光在主線程做耗時操作不會產生ANR，超時響應用戶操作才會產生ANR。
- ANR的定位方法主要是根據Logcat中日志和ANR過程中生成的堆棧信息文件traces.txt。
- 解決問題不如預防問題，寫代碼的時候要注意預防產生ANR。
- 預防ANR的產生不光是在Activity中注意要把耗時操作放到子線程中去，還要注意在使用其他三個組件時，在其生命周期中同樣不能做太耗時的操作。另外在使用多線程時候要注意同步和死鎖的情況，一旦產生死鎖主線程同樣會引發ANR。
轉載于:https://juejin.im/post/5d171455f265da1b61500d17
總結
以上是生活随笔為你收集整理的Android进阶知识：ANR的定位与解决的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 第九章 结构体与共用体
- 下一篇： UA池和IP代理池使用