簡介：?崩潰堆棧是我們?nèi)粘?yīng)用問題排查中的重要輔助手段，在移動開發(fā)上也不例外，為了支持用戶在堆棧上的快速定位，我們面臨一個看似比較簡單問題：高亮崩潰中的關(guān)鍵行, 輔助用戶快速定位問題。

?

阿里云 云原生應(yīng)用研發(fā)平臺EMAS 張?jiān)?#xff08;此間）

一、前言

崩潰堆棧是我們?nèi)粘?yīng)用問題排查中的重要輔助手段，在移動開發(fā)上也不例外，為了支持用戶在堆棧上的快速定位，我們面臨一個看似比較簡單問題：高亮崩潰中的關(guān)鍵行, 輔助用戶快速定位問題。
崩潰堆棧關(guān)鍵行: 堆棧中是屬于用戶開發(fā)代碼中那行直接引起崩潰的代碼。
舉個例子：

二、 業(yè)界方案

業(yè)界的競品基本上是通過 Package Name判斷的，在沒有 Package Name 的情況下，有的競品會定位到第一行，有的則會定位到非系統(tǒng)庫的第一行。
例如: 友商這種情況下就將關(guān)鍵行掛在了第一行 fastjson 的位置。

這里容易出現(xiàn)兩個問題：
1.Package Name 大多數(shù)時候和真正的崩潰包名關(guān)系不大。
2.App 組件化，包名不能覆蓋一方庫，二方庫。
為了更好的解決這個問題，我們提出了下面用詞頻比/詞頻分的方式來解決問題的新方案。

三、新方案

所以在 Package Name 的基礎(chǔ)上，我們還需要一個輔助手段，讓我們能夠識別這兩種情況，從而在關(guān)鍵行定位更精準(zhǔn)。

這里我們想到的一個做法就是利用全量的 Crash 崩潰堆棧，計(jì)算詞頻比和相應(yīng)的詞頻分，通過概率去優(yōu)化我們的關(guān)鍵行判斷。

實(shí)現(xiàn)上分為兩個平臺。

3.1 對于 iOS

1）主包判斷

這個問題，對于 iOS，其實(shí)不用考慮用戶填寫的 Bundle ID, 因?yàn)?IOS Crash 天然就自帶 Binary Images，我們將用戶主包信息預(yù)存下來，用于后續(xù)判斷就行了。
Binary Images

2）直接定位:

對于組件化的包，我們可以通過 Binary Images 里面的信息統(tǒng)計(jì)一下每個包名出現(xiàn)的頻率，具體的頻率分布統(tǒng)計(jì)大致如下圖所示，縱坐標(biāo)代表包名出現(xiàn)的次數(shù)：

-> 注：橫坐標(biāo)為包名（這里放不下），縱坐標(biāo)為包名出現(xiàn)次數(shù)

出現(xiàn)的頻率越低，那么我們越認(rèn)為他是一方庫或者二方庫。

3.2 對于 Android

對于 Android，情況稍微復(fù)雜一點(diǎn)，首先 Android 的 Crash 中其實(shí)是不能明確標(biāo)識包名的，而且 Android 的 Package Name 并不是一個詞，而是一長串的以點(diǎn)分隔的包名, 例如

"com.aliyun.emasha.cache"。

如果單純的還以包名的詞頻比來做匹配的話，那么就會出現(xiàn)下面的問題
a.歷史數(shù)據(jù) 只出現(xiàn) com.aliyun.emasha.cache 的包名， 下次出現(xiàn)個 com.aliyun.emasha.login 的就匹配不上了。
b.同樣是 com.aliyun.emasha 的前綴，匹配到了 com.aliyun.emasha 和匹配到了 com.aliyun.emasha.cache 包名的詞頻相差很大，不符合常理。

所以還要解決這兩個問題
a.能夠盡可能的覆蓋未出現(xiàn)的崩潰情況。
b.隨著匹配的前綴越長，需要考慮前面的包名匹配帶來的影響。

所以這里要引入包名分級和詞頻分的概念
a.包名分級：將包名 split(".") 得到數(shù)組，從前往后為 1級，2級，3級這樣的分級。
b.包名詞頻分：根據(jù)包的詞頻比多級累加算出來的一個評價包名是否是三方庫的分?jǐn)?shù)，分?jǐn)?shù)越高，是三方庫的幾率越大。

但這還不夠，如果我們的詞頻比只是單純的累加，那么 com 開頭的的包名，詞頻分一定會很高，大于所有的 org 開頭的包名，但根據(jù)我們的經(jīng)驗(yàn)，其實(shí)不是這樣的，我們認(rèn)為不同級別的匹配，權(quán)重應(yīng)該是不一樣的，所以我就拍腦袋想了個權(quán)重。

0 5 2 1 1 1

這里舉個例子

com.alibaba.aliyun.emas.ha.tlog 這個包名
com 1
com.alibaba 0.3
com.alibaba.aliyun 0.1
com.alibaba.aliyun.emas 0.05
com.alibaba.aliyun.emas.ha 0.02
com.alibaba.aliyun.emas.ha.tlog 0.01

如果匹配到 com 那么詞頻分為 1 * 0
如果匹配到 com.alibaba 那么詞頻分為 1 0 + 0.3 5 = 1.5
如果匹配到 com.alibaba.aliyun 那么詞頻分為 1 0 + 0.3 5 + 0.1 * 2 = 1.7
以此類推

但是在我們的經(jīng)驗(yàn)中匹配到了 com.alibaba 和匹配到了 com.alibaba.aliyun，后者更有可能是關(guān)鍵行，所以它的詞頻分按理來說也就更低。所以我們這里做一個符合常理的修正，對于位數(shù)過短的匹配，需要后幾位的權(quán)重做補(bǔ)齊。

最終結(jié)果如下：
如果匹配到 com 那么詞頻分為 1 0 + 1 5 + 1 2 + 1 1 + 1 1 + 1 1 = 10
如果匹配到 com.alibaba 那么詞頻分為 1 0 + 0.3 5 + 0.3 2 + 0.3 1 + 0.3 1 + 0.3 1 = 3
如果匹配到 com.alibaba.aliyun 那么詞頻分為 1 0 + 0.3 5 + 0.1 2 + 0.1 1 + 0.1 1 + 0.1 1 = 2

看上去是比較符合我們的經(jīng)驗(yàn)的。

所以這里詞頻分的最終定義：根據(jù)包的詞頻多級累加算出來的一個評價包名是否是三方庫的分?jǐn)?shù)，分?jǐn)?shù)越高，是三方庫的幾率越大。如果一個包名分級過短，需要把缺失的后面分級的也算上累加，用于增大短包名的詞頻分。

我們對所有的包做一個詞頻分統(tǒng)計(jì)，可以得到如下分布圖

-> 注：橫坐標(biāo)為包名（這里放不下），縱坐標(biāo)為包名的詞頻分

根據(jù)觀察和測試，這里把閾值定在 0.2 左右比較能區(qū)分用戶的包名和三方、系統(tǒng)庫。

3.3 整體架構(gòu)

在工程實(shí)現(xiàn)上我們也做了一些優(yōu)化
1.以前業(yè)務(wù)數(shù)據(jù)是存儲在 OSS 中的，但是 EMR-OSS 目前文件處理較慢，這里換成了更適合并行處理的 HBase。
2.只計(jì)算增量 Crash 日志, 對于存量的數(shù)據(jù)，以 HyperLogLog 的形式存儲，增量計(jì)算后與存量做 Merge。

四、效果評估

常規(guī)的利用 Package Name 做判定: F1 Score

使用詞頻分思路的：F1 Score

五、真實(shí)效果評估

上面的效果評估只考慮到了每一個包名的情況，在生產(chǎn)因素下，考慮到崩潰行出現(xiàn)的位置，包名出現(xiàn)的頻率，以及沒關(guān)鍵行的情況，準(zhǔn)確率可能會有所不同，所以我們在真實(shí)環(huán)境做了高亮測試，測試方式為：對線上50個 App，每個 App 取前3條崩潰來做統(tǒng)計(jì)，總的準(zhǔn)確率如下，可以說是比較高的。

安卓準(zhǔn)確率：(333-9)/(333)*100%=90.91%
iOS準(zhǔn)確率：(173-0)/(173)*100%=100%
總體準(zhǔn)確率：(503-9)/(503)*100%=94%

六、思考

小需求可以做出大深度, 后續(xù)我們可以考慮更多跨用戶數(shù)據(jù)的脫敏拉通，理解數(shù)據(jù)，為客戶帶來更多的數(shù)據(jù)價值。

七、接下來的方向

1.組內(nèi)算法的朋友說可以通過打標(biāo) + CNN 的方式來做深度學(xué)習(xí)下的三方包名判斷, 這個后續(xù)可以試一試。
2.對于憑經(jīng)驗(yàn)拍腦袋相出來的參數(shù)和方程（詞頻分計(jì)算），其實(shí)都可以通過打標(biāo)訓(xùn)練的方式做參數(shù)和方程的固定，這也是一個優(yōu)化方向。

八、寫在最后

移動研發(fā)平臺 EMAS

阿里巴巴應(yīng)用研發(fā)平臺 EMAS 是國內(nèi)領(lǐng)先的云原生應(yīng)用研發(fā)平臺（移動App、H5應(yīng)用、小程序、Web應(yīng)用等），基于廣泛的云原生技術(shù)（Backend as a Service、Serverless、DevOps、低代碼等），致力于為企業(yè)、開發(fā)者提供一站式的應(yīng)用研發(fā)管理服務(wù)，涵蓋開發(fā)、測試、運(yùn)維、運(yùn)營等應(yīng)用全生命周期。

?

?

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

總結(jié)

以上是生活随笔為你收集整理的移动端堆栈关键行定位的新思路的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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