共计 2952 个字符，预计需要花费 8 分钟才能阅读完成。
阿里云 云原生利用研发平台 EMAS 张月（此间）
简介：解体堆栈是咱们日常利用问题排查中的重要辅助伎俩，在挪动开发上也不例外，为了反对用户在堆栈上的疾速定位，咱们面临一个看似比较简单问题：高亮解体中的要害行, 辅助用户疾速定位问题。
一、前言
解体堆栈是咱们日常利用问题排查中的重要辅助伎俩，在挪动开发上也不例外，为了反对用户在堆栈上的疾速定位，咱们面临一个看似比较简单问题：高亮解体中的要害行, 辅助用户疾速定位问题。
解体堆栈要害行: 堆栈中是属于用户开发代码中那行间接引起解体的代码。
举个例子：
二、业界计划
业界的竞品基本上是通过 Package Name 判断的，在没有 Package Name 的状况下，有的竞品会定位到第一行，有的则会定位到非零碎库的第一行。
例如: 友商这种状况下就将要害行挂在了第一行 fastjson 的地位。
这里容易呈现两个问题：
- Package Name 大多数时候和真正的解体包名关系不大。
- App 组件化，包名不能笼罩一方库，二方库。
为了更好的解决这个问题，咱们提出了上面用词频比 / 词频分的形式来解决问题的新计划。
三、新计划
所以在 Package Name 的根底上，咱们还须要一个辅助伎俩，让咱们可能辨认这两种状况，从而在要害行定位更精准。
这里咱们想到的一个做法就是利用全量的 Crash 解体堆栈，计算词频比和相应的词频分，通过概率去优化咱们的要害行判断。
实现上分为两个平台。
对于 iOS
主包判断
这个问题，对于 iOS，其实不必思考用户填写的 Bundle ID, 因为 IOS Crash 人造就自带 Binary Images，咱们将用户主包信息预存下来，用于后续判断就行了。
Binary Images
间接定位:
对于组件化的包，咱们能够通过 Binary Images 外面的信息统计一下每个包名呈现的频率，具体的频率散布统计大抵如下图所示，纵坐标代表包名呈现的次数：
注：横坐标为包名（这里放不下），纵坐标为包名呈现次数
呈现的频率越低，那么咱们越认为他是一方库或者二方库。
对于 Android
对于 Android，状况略微简单一点，首先 Android 的 Crash 中其实是不能明确标识包名的，而且 Android 的 Package Name 并不是一个词，而是一长串的以点分隔的包名, 例如
“com.aliyun.emasha.cache”。
如果单纯的还以包名的词频比来做匹配的话，那么就会呈现上面的问题
- 历史数据 只呈现 com.aliyun.emasha.cache 的包名，下次呈现个 com.aliyun.emasha.login 的就匹配不上了。
- 同样是 com.aliyun.emasha 的前缀，匹配到了 com.aliyun.emasha 和匹配到了 com.aliyun.emasha.cache 包名的词频相差很大，不合乎常理。
所以还要解决这两个问题
- 可能尽可能的笼罩未呈现的解体状况。
- 随着匹配的前缀越长，须要思考后面的包名匹配带来的影响。
所以这里要引入包名分级和词频分的概念
- 包名分级：将包名 split(“.”) 失去数组，从前往后为 1 级，2 级，3 级这样的分级。
- 包名词频分：依据包的词频比多级累加算进去的一个评估包名是否是三方库的分数，分数越高，是三方库的几率越大。
但这还不够，如果咱们的词频比只是单纯的累加，那么 com 结尾的的包名，词频分肯定会很高，大于所有的 org 结尾的包名，但依据咱们的教训，其实不是这样的，咱们认为不同级别的匹配，权重应该是不一样的，所以我就拍脑袋想了个权重。
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
以此类推
然而在咱们的教训中匹配到了 com.alibaba 和匹配到了 com.alibaba.aliyun，后者更有可能是要害行，所以它的词频分按理来说也就更低。所以咱们这里做一个合乎常理的修改，对于位数过短的匹配，须要后几位的权重做补齐。
最终后果如下 ：
如果匹配到 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
看上去是比拟合乎咱们的教训的。
所以这里词频分的最终定义：依据包的词频多级累加算进去的一个评估包名是否是三方库的分数，分数越高，是三方库的几率越大。如果一个包名分级过短，须要把缺失的前面分级的也算上累加，用于增大短包名的词频分。
咱们对所有的包做一个词频分统计，能够失去如下分布图
注：横坐标为包名（这里放不下），纵坐标为包名的词频分
依据察看和测试，这里把阈值定在 0.2 左右比拟能辨别用户的包名和三方、零碎库。
整体架构
在工程实现上咱们也做了一些优化
- 以前业务数据是存储在 OSS 中的，然而 EMR-OSS 目前文件解决较慢，这里换成了更适宜并行处理的 HBase。
- 只计算增量 Crash 日志, 对于存量的数据，以 HyperLogLog 的模式存储，增量计算后与存量做 Merge。
四、成果评估
惯例的利用 Package Name 做断定: F1 Score
应用词频分思路的：F1 Score
五、实在成果评估
下面的成果评估只思考到了每一个包名的状况，在生产因素下，思考到解体行呈现的地位，包名呈现的频率，以及没要害行的状况，准确率可能会有所不同，所以咱们在实在环境做了高亮测试，测试形式为：对线上 50 个 App，每个 App 取前 3 条解体来做统计，总的准确率如下，能够说是比拟高的。
安卓准确率：(33_3-9)/(33_3)*100%=90.91%
iOS 准确率：(17_3-0)/(17_3)*100%=100%
总体准确率：(50_3-9)/(50_3)*100%=94%
六、思考
小需要能够做出大深度, 后续咱们能够思考更多跨用户数据的脱敏拉通，了解数据，为客户带来更多的数据价值。
七、接下来的方向
- 组内算法的敌人说能够通过打标 + CNN 的形式来做深度学习下的三方包名判断, 这个后续能够试一试。
- 对于凭教训拍脑袋相进去的参数和方程（词频分计算），其实都能够通过打标训练的形式做参数和方程的固定，这也是一个优化方向。
八、写在最初
挪动研发平台 EMAS
阿里巴巴利用研发平台 EMAS 是国内当先的云原生利用研发平台（挪动 App、H5 利用、小程序、Web 利用等），基于宽泛的云原生技术（Backend as a Service、Serverless、DevOps、低代码等），致力于为企业、开发者提供一站式的利用研发治理服务，涵盖开发、测试、运维、经营等利用全生命周期。
欢送大家移步应用：https://cn.aliyun.com/product/emas