看完這篇 Android ANR 分析，就可以和麵試官裝逼了！
ANR概述
首先，ANR(Application Not responding)是指應用程式未響應，Android系統對於一些事件需要在一定的時間範圍內完成，如果超過預定時間能未能得到有效響應或者響應時間過長，都會造成ANR。ANR由訊息處理機制保證，Android在系統層實現了一套精密的機制來發現ANR，核心原理是訊息排程和超時處理。
其次，ANR機制主體實現在系統層。所有與ANR相關的訊息，都會經過系統程序(system_server)排程，然後派發到應用程序完成對訊息的實際處理，同時，系統程序設計了不同的超時限制來跟蹤訊息的處理。 一旦應用程式處理訊息不當，超時限制就起作用了，它收集一些系統狀態，譬如CPU/IO使用情況、程序函式呼叫棧，並且報告使用者有程序無響應了(ANR對話方塊)。
然後，ANR問題本質是一個性能問題。ANR機制實際上對應用程式主執行緒的限制，要求主執行緒在限定的時間內處理完一些最常見的操作(啟動服務、處理廣播、處理輸入)， 如果處理超時，則認為主執行緒已經失去了響應其他操作的能力。主執行緒中的耗時操作，譬如密集CPU運算、大量IO、複雜介面佈局等，都會降低應用程式的響應能力。
哪些場景會造成ANR？
- 發生ANR時會呼叫AppNotRespondingDialog.show()方法彈出對話方塊提示使用者，該對話方塊的依次呼叫關係如下圖所示：
- AppErrors.appNotResponding()，該方法是最終彈出ANR對話方塊的唯一入口，呼叫該方法的場景才會有ANR提示，也可以認為在主執行緒中執行無論再耗時的任務，只要最終不呼叫該方法，都不會有ANR提示，也不會有ANR相關日誌及報告；通過呼叫關係可以看出哪些場景會導致ANR，有以下四種場景：
（1）Service Timeout:Service在特定的時間內無法處理完成
（2）BroadcastQueue Timeout：BroadcastReceiver在特定時間內無法處理完成
（3）ContentProvider Timeout：內容提供者執行超時
（4）inputDispatching Timeout: 按鍵或觸控事件在特定時間內無響應。
ANR機制
ANR機制可以分為兩部分：
ANR監測機制：Android對於不同的ANR型別(Broadcast, Service, InputEvent)都有一套監測機制。
ANR報告機制：在監測到ANR以後，需要顯示ANR對話方塊、輸出日誌(發生ANR時的程序函式呼叫棧、CPU使用情況等)。
整個ANR機制的程式碼也是橫跨了Android的幾個層：
- App層：應用主執行緒的處理邏輯；
- Framework層：ANR機制的核心，主要有AMS、BroadcastQueue、ActiveServices、InputmanagerService、InputMonitor、InputChannel、ProcessCpuTracker等；
- Native層：InputDispatcher.cpp；
Provider超時機制遇到的比較少，暫不做分析；Broadcast目前主要想說兩個知識點：
第一：無論是普通廣播還是有序廣播，最終廣播接受者的onreceive都是序列執行的，可以通過Demo進行驗證；
第二：通過Demo以及框架新增相關日誌，都驗證了普通廣播也會有ANR監測機制，ANR機制以及問題分析文章認為只有序列廣播才有ANR監測機制，後續再會專門講解Broadcast傳送及接收流程，同時也會補充Broadcast ANR監測機制；本文主要以Servie處理超時、輸入事件分發超時為例探討ANR監測機制。
Service超時監測機制
Service執行在應用程式的主執行緒，如果Service的執行時間超過20秒，則會引發ANR。
當發生Service ANR時，一般可以先排查一下在Service的生命週期函式中(onCreate(), onStartCommand()等)有沒有做耗時的操作，譬如複雜的運算、IO操作等。 如果應用程式的程式碼邏輯查不出問題，就需要深入檢查當前系統的狀態：CPU的使用情況、系統服務的狀態等，判斷當時發生ANR程序是否受到系統執行異常的影響。
如何檢測Service超時呢？Android是通過設定定時訊息實現的。定時訊息是由AMS的訊息佇列處理的(system_server的ActivityManager執行緒)。 AMS有Service執行的上下文資訊，所以在AMS中設定一套超時檢測機制也是合情合理的。
我們先丟擲兩個問題
- 問題一：Service啟動流程？
- 問題一：如何監測Service超時？
主要通過以上兩個問題來說明Service監測機制，在知道Service啟動流程之後，通過Service啟動流程可以更容易分析Service超時監測機制。
- Service啟動流程如下圖所示：
（1）ActiveServices.realStartServiceLocked()在通過app.thread的scheduleCreateService()來建立Service物件並呼叫Service.onCreate()後，接著又呼叫sendServiceArgsLocked()方法來呼叫Service的其他方法，如onStartCommand。以上兩步均是程序間通訊，應用與AMS之間跨程序通訊可以參考應用程序與系統程序通訊
（2）以上只是列出Service啟動流程的關鍵步驟，具體每個方法主要做哪些工作還需要檢視具體的程式碼，暫時先忽略這些，感興趣的可以參考Android開發藝術探索等其他相關資料
- Service超時監測機制
Service超時監測機制可以從Service啟動流程中找到。
（1）ActiveServices.realStartServiceLocked()主要工作有
privatefinalvoidrealStartServiceLocked(ServiceRecord r,
ProcessRecord app, booleanexecInFg)throwsRemoteException {
...
// 主要是為了設定ANR超時，可以看出在正式啟動Service之前開始ANR監測；
bumpServiceExecutingLocked(r, execInFg, "create");
// 啟動過程呼叫scheduleCreateService方法,最終會呼叫Service.onCreate方法；
app.thread.scheduleCreateService(r, r.serviceInfo,
// 繫結過程中，這個方法中會呼叫app.thread.scheduleBindService方法
requestServiceBindingsLocked(r, execInFg);
// 調動Service的其他方法，如onStartCommand，也是IPC通訊
sendServiceArgsLocked(r, execInFg, true);
}
（2）bumpServiceExecutingLocked()會呼叫scheduleServiceTimeoutLocked()方法
voidscheduleServiceTimeoutLocked(ProcessRecord proc) {
if(proc.executingServices.size() == 0|| proc.thread == null) {
return;
}
Message msg = mAm.mHandler.obtainMessage(
ActivityManagerService.SERVICE_TIMEOUT_MSG);
msg.obj = proc;
// 在serviceDoneExecutingLocked中會remove該SERVICE_TIMEOUT_MSG訊息，
// 當超時後仍沒有remove SERVICE_TIMEOUT_MSG訊息，則執行ActiveServices. serviceTimeout()方法；
mAm.mHandler.sendMessageDelayed(msg,
proc.execServicesFg ? SERVICE_TIMEOUT : SERVICE_BACKGROUND_TIMEOUT);
// 前臺程序中執行Service，SERVICE_TIMEOUT=20s；後臺程序中執行Service，SERVICE_BACKGROUND_TIMEOUT=200s
}
（3）如果在指定的時間內還沒有serviceDoneExecutingLocked()方法將訊息remove掉，就會呼叫ActiveServices. serviceTimeout()方法
voidserviceTimeout(ProcessRecord proc){
...
finallongmaxTime = now -
(proc.execServicesFg ? SERVICE_TIMEOUT : SERVICE_BACKGROUND_TIMEOUT);
...
// 尋找執行超時的Service
for(inti=proc.executingServices.size()-1; i>=0; i--) {
ServiceRecord sr = proc.executingServices.valueAt(i);
if(sr.executingStart < maxTime) {
timeout = sr;
break;
}
...
}
...
// 判斷執行Service超時的程序是否在最近執行程序列表，如果不在，則忽略這個ANR
if(timeout != null&& mAm.mLruProcesses.contains(proc)) {
anrMessage = "executing service "+ timeout.shortName;
}
...
if(anrMessage != null) {
// 當存在timeout的service，則執行appNotResponding，報告ANR
mAm.appNotResponding(proc, null, null, false, anrMessage);
}
}
（4）Service onCreate超時監測整體流程如下圖
在onCreate生命週期開始執行前，啟動超時監測，如果在指定的時間onCreate沒有執行完畢（該該方法中執行耗時任務），就會呼叫ActiveServices.serviceTimeout()方法報告ANR；如果在指定的時間內onCreate執行完畢，那麼就會呼叫ActivityManagerService.serviceDoneExecutingLocked()方法移除SERVICE_TIMEOUT_MSG訊息，說明Service.onCreate方法沒有發生ANR，Service是由AMS排程，利用Handler和Looper，設計了一個TIMEOUT訊息交由AMS執行緒來處理，整個超時機制的實現都是在Java層；以上就是Service超時監測的整體流程。
輸入事件超時監測
應用程式可以接收輸入事件(按鍵、觸屏、軌跡球等)，當5秒內沒有處理完畢時，則會引發ANR。
這裡先把問題丟擲來了：
輸入事件經歷了一些什麼工序才能被派發到應用的介面？
如何檢測到輸入時間處理超時？
1. Android輸入系統簡介
Android輸入系統總體流程與參與者如下圖所示。
簡單來說，核心將原始事件寫入到裝置節點中，InputReader在其執行緒迴圈中不斷地從EventHub中抽取原始輸入事件，進行加工處理後將加工所得的事件放入InputDispatcher的派發發佇列中。InputDispatcher則在其執行緒迴圈中將派發佇列中的事件取出，查詢合適的視窗，將事件寫入到視窗的事件接收管道中。視窗事件接收執行緒的Looper從管道中將事件取出，交由視窗事件處理函式進行事件響應。關鍵流程有：原始輸入事件的讀取與加工；輸入事件的派發；輸入事件的傳送、接收與反饋。其中輸入事件派發是指InputDispatcher不斷的從派發佇列取出事件、尋找合適的視窗進行傳送的過程，輸入事件的傳送是InputDispatcher通過Connection物件將事件傳送給視窗的過程。
InputDispatcher與視窗之間的跨程序通訊主要通過InputChannel來完成。在InputDispatcher與視窗通過InputChannel建立連線之後，就可以進行事件的傳送、接收與反饋；輸入事件的傳送和接收主要流程如圖所示：
其中，將輸入事件注入派發佇列後，會喚醒派發執行緒，派發執行緒迴圈由InputDispatcher.dispatchOnce函式完成；InputDispatcher將事件以InputMessage寫入InputChannel之後，視窗端的looper被喚醒，進而執行NativeInputReceiver::handleEvent()開始輸入事件的接收，從InputEventReceiver開始輸入事件被派發到使用者介面；以上只是輸入事件的大致流程，更詳細的流程可以參考相關資料；在瞭解輸入系統的大致流程之後，我們來分析輸入事件的超時監測機制。
2. 輸入事件超時監測
按鍵事件超時監測整體流程如下圖所示
（1）InputDispatcher::dispatchOnceInnerLocked():
根據事件型別選擇不同事件的處理方法：InputDispatcher::dispatchKeyLocked()或者InputDispatcher::dispatchMotionLocked()，我們以按鍵事件超時監測為例進行說明；
（2）findFocusedWindowTargetsLocked()方法會呼叫checkWindowReadyForMoreInputLocked（）;該方法檢查視窗是否有能力再接收新的輸入事件；可能會有一系列的場景阻礙事件的繼續派發，相關場景有：
場景1: 視窗處於paused狀態，不能處理輸入事件
“Waiting because the [targetType] window is paused.”
場景2: 視窗還未向InputDispatcher註冊，無法將事件派發到視窗
“Waiting because the [targetType] window’s input channel is not registered with the input dispatcher. The window may be in the process of being removed.”
場景3: 視窗和InputDispatcher的連線已經中斷，即InputChannel不能正常工作
“Waiting because the [targetType] window’s input connection is [status]. The window may be in the process of being removed.”
場景4: InputChannel已經飽和，不能再處理新的事件
“Waiting because the [targetType] window’s input channel is full. Outbound queue length: %d. Wait queue length: %d.”
場景5: 對於按鍵型別(KeyEvent)的輸入事件，需要等待上一個事件處理完畢
“Waiting to send key event because the [targetType] window has not finished processing all of the input events that were previously delivered to it. Outbound queue length: %d. Wait queue length: %d.”
場景6: 對於觸控型別(TouchEvent)的輸入事件，可以立即派發到當前的視窗，因為TouchEvent都是發生在使用者當前可見的視窗。但有一種情況， 如果當前應用由於佇列有太多的輸入事件等待派發，導致發生了ANR，那TouchEvent事件就需要排隊等待派發。
“Waiting to send non-key event because the %s window has not finished processing certain input events that were delivered to it over %0.1fms ago. Wait queue length: %d. Wait queue head age: %0.1fms.”
以上這些場景就是我們常在日誌中看到的ANR原因的列印。
（3）其中事件分發5s限制定義在InputDispatcher.cpp；InputDispatcher::handleTargetsNotReadyLocked（）方法中如果事件5s之內還沒有分發完畢，則呼叫InputDispatcher::onANRLocked()提示使用者應用發生ANR；
//預設分發超時間為5s
constnsecs_tDEFAULT_INPUT_DISPATCHING_TIMEOUT = 5000* 1000000LL;
int32_tInputDispatcher::handleTargetsNotReadyLocked(nsecs_tcurrentTime,
constEventEntry* entry,
constsp<InputApplicationHandle>& applicationHandle,
constsp<InputWindowHandle>& windowHandle,
nsecs_t* nextWakeupTime, constchar* reason) {
// 1.如果當前沒有聚焦視窗，也沒有聚焦的應用
if(applicationHandle == NULL&& windowHandle == NULL) {
...
} else{
// 2.有聚焦視窗或者有聚焦的應用
if(mInputTargetWaitCause != INPUT_TARGET_WAIT_CAUSE_APPLICATION_NOT_READY) {
// 獲取等待的時間值
if(windowHandle != NULL) {
// 存在聚焦視窗，DEFAULT_INPUT_DISPATCHING_TIMEOUT事件為5s
timeout = windowHandle->getDispatchingTimeout(DEFAULT_INPUT_DISPATCHING_TIMEOUT);
} elseif(applicationHandle != NULL) {
// 存在聚焦應用，則獲取聚焦應用的分發超時時間
timeout = applicationHandle->getDispatchingTimeout(
DEFAULT_INPUT_DISPATCHING_TIMEOUT);
} else{
// 預設的分發超時時間為5s
timeout = DEFAULT_INPUT_DISPATCHING_TIMEOUT;
}
}
}
// 如果當前時間大於輸入目標等待超時時間，即當超時5s時進入ANR處理流程
// currentTime 就是系統的當前時間，mInputTargetWaitTimeoutTime 是一個全域性變數,
if(currentTime >= mInputTargetWaitTimeoutTime) {
// 呼叫ANR處理流程
onANRLocked(currentTime, applicationHandle, windowHandle,
entry->eventTime, mInputTargetWaitStartTime, reason);
// 返回需要等待處理
returnINPUT_EVENT_INJECTION_PENDING;
}
}
（4）當應用主執行緒被卡住的事件，再點選該應用其它元件也是無響應，因為事件派發是序列的，上一個事件不處理完畢，不會處理下一個事件。
（5）Activity.onCreate執行耗時操作，不管使用者如何操作都不會發生ANR，因為輸入事件相關監聽機制還沒有建立起來；InputChannel通道還沒有建立
這時是不會響應輸入事件，InputDispatcher還不能事件傳送到應用視窗，ANR監聽機制也還沒有建立，所以此時是不會報告ANR的。
（6）輸入事件由InputDispatcher排程，待處理的輸入事件都會進入佇列中等待，設計了一個等待超時的判斷，超時機制的實現在Native層。
以上就是輸入事件ANR監測機制；具體邏輯請參考相關原始碼；
ANR報告機制
無論哪種型別的ANR發生以後，最終都會呼叫 AppErrors.appNotResponding() 方法，所謂“殊途同歸”。這個方法的職能就是向用戶或開發者報告ANR發生了。 最終的表現形式是：彈出一個對話方塊，告訴使用者當前某個程式無響應;輸入一大堆與ANR相關的日誌，便於開發者解決問題。
final void appNotResponding(ProcessRecord app, ActivityRecord activity,
ActivityRecord parent, boolean aboveSystem, final String annotation) {
...
if(ActivityManagerService.MONITOR_CPU_USAGE) {
// 1. 更新CPU使用資訊。ANR的第一次CPU資訊取樣，取樣資料會儲存在mProcessStats這個變數中
mService.updateCpuStatsNow();
}
// 記錄ANR到EventLog中
EventLog.writeEvent(EventLogTags.AM_ANR, app.userId, app.pid,
app.processName, app.info.flags, annotation);
// 輸出ANR到main log.
StringBuilder info = newStringBuilder();
info.setLength(0);
info.append("ANR in ").append(app.processName);
if(activity != null && activity.shortComponentName != null) {
info.append(" (").append(activity.shortComponentName).append(")");
}
info.append("n");
info.append("PID: ").append(app.pid).append("n");
if(annotation != null) {
info.append("Reason: ").append(annotation).append("n");
}
if(parent != null && parent != activity) {
info.append("Parent: ").append(parent.shortComponentName).append("n");
}
// 3. 列印呼叫棧。具體實現由dumpStackTraces()函式完成
File tracesFile = ActivityManagerService.dumpStackTraces(
true, firstPids,
(isSilentANR) ? null : processCpuTracker,
(isSilentANR) ? null : lastPids,
nativePids);
String cpuInfo = null;
// MONITOR_CPU_USAGE預設為true
if(ActivityManagerService.MONITOR_CPU_USAGE) {
// 4. 更新CPU使用資訊。ANR的第二次CPU使用資訊取樣。兩次取樣的資料分別對應ANR發生前後的CPU使用情況
mService.updateCpuStatsNow();
synchronized (mService.mProcessCpuTracker) {
// 輸出ANR發生前一段時間內各個程序的CPU使用情況
cpuInfo = mService.mProcessCpuTracker.printCurrentState(anrTime);
}
// 輸出CPU負載
info.append(processCpuTracker.printCurrentLoad());
info.append(cpuInfo);
}
// 輸出ANR發生後一段時間內各個程序的CPU使用率
info.append(processCpuTracker.printCurrentState(anrTime));
//會打印發生ANR的原因，如輸入事件導致ANR的不同場景
Slog.e(TAG, info.toString());
if(tracesFile == null) {
// There is no trace file, so dump (only) the alleged culprit's threads to the log
// 傳送signal 3(SIGNAL_QUIT)來dump棧資訊
Process.sendSignal(app.pid, Process.SIGNAL_QUIT);
}
// 將anr資訊同時輸出到DropBox
mService.addErrorToDropBox("anr", app, app.processName, activity, parent, annotation,
cpuInfo, tracesFile, null);
// Bring up the infamous App Not Responding dialog
// 5. 顯示ANR對話方塊。丟擲SHOW_NOT_RESPONDING_MSG訊息，
// AMS.MainHandler會處理這條訊息，顯示AppNotRespondingDialog對話方塊提示使用者發生ANR
Message msg = Message.obtain();
HashMap<String, Object> map= newHashMap<String, Object>();
msg.what = ActivityManagerService.SHOW_NOT_RESPONDING_UI_MSG;
msg.obj = map;
msg.arg1 = aboveSystem ? 1: 0;
map.put("app", app);
if(activity != null) {
map.put("activity", activity);
}
mService.mUiHandler.sendMessage(msg);
}
}
除了主體邏輯，發生ANR時還會輸出各種類別的日誌：
event log：通過檢索”am_anr”關鍵字，可以找到發生ANR的應用
main log：通過檢索”ANR in “關鍵字，可以找到ANR的資訊，日誌的上下文會包含CPU的使用情況
dropbox：通過檢索”anr”型別，可以找到ANR的資訊
traces：發生ANR時，各程序的函式呼叫棧資訊
至此ANR相關報告已經完成，後續需要分析ANR問題，分析ANR往往是從main log中的CPU使用情況和traces中的函式呼叫棧開始。所以，更新CPU的使用資訊updateCpuStatsNow()方法和列印函式棧dumpStackTraces()方法，是系統報告ANR問題關鍵所在，具體分析ANR問題請參考相關資料。
總結
- ANR的監測機制：首先分析Service和輸入事件大致工作流程，然後從Service，InputEvent兩種不同的ANR監測機制的原始碼實現開始，分析了Android如何發現各類ANR。在啟動服務、輸入事件分發時，植入超時檢測，用於發現ANR。
- ANR的報告機制：分析Android如何輸出ANR日誌。當ANR被發現後，兩個很重要的日誌輸出是：CPU使用情況和程序的函式呼叫棧，這兩類日誌是我們解決ANR問題的利器。
- 監測ANR的核心原理是訊息排程和超時處理。
- 只有被ANR監測的場景才會有ANR報告以及ANR提示框。
參考資料
- ANR機制以及問題分析
- 理解Android ANR的觸發原理
- 深入理解Android卷三（Android輸入系統）
- Android開發藝術探索
- Android原始碼
最後，感謝本文內容所