簡介：?選擇一款有超強(qiáng)捕獲能力的專業(yè)產(chǎn)品，對于開發(fā)者定位和修復(fù)穩(wěn)定性問題至關(guān)重要。友盟+U-APM SDK集成了UC 內(nèi)核團(tuán)隊(duì)強(qiáng)大的技術(shù)及友盟+超強(qiáng)的錯誤捕獲能力，通過數(shù)萬次捕獲實(shí)踐中積累了豐富經(jīng)驗(yàn)，在產(chǎn)品、性能和研發(fā)能力上都極大保障了開發(fā)者定位和修復(fù)穩(wěn)定性問題的超強(qiáng)效率。

1. ANR 產(chǎn)生原理

關(guān)于 ANR 的觸發(fā)原因，Android 官方開發(fā)者文檔中 “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......

即，常見的有如下兩種情況會產(chǎn)生 ANR：

輸入事件（例如按鍵或屏幕輕觸事件等）在 5 秒內(nèi)沒有響應(yīng)；

BroadcastReceiver 在 10 秒內(nèi)沒有執(zhí)行完成。

結(jié)合 Android 相關(guān)源碼分析可知，輸入事件的 ANR 檢測是基于輸入事件本身驅(qū)動的，系統(tǒng)要求在 App進(jìn)程中處理完成每個輸入事件后，通知系統(tǒng)進(jìn)程事件處理完畢，以此判斷 App是否無響應(yīng)。

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

第一個輸入事件產(chǎn)生，系統(tǒng)將其發(fā)送給用戶當(dāng)前操作的 App；

系統(tǒng)收到第二個事件，發(fā)現(xiàn)當(dāng)前距第一個輸入事件發(fā)送時間超過 0.5s 仍未處理完畢，則設(shè)置一個定時器，5s 后觸發(fā)；

5s 之后，若系統(tǒng)發(fā)現(xiàn)第一個輸入事件仍然沒有回應(yīng)時，則觸發(fā) ANR，激活 App 中的 Signal Cather 線程生成 traces.txt，然后彈出 ANR 對話框，告知用戶 App 無響應(yīng)。

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

2. ANR 日志生成原理

系統(tǒng)的 system_server 進(jìn)程在檢測到 App 出現(xiàn) ANR 后，會向出現(xiàn) ANR 的進(jìn)程發(fā)送 SIGQUIT (signal 3) 信號。正常情況下，系統(tǒng)的 libart.so 會收到該信號，并調(diào)用 Java 虛擬機(jī)的 dump 方法生成 traces。

以友盟+的 U-APM 應(yīng)用性能監(jiān)控平臺為例，集成SDK 后，SDK 會攔截 SIGQUIT。在出現(xiàn) ANR 時，libcrashsdk.so 會優(yōu)先收到信號，并生成 traces 和 ANR 日志。在 SDK 處理完信號后，會將信號繼續(xù)傳遞給系統(tǒng)的 libart.so，讓系統(tǒng)生成 ANR traces.txt。

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

U-APM SDK ANR 捕獲原理

其中，SDK 生成 traces 時，使用的是 libart.so 中的 dump 方法，生成的內(nèi)容與系統(tǒng)原生的基本一致。并且，U-APM SDK 在調(diào)用 dump 方法時進(jìn)行了優(yōu)化，dump 速度較系統(tǒng)生成原生 traces 的速度顯著提升，有效地避免了可能因生成 traces 時間過長，而被 system_server 使用 SIGKILL (signal 9) 再次強(qiáng)殺。

在獲取所有線程的 traces 信息后，生成完整的 ANR 日志，還會提供獲取觸發(fā) ANR 的原因、手機(jī)中 TOP 進(jìn)程 CPU 使用率、ANR 進(jìn)程中 TOP 線程 CPU 使用率、CPU 各核心處理時間分布情況、磁盤 IO 操作等待時長等重要信息。

目前，SDK 生成的 ANR 日志信息，基本包含系統(tǒng)生成的 ANR 日志的所有內(nèi)容，甚至還包含一些系統(tǒng)日志中沒有的內(nèi)容，以及 App增加的自身的業(yè)務(wù)相關(guān)信息，對分析、定位和解決 ANR 問題，提供了更加強(qiáng)有力的支撐。

3、日志分析

如開發(fā)者接入了SDK，ANR 日志將自動啟用，出現(xiàn) ANR 時，會先于系統(tǒng)生成 ANR 日志。日志的主要內(nèi)容介紹如下：

1）. ANR 日志結(jié)構(gòu)

使用日志分析插件，我們可以清晰地看到 生成的 ANR 日志包含的內(nèi)容以及重點(diǎn)信息，如下：

ANR 日志結(jié)構(gòu)

除了生成的日志以 Section 分為多個部分，其中，包含重要信息的 Section 會使用紅色標(biāo)出，特別重要的信息還會加粗。另外，每個 Section 有快捷鍵可直接跳轉(zhuǎn)到相應(yīng)位置。

2）. ANR 概要

概要信息如下：

ANR 概要信息

這部分內(nèi)容主要從系統(tǒng)獲取，其包含了 ANR 的進(jìn)程名、ANR 產(chǎn)生的時間、ANR 的原因、ANR 前后幾秒內(nèi)系統(tǒng) TOP 進(jìn)程的 CPU 使用率等。其中，通過 ANR 原因可以得知是輸入事件處理超時，還是 BroadcastReceiver 等其它消息處理時間過長；通過 CPU 使用率則可以得知是哪個進(jìn)程占用 CPU 資源過多。

3）. 系統(tǒng)資源使用情況

可記錄在出現(xiàn) ANR 前一段時間內(nèi)，CPU 平均使用率、CPU 各核心使用率及其耗時分布，ANR 進(jìn)程中 TOP 線程的執(zhí)行耗時及比例、出現(xiàn)頁錯誤的次數(shù)，磁盤 IO 操作等待時長及次數(shù)等內(nèi)容。如下：

系統(tǒng)資源使用情況

當(dāng) IO 繁忙導(dǎo)致 ANR 時，io wait time 和 CPU 時間分布中的 iowait 比例會比較突出；通過 CPU 時間分布中的 user 和 system 占比，則可以知道是用戶態(tài)代碼執(zhí)行耗時過長，還是 Linux 內(nèi)核的系統(tǒng)調(diào)用耗時太久。

4）. ANR traces

traces 信息是 ANR 日志中最關(guān)鍵的內(nèi)容。如U-APM生成的 traces 信息包含了出現(xiàn) ANR 時主線程的 native 調(diào)用棧和所有線程的 java 調(diào)用棧。通常死鎖問題通過調(diào)用棧中的信息可以很容易發(fā)現(xiàn)。

ANR traces

U-APM SDK 的 traces 由 fork 的子進(jìn)程生成，不會因 Java 虛擬機(jī)出現(xiàn) BUG 導(dǎo)致生成 traces 時又出現(xiàn) native 崩潰，也不會因 dump 時卡死阻塞整個 ANR 日志的生成。

5）. Logcat

以U-APM為例，會在 ANR 時抓取 Android logcat。APM SDK 能繞開部分 ROM 增加的權(quán)限控制，拿到當(dāng)前 App ANR 前相關(guān)的 log 信息。當(dāng)前進(jìn)程以及當(dāng)前錯誤線程輸出的 log 會被重點(diǎn)標(biāo)出，error 和 warning 也會以顯目的顏色標(biāo)出。

logcat

6）. 內(nèi)存等其它信息

通過ANR日志可以分析出一系列的內(nèi)存信息，如：

系統(tǒng)的 RAM 總內(nèi)存、剩余可用內(nèi)存；

當(dāng)前進(jìn)程占用的虛擬內(nèi)存、物理內(nèi)存；

Java 占用的總內(nèi)存和可用內(nèi)存；

Native 占用的內(nèi)存和可用內(nèi)存等。

另外，ANR 日志同 Java 和 Native 崩潰日志一樣，支持業(yè)務(wù)自定義日志內(nèi)容擴(kuò)展，如：

崩潰前增加簡短的自定義頭信息；

崩潰前注冊外部文件，崩潰時其內(nèi)容將被帶入日志；

崩潰前緩存業(yè)務(wù)相關(guān)的最近若干條操作或信息；

崩潰時通過回調(diào)返回業(yè)務(wù)最新內(nèi)容等。

4、ANR監(jiān)控工具

選擇一款有超強(qiáng)捕獲能力的專業(yè)產(chǎn)品，對于開發(fā)者定位和修復(fù)穩(wěn)定性問題至關(guān)重要。友盟+U-APM SDK集成了UC 內(nèi)核團(tuán)隊(duì)強(qiáng)大的技術(shù)及友盟+超強(qiáng)的錯誤捕獲能力，通過數(shù)萬次捕獲實(shí)踐中積累了豐富經(jīng)驗(yàn)，在產(chǎn)品、性能和研發(fā)能力上都極大保障了開發(fā)者定位和修復(fù)穩(wěn)定性問題的超強(qiáng)效率。

作者：友盟全域數(shù)據(jù)

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載

?

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的一文教你轻松搞定ANR异常捕获与分析方法的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。