「崩潰」與「卡頓」、「異常退出」等一樣，是影響App穩(wěn)定性常見的三種情況。相關(guān)數(shù)據(jù)顯示，當(dāng)iOS的崩潰率超過0.8%，Android的崩潰率超過0.4%的時候，活躍用戶有明顯下降態(tài)勢。它不僅會造成關(guān)鍵業(yè)務(wù)中斷、用戶留存率下降、品牌口碑變差等負(fù)面影響，而且會直接帶來卸載和流失。也同時給開發(fā)者帶來不可小覷的資本損失。

那么，崩潰率低的App質(zhì)量就高么?是否可以通過崩潰率直接判斷App的穩(wěn)定性?

首先，衡量一個App質(zhì)量好壞時我們需要定義一個統(tǒng)一的口徑，即哪些指標(biāo)可以作為穩(wěn)定性的評估口徑?以友盟+的U-APM定義的穩(wěn)定率這個概念為例，評價一個App的穩(wěn)定性和質(zhì)量，一般從以下三點(diǎn)綜合考慮：

• 發(fā)生了崩潰，如java崩潰和Native崩潰，即用崩潰率這個指標(biāo)來評估計算;
• 異常退出，如：low memory killer、任務(wù)列表中劃掉、系統(tǒng)異常、斷電、用戶觸發(fā)關(guān)機(jī)/重啟等，即用異常率這個指標(biāo)來評估計算。
• 崩潰，也就是程序出現(xiàn)異常，導(dǎo)致程序退出。包括：
• Java崩潰，也就是在Java代碼中出現(xiàn)了未捕獲異常，導(dǎo)致程序異常退出。如：空指針異常、數(shù)組越界異常等。
• Native異常，也就是在Native代碼中，出現(xiàn)錯誤產(chǎn)生相應(yīng)的signal信號，導(dǎo)致程序異常退出。如：訪問非法地址、地址對其 問題等。

Java崩潰的捕獲相對會簡單一些，Native崩潰的捕獲可能要求我們對系統(tǒng)底層知識要有一定的掌握。我們知道Android是基于Linux系統(tǒng)的，系統(tǒng)中的崩潰大多是由于編碼錯誤或硬件錯誤導(dǎo)致的。當(dāng)系統(tǒng)遇到不可恢復(fù)的錯誤時會通過異常中斷的方式觸發(fā)異常處理流程，這些中斷的處理被統(tǒng)一為了信號量。當(dāng)應(yīng)用程序接收到某個信號量時會按照內(nèi)核默認(rèn)的動作處理，如Term、lgn、Core、Stop、Cont。同時我們也可以通過sigaction注冊接收信號來指定處理動作，比如捕獲崩潰信息等。當(dāng)然捕獲過程中也會有一些困難點(diǎn)，尤其在極端環(huán)境中，比如棧溢出時，由于?？臻g已經(jīng)被用完，造成我們的信號處理函數(shù)沒法被調(diào)用，以至于無法捕獲到崩潰信息，這時我們需要考慮使用signalstack，使我們的信號處理函數(shù)可以在堆里面分配到一塊內(nèi)存空間作為“可替換信號棧”來處理崩潰信息。

當(dāng)然，除了穩(wěn)定、安全的捕獲能力外，還需要豐富崩潰現(xiàn)場的上下文信息，比如Logcat信息、調(diào)用棧信息、設(shè)備信息、環(huán)境信息等等，為我們后續(xù)定位和解決問題提供全面的參考。

對于發(fā)生崩潰的情況，我們使用崩潰率作為數(shù)據(jù)指標(biāo)。包括：

• UV崩潰率，也就是發(fā)生崩潰錯誤的去重用戶/去重活躍總用戶;
• PV崩潰率，也就是發(fā)生崩潰錯誤的次數(shù)/啟動次數(shù);

啟動崩潰率，也就是應(yīng)用啟動過程中發(fā)生的崩潰，很容易被忽略但又非常重要的崩潰指標(biāo)，因?yàn)閱邮茿PP生命周期中非常重要的一個階段，很多廣告、閃屏、活動等內(nèi)容都在這個過程中透出，同時啟動時又需要加載各種初始化，并且如果啟動出現(xiàn)錯誤，往往熱修復(fù)、降級融災(zāi)策略都無法彌補(bǔ)。

ANR，也就是Application Not Responding，當(dāng)應(yīng)用程序一段時間無法及時響應(yīng)，則會彈出ANR對話框，讓用戶選擇繼續(xù)等待，還是強(qiáng)制關(guān)閉。從用戶體驗(yàn)的角度看，有時候ANR可能要比崩潰會帶來更糟糕的體驗(yàn)，所以開發(fā)者重視崩潰的同時也要非常重視ANR。

ANR捕獲的準(zhǔn)確性一直是不斷升級打怪、不斷完善的過程。早期我們通過FileObserver 監(jiān)聽/data/anr/traces.txt文件的變化進(jìn)行捕獲和上報，但很遺憾隨著版本升級，系統(tǒng)和廠商開始收緊系統(tǒng)文件的權(quán)限，此方案的覆蓋設(shè)備情況越來越低，造成ANR捕獲的準(zhǔn)確性也一直降低。

隨后我們改進(jìn)為監(jiān)控消息隊(duì)列的運(yùn)行時間的方式捕獲ANR，也就是向主線程Looper中放入一個空消息，監(jiān)聽該空消息在5秒后是否被執(zhí)行，但該方案無法真實(shí)的捕獲ANR情況(存在漏報和誤報情況)，并且也無法得到完整的ANR內(nèi)容。后續(xù)我們參考Android ANR的實(shí)現(xiàn)原理，實(shí)現(xiàn)了一套實(shí)時、準(zhǔn)確的ANR捕獲方案，并且可以兼容所有系統(tǒng)版本。我們知道系統(tǒng)的system_server 進(jìn)程在檢測到 APP 出現(xiàn) ANR 后，會向出現(xiàn)ANR 的進(jìn)程發(fā)送 SIGQUIT (signal 3) 信號。默認(rèn)情況，系統(tǒng)的 libart.so 會收到該信號，并調(diào)用 Java 虛擬機(jī)的 dump 方法生成 traces。

我們通過攔截SIGQUT，在出現(xiàn)ANR時優(yōu)先接收到信號，并生成traces和ANR日志，在處理完信號后，將信號繼續(xù)傳遞給系統(tǒng)讓系統(tǒng)生成traces文件，生成traces文件時，在保證內(nèi)容與系統(tǒng)原生的一致性的同時還對生成traces文件的速度進(jìn)行了明顯的提升，有效地避免了可能因生成 traces 時間過長，而被 system_server 使用 SIGKILL (signal 9) 再次強(qiáng)殺，同時我們對捕獲到的內(nèi)容進(jìn)行了豐富，包括：觸發(fā) ANR 的原因、手機(jī)中 TOP 進(jìn)程CPU 使用率、ANR 進(jìn)程中 TOP 線程 CPU 使用率、CPU 各核心處理時間分布情況、磁盤 IO 操作等待時長等重要信息，對分析、定位和解決 ANR 問題，提供了更加強(qiáng)有力的支撐!

同樣對于發(fā)生ANR的情況，我們也分為UV ANR率和PV ANR率，算法可參考如上崩潰率的計算。

當(dāng)然，除了崩潰和ANR，我們往往忽略了異常退出這種場景，但往往通過異常退出我們可以發(fā)現(xiàn)如low memory killer、系統(tǒng)重啟等無法正常捕獲到的問題。比如兼容性問題導(dǎo)致的閃退、設(shè)備重啟、三方庫主動調(diào)用exit函數(shù)，導(dǎo)致應(yīng)用閃退次數(shù)增加等難以發(fā)現(xiàn)的問題，所以通過異常退出率我們可以比較全面的了解和衡量應(yīng)用的穩(wěn)定性。

綜上，對于文章開始的那個問題，我想大家都應(yīng)該有答案了吧。當(dāng)然，我們不應(yīng)該為了掩蓋代碼質(zhì)量問題，通過手動try catch去規(guī)避某些問題，這樣有可能會打斷用戶的正常使用，并造成感知性的阻斷反饋，應(yīng)該從用戶使用APP時的真實(shí)感知出發(fā)，當(dāng)出現(xiàn)問題時及時捕獲和處理問題。

App的穩(wěn)定性是一個長期不斷迭代的過程，在這個過程中U-APM是一個很好的提升效率降低成本的工具，他提供了收集、解析、聚合、分析的能力，下一期我們會從如何通過U-APM解決和處理崩潰、ANR等問題進(jìn)行講解，敬請期待。