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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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