一文教你輕松搞定ANR例外捕獲與分析方法

1. ANR 產生原理

關于 ANR 的觸發原因，Android 官方開發者檔案中 “What Triggers ANR?” 有介紹，如下：

Generally, the system displays an ANR if an application cannot respond to user input. For example, if an application blocks on some I/O operation (frequently a network access) on the UI thread so the system can't process incoming user input events. Or perhaps the app spends too much time building an elaborate in-memory structure or computing the next move in a game on the UI thread. It's always important to make sure these computations are efficient, but even the most efficient code still takes time to run......

即，常見的有如下兩種情況會產生 ANR：

輸入事件（例如按鍵或螢屏輕觸事件等）在 5 秒內沒有回應；

BroadcastReceiver 在 10 秒內沒有執行完成，

結合 Android 相關原始碼分析可知，輸入事件的 ANR 檢測是基于輸入事件本身驅動的，系統要求在 App行程中處理完成每個輸入事件后，通知系統行程事件處理完畢，以此判斷 App是否無回應，

要產生 ANR，至少得有兩個輸入事件，場景如下：

第一個輸入事件產生，系統將其發送給用戶當前操作的 App；

系統收到第二個事件，發現當前距第一個輸入事件發送時間超過 0.5s 仍未處理完畢，則設定一個定時器，5s 后觸發；

5s 之后，若系統發現第一個輸入事件仍然沒有回應時，則觸發 ANR，激活 App 中的 Signal Cather 執行緒生成 traces.txt，然后彈出 ANR 對話框，告知用戶 App 無回應，

也就是說，要產生 ANR，第一個輸入事件必需在 5.5s 以上沒有被處理完成并反饋回系統；并且要有第二個輸入事件產生，如果沒有第二個輸入事件，即便第一個輸入事件執行了 60s 或更長時間，也是不會產生 ANR 的，

2. ANR 日志生成原理

系統的 system_server 行程在檢測到 App 出現 ANR 后，會向出現 ANR 的行程發送 SIGQUIT (signal 3) 信號，正常情況下，系統的 libart.so 會收到該信號，并呼叫 Java 虛擬機的 dump 方法生成 traces，

以友盟+的 U-APM 應用性能監控平臺為例，集成SDK 后，SDK 會攔截 SIGQUIT，在出現 ANR 時，libcrashsdk.so 會優先收到信號，并生成 traces 和 ANR 日志，在 SDK 處理完信號后，會將信號繼續傳遞給系統的 libart.so，讓系統生成 ANR traces.txt，

如下圖，紅色線為 U-APM SDK 處理 ANR 信號和生成 ANR 日志的流程，紫色線為系統生成 ANR traces.txt 的流程，

U-APM SDK ANR 捕獲原理

其中，SDK 生成 traces 時，使用的是 libart.so 中的 dump 方法，生成的內容與系統原生的基本一致，并且，U-APM SDK 在呼叫 dump 方法時進行了優化，dump 速度較系統生成原生 traces 的速度顯著提升，有效地避免了可能因生成 traces 時間過長，而被 system_server 使用 SIGKILL (signal 9) 再次強殺，

在獲取所有執行緒的 traces 資訊后，生成完整的 ANR 日志，還會提供獲取觸發 ANR 的原因、手機中 TOP 行程 CPU 使用率、ANR 行程中 TOP 執行緒 CPU 使用率、CPU 各核心處理時間分布情況、磁盤 IO 操作等待時長等重要資訊，

目前，SDK 生成的 ANR 日志資訊，基本包含系統生成的 ANR 日志的所有內容，甚至還包含一些系統日志中沒有的內容，以及 App增加的自身的業務相關資訊，對分析、定位和解決 ANR 問題，提供了更加強有力的支撐，

3、日志分析

如開發者接入了SDK，ANR 日志將自動啟用，出現 ANR 時，會先于系統生成 ANR 日志，日志的主要內容介紹如下：

1）. ANR 日志結構

使用日志分析插件，我們可以清晰地看到 生成的 ANR 日志包含的內容以及重點資訊，如下：

ANR 日志結構

除了生成的日志以 Section 分為多個部分，其中，包含重要資訊的 Section 會使用紅色標出，特別重要的資訊還會加粗，另外，每個 Section 有快捷鍵可直接跳轉到相應位置，

2）. ANR 概要

概要資訊如下：

ANR 概要資訊

這部分內容主要從系統獲取，其包含了 ANR 的行程名、ANR 產生的時間、ANR 的原因、ANR 前后幾秒內系統 TOP 行程的 CPU 使用率等，其中，通過 ANR 原因可以得知是輸入事件處理超時，還是 BroadcastReceiver 等其它訊息處理時間過長；通過 CPU 使用率則可以得知是哪個行程占用 CPU 資源過多，

3）. 系統資源使用情況

可記錄在出現 ANR 前一段時間內，CPU 平均使用率、CPU 各核心使用率及其耗時分布，ANR 行程中 TOP 執行緒的執行耗時及比例、出現頁錯誤的次數，磁盤 IO 操作等待時長及次數等內容，如下：

系統資源使用情況

當 IO 繁忙導致 ANR 時，io wait time 和 CPU 時間分布中的 iowait 比例會比較突出；通過 CPU 時間分布中的 user 和 system 占比，則可以知道是用戶態代碼執行耗時過長，還是 Linux 內核的系統呼叫耗時太久，

4）. ANR traces

traces 資訊是 ANR 日志中最關鍵的內容，如U-APM生成的 traces 資訊包含了出現 ANR 時主執行緒的 native 呼叫堆疊和所有執行緒的 java 呼叫堆疊，通常死鎖問題通過呼叫堆疊中的資訊可以很容易發現，

ANR traces

U-APM SDK 的 traces 由 fork 的子行程生成，不會因 Java 虛擬機出現 BUG 導致生成 traces 時又出現 native 崩潰，也不會因 dump 時卡死阻塞整個 ANR 日志的生成，

5）. Logcat

以U-APM為例，會在 ANR 時抓取 Android logcat，APM SDK 能繞開部分 ROM 增加的權限控制，拿到當前 App ANR 前相關的 log 資訊，當前行程以及當前錯誤執行緒輸出的 log 會被重點標出，error 和 warning 也會以顯目的顏色標出，

logcat

6）. 記憶體等其它資訊

通過ANR日志可以分析出一系列的記憶體資訊，如：

系統的 RAM 總記憶體、剩余可用記憶體；

當前行程占用的虛擬記憶體、物理記憶體；

Java 占用的總記憶體和可用記憶體；

Native 占用的記憶體和可用記憶體等，

另外，ANR 日志同 Java 和 Native 崩潰日志一樣，支持業務自定義日志內容擴展，如：

崩潰前增加簡短的自定義頭資訊；

崩潰前注冊外部檔案，崩潰時其內容將被帶入日志；

崩潰前快取業務相關的最近若干條操作或資訊；

崩潰時通過回呼回傳業務最新內容等，

4、ANR監控工具

選擇一款有超強捕獲能力的專業產品，對于開發者定位和修復穩定性問題至關重要，友盟+U-APM SDK集成了UC 內核團隊強大的技術及友盟+超強的錯誤捕獲能力，通過數萬次捕獲實踐中積累了豐富經驗，在產品、性能和研發能力上都極大保障了開發者定位和修復穩定性問題的超強效率，