為什么會產(chǎn)生ANR

ANR 是英文Application Not Response 的縮寫审胸，也就是當前的應用未響應尼变±眨“臨床”表現(xiàn)為當前的應用滑動無響應，點擊無響應嫌术，輸入無響應哀澈。等待一會后有些手機會直接閃退（比如oppo），有些手機會有彈框“當前應用未響應度气，是否結(jié)束”日丹。然后你可以選擇結(jié)束應用或繼續(xù)等待。是否有彈框選擇對于我們開發(fā)人員來說可以去開發(fā)者設(shè)置里面進行設(shè)置蚯嫌，但是對于普通用戶來說哲虾，閃退了就是閃退了丙躏，跟crash的用戶體感是一樣的

產(chǎn)生anr情況

首先為什么會產(chǎn)生ANR？其實以下四種場景總結(jié)起來一句話：UI線程沒有辦法在規(guī)定的時間內(nèi)做出本應當做的事情束凑。

1InputDispatching Timeout

這個Timeout 引發(fā)的anr表示5s內(nèi)無法響應屏幕的點擊事件或者輸入事件晒旅。inputDispatching 的超時事件是一個native層的引發(fā)的anr，我們這里由于篇幅所限制不做擴展

2 廣播的onReceiver()在規(guī)定的事件內(nèi)無法被處理完

Android 系統(tǒng)定義了如果廣播的onReceiver()事件在規(guī)定的時間內(nèi)無法被執(zhí)行完汪诉，那么系統(tǒng)就會拋出ANR異常废恋，其中：
前臺廣播：10s
后臺廣播：60s
整個流程是如何判斷的呢？我們接下來就進入源碼的世界中

BroadcastQueue

我們看一下BroadcastQueue里面的重要方法

 public void scheduleBroadcastsLocked() {
        if (DEBUG_BROADCAST) Slog.v(TAG_BROADCAST, "Schedule broadcasts ["
                + mQueueName + "]: current="
                + mBroadcastsScheduled);

        if (mBroadcastsScheduled) {
            return;
        }
        mHandler.sendMessage(mHandler.obtainMessage(BROADCAST_INTENT_MSG, this));
        mBroadcastsScheduled = true;
    }

這里我們看到是通過handler的方法發(fā)送了一個廣播的intent Message扒寄。我們再往后追鱼鼓，handler的回調(diào)中處理這個消息后調(diào)用了processNextBroadcastLocked()方法。我們看一下源碼该编，這里篇幅較長迄本，我們只截取了核心的調(diào)用方法

    final void processNextBroadcast(boolean fromMsg) {
        broadcastTimeoutLocked(false);     
        setBroadcastTimeoutLocked(timeoutTime); 
        cancelBroadcastTimeoutLocked();
    }

我們看一下

final void setBroadcastTimeoutLocked(long timeoutTime) {
        if (! mPendingBroadcastTimeoutMessage) {
            Message msg = mHandler.obtainMessage(BROADCAST_TIMEOUT_MSG, this);
            mHandler.sendMessageAtTime(msg, timeoutTime);
            mPendingBroadcastTimeoutMessage = true;
        }
    }

整個的核心思路就是發(fā)送一個延時的message，當時間到達的時候课竣，觸發(fā)handler的回調(diào)嘉赎，這個時候回去檢查當前的超時廣播事件監(jiān)聽有沒有被remove掉，如果沒有被remove掉于樟，就表明當前的廣播執(zhí)行超時了公条。我們看一下超時的處理

 scheduleBroadcastsLocked(){

        if (anrMessage != null) {
            // Post the ANR to the handler since we do not want to process ANRs while
            // potentially holding our lock.
            mHandler.post(new AppNotResponding(app, anrMessage));
        }
}

有注釋也可以看出，這個handler會拋往ActivityManagerService迂曲，執(zhí)行anr處理的流程靶橱。這個流程我們在下面進行分析

3 Service 組件引發(fā)的ANR

我們都知道，service里面是不可以做耗時操作的路捧，我們先拋出結(jié)果：
前臺service：20s
后臺service：200s
超過這兩個時間抓韩，我們的應用程序也會拋出ANR。
接下來我們進入源碼分析鬓长。我們知道應用冷啟動的時候谒拴，ActvityManagerService的attachApplicationLocked方法會通知ActivityThread 把當前的application 創(chuàng)建起來。attachApplicationLocked里面有一個重要的邏輯涉波，就是會判斷當前有沒有需要執(zhí)行的Service

// Find any services that should be running in this process...
        if (!badApp) {
            try {
                didSomething |= mServices.attachApplicationLocked(app, processName);
                checkTime(startTime, "attachApplicationLocked: after mServices.attachApplicationLocked");
            } catch (Exception e) {
                Slog.wtf(TAG, "Exception thrown starting services in " + app, e);
                badApp = true;
            }
        }

進入ActiveService.java的類后英上，核心的“挖坑”的地方就是這個方法

   void scheduleServiceTimeoutLocked(ProcessRecord proc) {
        if (proc.executingServices.size() == 0 || proc.thread == null) {
            return;
        }
        Message msg = mAm.mHandler.obtainMessage(
                ActivityManagerService.SERVICE_TIMEOUT_MSG);
        msg.obj = proc;
        mAm.mHandler.sendMessageDelayed(msg,
                proc.execServicesFg ? SERVICE_TIMEOUT : SERVICE_BACKGROUND_TIMEOUT);
    }

這個流程就和廣播的ANR超時處理機制很像了。一樣就是開啟一個定時消息啤覆。如果這個定時消息沒有被取消苍日，那么就會走ANR的處理邏輯，拋出異常

 void serviceTimeout(ProcessRecord proc) {
        ...
        if (anrMessage != null) {
            mAm.mAppErrors.appNotResponding(proc, null, null, false, anrMessage);
        }
    }

4 Contentprovider publish 引發(fā)的異常

還是回到萬能的ActivityManagerService的attachApplicationLocket()方法中窗声，查看關(guān)鍵的contentprovider 流程處理相關(guān)

 List<ProviderInfo> providers = normalMode ? generateApplicationProvidersLocked(app) : null;

        if (providers != null && checkAppInLaunchingProvidersLocked(app)) {
            Message msg = mHandler.obtainMessage(CONTENT_PROVIDER_PUBLISH_TIMEOUT_MSG);
            msg.obj = app;
            mHandler.sendMessageDelayed(msg, CONTENT_PROVIDER_PUBLISH_TIMEOUT);
        }

還是這個熟悉的流程相恃，發(fā)送定時Message，如果能收到這個笨觅，說明當前CP的發(fā)布10s超時拦耐，從而引發(fā)ANR

四大組件產(chǎn)生的原因小結(jié)

其實總結(jié)上面的幾個流程耕腾，簡單來說就是一個挖坑，掉坑和填坑的過程
挖坑：發(fā)送定時消息
填坑：正常處理流程杀糯，成功后remove本條message
掉坑：無法正常處理流程扫俺，定時消息成功接受，觸發(fā)anr固翰，掉進坑里去

發(fā)生anr后狼纬，系統(tǒng)做了什么

我們從上文的分析中可以看到，所有的ANR錯誤最后都會走到AppErrors里面的appNotResponding里面骂际。下面我們用流程圖進行分析

ANR處理流程

anr 監(jiān)控的原理和方法

1 監(jiān)聽Looper Log的時間

思路
在Looper的loop()方法中疗琉，我們可以看到在調(diào)用msg的dispatchMessage方法的前后有兩個logger的日志打印。那么我們就可以采用這個方法歉铝，定義一個Printer類盈简，去計算這兩個Logger的打印時間，這樣就可以準確的判斷出是否發(fā)生了ANR
優(yōu)點
靈活配置犯戏，可以準備的得到發(fā)生ANR的時間和調(diào)用棧送火；
缺點：
1 不能覆蓋所有的場景拳话，有些anr并不通過dispatchMessage方法調(diào)用先匪，比如input事件的ANR
2 Logger有可能被第三方所接管
3 dispatchMessage方法如果執(zhí)行時間過長，同樣也無法觸發(fā)計算

2 定時往主線程發(fā)一個時間弃衍，如果5s后沒有響應呀非，那么就是發(fā)生anr了

思路
啟用一個線程向主線程定時發(fā)送一個消息a，然后線程進行休眠镜盯，等到時間結(jié)束后去檢查判斷這個值是否變成了a+1岸裙，如果沒有，說明發(fā)生了anr
優(yōu)點
1 無侵入速缆，對工程項目比較友好
2 代碼簡單降允，流程比較容易理解
3 沒有兼容問題，通殺
缺點
1 不能保證所有場景都可以觸發(fā)艺糜，另外這個休眠的時間閥值不好控制

3 監(jiān)聽fileobserve的ANR路徑的讀寫

思路
監(jiān)聽data/anr 文件路徑下的文件讀寫的變化剧董，因為一旦發(fā)生了anr，系統(tǒng)就會往這個路徑創(chuàng)建anr文件
缺點
隨著Android對文件讀寫權(quán)限的嚴格把控破停，這個思路現(xiàn)在已經(jīng)不可用了～

4 監(jiān)聽廣播

思路
監(jiān)聽“android.intent.action.ANR“廣播
“缺點”
所有發(fā)生ANR的應用都會發(fā)出這個廣播翅楼，因此就容易發(fā)生“誤報”。所以需要在接收到廣播的時候進行過濾

日常開發(fā)如何盡量避免anr

1 小心使用SharedPreferences
2 多線程情況下選用線程池
3 不要在主線程做耗時操作
4 跨進程也有可能引發(fā)anr（cpu搶占）

深入分析ANR