總之，抓棧隨機性決定了我們無法定位真實原因，也就無法確定新增問題的有效性，這就使得很多新增問題被帶入線上，我們也在這種低效的惡性循環(huán)中不斷重復。

我們的訴求

經(jīng)過以上的分析和調(diào)研，我們的痛點可以歸結(jié)為以下三類：

現(xiàn)有的問題現(xiàn)場堆棧對于由于抓棧的不準確，無論對單點問題排查還是多段耗時問題排查都意義不大，無法正確的還原現(xiàn)場信息，這使得我們的問題排查優(yōu)化進展緩慢，甚至偏離正常的方向。現(xiàn)有的卡頓及調(diào)度時序圖等工具都是以 Message 為統(tǒng)計粒度，無法提供真正可優(yōu)化的耗時定位，而現(xiàn)有的以 Method 為統(tǒng)計粒度的工具由于性能和穩(wěn)定性問題都只能運行在線下。為此，我們希望有一套能夠高效運行在線上的 Method trace 工具，用于卡頓及 ANR 的檢測，以 Method 耗時為統(tǒng)計粒度，獲取卡頓/ANR 時用戶當前和之前一段時間內(nèi)的 Method 執(zhí)行耗時情況，這樣我們可以完整的呈現(xiàn)問題發(fā)生時刻以及之前一段時間的 Method 執(zhí)行耗時情況，高效清晰的定位問題癥結(jié)所在。

針對增量問題的防治，由于現(xiàn)有的能力無法識別問題是否新增，導致在錯誤的方向上耗費太多精力，而真正的問題無法被發(fā)現(xiàn)從而帶入線上，為此我們需要搭建增量問題的防治體系，去體系化前置化的完成增量問題的監(jiān)控、有效信息的提供、問題的分發(fā)，前置化預防才能避免問題被帶入線上，體系化才能更高效更全面的最大限度發(fā)現(xiàn)問題，同時將增量問題的防治體系建設和問題監(jiān)控解決能力建設結(jié)合起來，建立一個自動化、前置化、發(fā)現(xiàn)問題全面、易消費、分發(fā)及時的的全鏈路體系。

監(jiān)控體系建設

在目前的監(jiān)控體系下，堆棧抓取不準確，堆棧聚合存在問題，大量聚合在了無意義的堆棧上，現(xiàn)有的工具體系下，分析成本極高，大多數(shù)問題無法得到有效消費，卡頓和 ANR 指標長期高位，這就要求我們盡快找到破解之法。

誠然，最終導致彈出 ANR 彈窗的誘因很多，但是歸根結(jié)底，根本原因都是執(zhí)行超時，而我們最需要關注的也是那些耗時較高的 Method，當 Method 耗時減少后，相應的觸發(fā) ANR 的幾率也會隨之減少，為此我們就需要找出那些真正耗時卡頓的地方并對其進行優(yōu)化。

針對以上的痛點和訴求，我們重新梳理了思路，對比了現(xiàn)有方案的優(yōu)缺點后，取長補短，開發(fā)了基于 Method 的高性能線上 trace 工具。在此基礎上，我們針對 ANR、卡頓進行了方案升級和全方位的體系建設。

基于 Sliver 的 ANR 治理方案介紹

針對 ANR，我們希望獲取到發(fā)生 ANR 時前一段時間的堆棧記錄，以快速的找出發(fā)生耗時的 Method 調(diào)用堆棧。

Sliver 采用采樣的方式來定時獲取堆棧，我們在 APP 啟動時打開 Sliver 的監(jiān)控能力，根據(jù)不同機型傳入不同的采樣值，通常在低端機采樣值會大一些，在高端機采樣值會小一些，這樣最大限度降低獲取 trace 本身對性能的影響，Sliver 定時抓取堆棧，并對獲取到的堆棧做 diff 聚合、緩存以區(qū)分不同堆棧的關系。同時，通過 NPTH 的接口注冊 ANR 的回調(diào)，當發(fā)生 ANR 時，回調(diào)函數(shù)中將緩存的堆棧 dump 到文件，同時將文件隨 ANR 其他信息上報到 Sladar，這樣我們就可以在對 case 的分析中使用精確的 trace 信息問題定位，下圖說明了針對 ANR 的整體工作流程。

我們將這一套流程運行起來，收集了相關 case，在同一個 case 拿到相關信息對比。

以上三個圖是同一個 case 中的不同信息，分別是堆棧、調(diào)度時序圖、trace，通過 trace 能清晰看出問題的原因所在。

目前該方案已在線下、灰度、眾測渠道常態(tài)開啟，作用明顯，如下：

整體上，該方案的上線，使得我們能夠更清晰準確的定位問題原因，加快問題的流轉(zhuǎn)解決，促進各類隱藏較深問題的快速解決。

卡頓問題的防治方案

不同于 ANR 問題，卡頓問題的標準是我們自己定義的，卡頓以及多次卡頓的疊加是導致 ANR 以及影響性能的大項，現(xiàn)有的卡頓監(jiān)控只能拿到單一的堆棧鏈路，無法完整還原當前卡頓產(chǎn)生現(xiàn)場全貌，基于此我們設計了基于 Sliver trace 的卡頓監(jiān)控體系。

先看整體流程圖：

主要包含兩個方面：

在監(jiān)控卡頓時，首先需要打開 Sliver 的 trace 記錄能力，Sliver 采樣記錄 trace 執(zhí)行信息，對抓取到的堆棧進行 diff 聚合和緩存。

同時基于我們的需要設置相應的卡頓閾值，以 Message 的執(zhí)行耗時為衡量。對主線程消息調(diào)度流程進行攔截，在消息開始分發(fā)執(zhí)行時埋點，在消息執(zhí)行結(jié)束時計算消息執(zhí)行耗時，當消息執(zhí)行耗時超過閾值，則認為產(chǎn)生了一次卡頓。

當卡頓發(fā)生時，我們需要為此次卡頓準備數(shù)據(jù)，這部分工作是在端上子線程中完成的，主要是 dump trace 到文件以及過濾聚合要上報的堆棧。分為以下幾步：

之后，將 trace 文件和堆棧一同上報，這樣的特征堆棧提取策略保證了堆棧聚合的可靠性和準確性，保證了上報到平臺后堆棧的正確合理聚合，同時提供了進一步分析問題的 trace 文件。

上線后，我們通過和原卡頓體系進行效果對比：

以上三圖分別是，針對高斯模糊問題的原卡頓列表、現(xiàn)在卡頓列表、trace 。在原先的卡頓上報列表中，問題分散到了不同的堆棧中，這是由于發(fā)生卡頓時抓棧隨機，而現(xiàn)在的卡頓列表聚合到了單一的堆棧鏈路中，這是由于我們?nèi)∶恳粚佣褩Ｖ泻臅r最長的函數(shù)組合成特征堆棧，通過trace也可以驗證特征堆棧的有效性，能夠更準確的定位問題原因。同時，trace 詳細的展示了函數(shù)調(diào)用鏈路，提供了深入分析問題的能力。

經(jīng)過 trace 和堆棧驗證，該方式輸出的卡頓信息，堆棧聚合更加契合真正的卡頓點，當然一個 Message 中可能有多個大大小小的耗時函數(shù)存在，trace 文件的存在能夠更全面的還原現(xiàn)場情況，二者的結(jié)合才能更好的解決問題。

目前卡頓檢測體系已經(jīng)在眾測及線下自動化常態(tài)運行，產(chǎn)出數(shù)據(jù)來看均為線上存在問題。

前置發(fā)現(xiàn)能力建設

基于 Sliver 能力的卡頓和 ANR 檢測方案，能夠極大提高解決問題的效率，接下來我們需要考慮如何將這兩種能力常態(tài)的運行起來，服務于我們的日常存量問題、增量問題的防和治，尤其是將問題的暴露階段提前，減少對用戶的影響尤為重要。為此，我們進行了以下幾個方向的建設。

目前，測試平臺提供了一些自動化測試 job，這些 job 大多以遍歷方式自動的測試 APP 的功能，對所有功能優(yōu)先級一樣的觸達，我們將我們的 ANR 檢測能力和卡頓檢測能力進行集成打包，觸發(fā)自動化 job，產(chǎn)出相關的卡頓和 ANR case。

分析對比這些 case 后發(fā)現(xiàn)，線下上報的 TOP 問題和線上問題差異較大，不符合用戶真實的使用場景。線下檢測出的一些量級較大的 case 在線上場景出現(xiàn)的量級很小，影響的用戶很少，而線上一些影響用戶較多的 case，線下檢測卻上報很少。分析這是由于遍歷式的測試方案不符合真實的用戶行為，這會使我們在推動解決問題中優(yōu)先級錯誤，無法及時正確辨別那些真正量級高、影響用戶多、優(yōu)先級高的問題，影響整體的優(yōu)化節(jié)奏。

為此，我們接入了更智能的基于用戶行為的測試策略，產(chǎn)出了更符合用戶真實行為的智能測試 job，基于此 job 進行卡頓和 ANR 數(shù)據(jù)收集，采樣分析相關數(shù)據(jù)符合線上數(shù)據(jù)分布，在量級和影響用戶量級分布上更接近真實的用戶場景，得到正確的問題優(yōu)先級。

同時利用測試平臺接口，我們構(gòu)建了完全自動化的測試機制：基于最新 release 分支定時觸發(fā)打包平臺打包 -> 配置渠道為性能測試專用渠道 -> 成功后執(zhí)行自動化測試生成數(shù)據(jù)。

線下的自動化測試畢竟受機型、場景等條件限制，不易發(fā)現(xiàn)一些用戶個性化問題。為此，在線上進行問題檢測顯得尤為重要。beta_version 和灰度渠道都是真實的用戶渠道，能夠覆蓋各種場景，但二者又有所不同，beta_version 用戶較少但活躍度更高。為此我們在 beta_version 渠道集成了卡頓和 ANR 數(shù)據(jù)的收集方案。同時，灰度渠道由于用戶數(shù)多，可以提供更全面的場景和用戶，我們也在灰度渠道集成了 ANR 方案，不過由于卡頓發(fā)生的頻率相對較高，考慮到灰度用戶多的特點，我們暫未開啟灰度渠道的卡頓采集。

很多時候需要對線上用戶遇到的問題進行動態(tài)調(diào)查，相關調(diào)查能力雖然完備，但出于包大小的考慮很多時候并不會帶到線上。針對此類問題，需要有一種類似于補丁但又相對輕量的方案，能夠動態(tài)的下發(fā)能力到用戶的手機上。

為了提高西瓜 Android 客戶端的動態(tài)調(diào)查能力，將所有的通用能力封裝成一個模塊，通過統(tǒng)一的接口進行調(diào)度與事件分發(fā)，結(jié)合插件化下發(fā)加載能力，實現(xiàn)精準下發(fā)調(diào)查能力到任意手機上。

在實現(xiàn)上，整體流程如下圖：

可以分為宿主、插件、組件三部分來看：

基于此框架，我們可以根據(jù)需求以動態(tài)下發(fā)插件的方式下發(fā)攜帶不同能力的插件包，同時利用 Setting 控制宿主執(zhí)行相應的操作，完成動態(tài)的定向下發(fā)特定能力到特定手機或某類渠道的能力，這有以下優(yōu)點：

目前，我們已將多種問題調(diào)查能力進行了集成，為線上問題調(diào)查和修復提供了支撐。

卡頓數(shù)據(jù)的消費鏈路建設

以上部分從線上、線下、動態(tài)能力角度結(jié)合卡頓 & ANR 方案進行了全方位的運行，產(chǎn)出了易消費可消費的數(shù)據(jù)，接下來我們需要完善消費流程，提高問題的解決效率。

針對產(chǎn)出的數(shù)據(jù)，我們通過輕服務進行數(shù)據(jù)處理，根據(jù) apm_open 開放接口，我們可以拿到 job 對應的卡頓& ANR 數(shù)據(jù)列表，遍歷列表，將每一個 case 的相關信息進行拼接，尤其是卡頓的 trace 文件鏈接，避免了文件下載鏈路較長的弊端，降低優(yōu)化成本，之后將這些信息分發(fā)到對應的跟進群中。同時，在 Sladar 上根據(jù)對應的代碼修改人或模塊 owner 指定 owner 跟進。效果如下：

同時，針對需要獲取大量 trace 文件進行分析的場景，我們也開發(fā)了本地工具，便捷批量拉取 trace 文件。

總的來說，西瓜從基礎工具的開發(fā)到在此之上卡頓 & ANR 方案的優(yōu)化到線上線下動態(tài)前置發(fā)現(xiàn)能力建設再到最終的消費鏈路，完成整個卡頓 & ANR 監(jiān)控體系的閉環(huán)，在存量問題解決、增量問題防治、單點問題跟進、整體性能治理上發(fā)揮了重要作用。

典型案例介紹

堆棧聚合錯誤案例

對 TOP 1 的 nativePollonce 問題撈取多個 trace 樣本進行分析，堆棧表現(xiàn)如下：

通過 trace 看出其實是主線程在執(zhí)行數(shù)據(jù)庫操作，快速推動解決。

通過 trace 看出其實是 ClassLoader. 執(zhí)行了 20+s，查看源碼，發(fā)現(xiàn)是 PluginClassLoader.->....dex2oat....->Runtime.exec 這樣一個調(diào)用鏈路。

基于以上的堆棧，我們知道該問題是在加載插件時，驗證 oat 文件不通過而觸發(fā)主線程 dex2oat 操作導致。因此我們提前在插件 Plugin 實例初始化時，判斷 oat 文件是否有效，無效的話中斷插件狀態(tài)機，置為不可用，同時異步重新生成 dex2oat 產(chǎn)物。

通過 trace 清晰看出是直播插件內(nèi)部的初始化耗時嚴重導致問題，而非上報的堆棧分析發(fā)現(xiàn)，觸發(fā)主要發(fā)生在插件加載成功的回調(diào)中，基于現(xiàn)在的插件框架，插件的加載主要有兩條路徑：

為此，我們從兩個方面進行了優(yōu)化：

非常規(guī)案例

有一類這樣的問題，看堆棧發(fā)生在 JSonObject clone = new JSonObject(origin.toString),在其中的浮點類型轉(zhuǎn)換時。

看到這個堆棧的第一印象是該方法并不耗時，堆棧偏移，然后拿到對應的 trace 可以看到，確實是當前方法非常耗時導致。

看 trace 的最下層，都是重復的位計算，推測是一個超級長的 double 類型數(shù)字導致的運算過長，在灰度上收集對應的 json 發(fā)現(xiàn)其中無此類數(shù)據(jù)，推測是 toString 的時候，會把存放的 double 數(shù)據(jù)轉(zhuǎn)成 string，然后 new 的時候又把 string 轉(zhuǎn)成 double，這兩次轉(zhuǎn)換可能會出現(xiàn)精度問題，造成 double 的值變成了 1.9999999999999999999999 這種很長的數(shù)，然后計算耗時很長，導致 ANR。

為此，將上述 JSonObject clone = new JSonObject(origin.toString) 邏輯修改為遍歷 origin 內(nèi)容復制拷貝，驗證后此問題消失。

一類問題看堆棧報在了 HashMap.remove 方法中。

同樣，看到該堆棧，第一反應是當前方法并不耗時，堆棧偏移導致，然而拿到對應的 trace 后，我們發(fā)現(xiàn)確實是當前方法導致的耗時。

從 trace 可以明顯看出，確實在 HashMap.remove 中卡了 40+s，結(jié)合 cpu 負載情況看，也并不是得不到調(diào)度導致。

深入分析，發(fā)現(xiàn)在多線程操作 HashMap 時，若發(fā)生擴容，可能會產(chǎn)生循環(huán)鏈表，進而觸發(fā)死循環(huán)，最終采用 ConcurrentHashMap 后解決該問題。參見：https://www.jianshu.com/p/c72af03abba5。

卡頓案例

有一類動畫問題，動畫本身是個簡單的閃光動畫，內(nèi)部沒有復雜邏輯，關于其耗時的可信程度存疑，但是借助 trace 圖可以看到：

確實動畫存在嚴重的耗時情況，清晰的展示耗時點。此時再看原先卡頓監(jiān)控和現(xiàn)在卡頓監(jiān)控的堆棧聚合效果：

上邊兩圖分別表示了原卡頓監(jiān)控和現(xiàn)在卡頓監(jiān)控的堆棧聚合效果，可以看到原卡頓監(jiān)控的堆棧聚合到了多個不同的堆棧鏈路下，這也是因為其抓棧的隨機性，這樣會使我們分散精力，也無法確定問題真實原因，而在我們現(xiàn)有的卡頓體系下，堆棧高度精確聚合到唯一的堆棧鏈路上，借助 trace 信息，也可以驗證堆棧的準確性。基于此，我們可以精確定位和分析問題。

有一種情況，如果一個 Message 中每一層調(diào)用中的函數(shù)都非常耗時，那么就會有多個聚合，此時的每一個聚合都是一個真實耗時鏈路，對應的 trace 如下：

可以看到，所有函數(shù)的耗時一目了然，這樣可以清晰明確問題之所在，找準優(yōu)化方向。

以上案例介紹，展示了我們在卡頓和 ANR 方面調(diào)查能力的提升，大大提升了我們在問題解決及防治上的能力，解決了長期以來制約我們提升性能的瓶頸，為長期的發(fā)展提升提供了支撐。

卡頓 & ANR 后續(xù)規(guī)劃

過去一段時間的監(jiān)控建設和治理工作取得了不錯的成果，但是仍然存在許多問題，主要有以下幾類：

基于這些仍然存在的問題，接下來，我們考慮做以下幾方面的工作：

總結(jié)

在上面我們整體介紹了過去一段時間西瓜 APP 的體系建設和治理工作，全方位的展示了我們的思考和各項短板的建設，并使之成功用于優(yōu)化實踐和常態(tài)問題防治，80% 以上的卡頓和 ANR 問題能夠準確還原現(xiàn)場信息，線上嚴重影響用戶體驗的問題得到了很大程度的緩解，同時有效遏制了新增問題被帶入線上，為西瓜長期常態(tài)性能問題防治提供了參考。

加入我們

歡迎加入字節(jié)跳動西瓜視頻客戶端團隊，我們專注于西瓜視頻 App 的開發(fā)和基礎技術建設，在客戶端架構(gòu)、性能、穩(wěn)定性、編譯構(gòu)建、研發(fā)工具等方向都有投入。如果你也想一起攻克技術難題，迎接更大的技術挑戰(zhàn)，歡迎加入我們！

西瓜視頻客戶端團隊正在熱招 Android、iOS 架構(gòu)師和研發(fā)工程師，最 Nice 的工作氛圍和成長機會，各種福利各種機遇，在北京、杭州、上海、廈門四地均有職位，歡迎投遞簡歷！聯(lián)系郵箱：liaojinxing@bytedance.com ；郵件標題：姓名-西瓜-工作年限-工作地點。