為什么會產生ANR

ANR 是英文Application Not Response 的縮寫，也就是當前的應用未響應。“臨床”表現為當前的應用滑動無響應，點擊無響應，輸入無響應。等待一會后有些手機會直接閃退（比如oppo），有些手機會有彈框“當前應用未響應，是否結束”。然后你可以選擇結束應用或繼續等待。是否有彈框選擇對于我們開發人員來說可以去開發者設置里面進行設置，但是對于普通用戶來說，閃退了就是閃退了，跟crash的用戶體感是一樣的

產生anr情況

首先為什么會產生ANR？其實以下四種場景總結起來一句話：UI線程沒有辦法在規定的時間內做出本應當做的事情。

1InputDispatching Timeout

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

2 廣播的onReceiver()在規定的事件內無法被處理完

Android 系統定義了如果廣播的onReceiver()事件在規定的時間內無法被執行完，那么系統就會拋出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的方法發送了一個廣播的intent Message。我們再往后追，handler的回調中處理這個消息后調用了processNextBroadcastLocked()方法。我們看一下源碼，這里篇幅較長，我們只截取了核心的調用方法

    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;
        }
    }

整個的核心思路就是發送一個延時的message，當時間到達的時候，觸發handler的回調，這個時候回去檢查當前的超時廣播事件監聽有沒有被remove掉，如果沒有被remove掉，就表明當前的廣播執行超時了。我們看一下超時的處理

 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，執行anr處理的流程。這個流程我們在下面進行分析

3 Service 組件引發的ANR

我們都知道，service里面是不可以做耗時操作的，我們先拋出結果：
前臺service：20s
后臺service：200s
超過這兩個時間，我們的應用程序也會拋出ANR。
接下來我們進入源碼分析。我們知道應用冷啟動的時候，ActvityManagerService的attachApplicationLocked方法會通知ActivityThread 把當前的application 創建起來。attachApplicationLocked里面有一個重要的邏輯，就是會判斷當前有沒有需要執行的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 引發的異常

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

 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);
        }

還是這個熟悉的流程，發送定時Message，如果能收到這個，說明當前CP的發布10s超時，從而引發ANR

四大組件產生的原因小結

其實總結上面的幾個流程，簡單來說就是一個挖坑，掉坑和填坑的過程
挖坑：發送定時消息
填坑：正常處理流程，成功后remove本條message
掉坑：無法正常處理流程，定時消息成功接受，觸發anr，掉進坑里去

發生anr后，系統做了什么

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

ANR處理流程

anr 監控的原理和方法

1 監聽Looper Log的時間

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

2 定時往主線程發一個時間，如果5s后沒有響應，那么就是發生anr了

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

3 監聽fileobserve的ANR路徑的讀寫

思路
監聽data/anr 文件路徑下的文件讀寫的變化，因為一旦發生了anr，系統就會往這個路徑創建anr文件
缺點
隨著Android對文件讀寫權限的嚴格把控，這個思路現在已經不可用了～

4 監聽廣播

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

日常開發如何盡量避免anr

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