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

?

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

一、前言

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

二、 業(yè)界方案

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

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

三、新方案

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

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

實(shí)現(xiàn)上分為兩個(gè)平臺(tái)。

3.1 對(duì)于 iOS

1）主包判斷

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

2）直接定位:

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

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

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

3.2 對(duì)于 Android

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

"com.aliyun.emasha.cache"。

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

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

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

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

0 5 2 1 1 1

這里舉個(gè)例子

com.alibaba.aliyun.emas.ha.tlog 這個(gè)包名
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
以此類(lèi)推

但是在我們的經(jīng)驗(yàn)中匹配到了 com.alibaba 和匹配到了 com.alibaba.aliyun，后者更有可能是關(guān)鍵行，所以它的詞頻分按理來(lái)說(shuō)也就更低。所以我們這里做一個(gè)符合常理的修正，對(duì)于位數(shù)過(guò)短的匹配，需要后幾位的權(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í)累加算出來(lái)的一個(gè)評(píng)價(jià)包名是否是三方庫(kù)的分?jǐn)?shù)，分?jǐn)?shù)越高，是三方庫(kù)的幾率越大。如果一個(gè)包名分級(jí)過(guò)短，需要把缺失的后面分級(jí)的也算上累加，用于增大短包名的詞頻分。

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

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

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

3.3 整體架構(gòu)

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

四、效果評(píng)估

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

使用詞頻分思路的：F1 Score

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

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

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

六、思考

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

七、接下來(lái)的方向

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

八、寫(xiě)在最后

移動(dòng)研發(fā)平臺(tái) EMAS

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

?

?

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

總結(jié)

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

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