如何制作网站的app,分类信息网站如何做优化,网页版qq登陆登录,wordpress修改底部联系QQ简介#xff1a; 崩溃堆栈是我们日常应用问题排查中的重要辅助手段#xff0c;在移动开发上也不例外#xff0c;为了支持用户在堆栈上的快速定位#xff0c;我们面临一个看似比较简单问题#xff1a;高亮崩溃中的关键行, 辅助用户快速定位问题。 阿里云 云原生应用研发平台…简介 崩溃堆栈是我们日常应用问题排查中的重要辅助手段在移动开发上也不例外为了支持用户在堆栈上的快速定位我们面临一个看似比较简单问题高亮崩溃中的关键行, 辅助用户快速定位问题。 阿里云 云原生应用研发平台EMAS 张月此间
一、前言
崩溃堆栈是我们日常应用问题排查中的重要辅助手段在移动开发上也不例外为了支持用户在堆栈上的快速定位我们面临一个看似比较简单问题高亮崩溃中的关键行, 辅助用户快速定位问题。 崩溃堆栈关键行: 堆栈中是属于用户开发代码中那行直接引起崩溃的代码。 举个例子
二、 业界方案
业界的竞品基本上是通过 Package Name判断的在没有 Package Name 的情况下有的竞品会定位到第一行有的则会定位到非系统库的第一行。 例如: 友商这种情况下就将关键行挂在了第一行 fastjson 的位置。
这里容易出现两个问题 1.Package Name 大多数时候和真正的崩溃包名关系不大。 2.App 组件化包名不能覆盖一方库二方库。 为了更好的解决这个问题我们提出了下面用词频比/词频分的方式来解决问题的新方案。
三、新方案
所以在 Package Name 的基础上我们还需要一个辅助手段让我们能够识别这两种情况从而在关键行定位更精准。
这里我们想到的一个做法就是利用全量的 Crash 崩溃堆栈计算词频比和相应的词频分通过概率去优化我们的关键行判断。
实现上分为两个平台。
3.1 对于 iOS
1主包判断
这个问题对于 iOS其实不用考虑用户填写的 Bundle ID, 因为 IOS Crash 天然就自带 Binary Images我们将用户主包信息预存下来用于后续判断就行了。 Binary Images
2直接定位: 对于组件化的包我们可以通过 Binary Images 里面的信息统计一下每个包名出现的频率具体的频率分布统计大致如下图所示纵坐标代表包名出现的次数
- 注横坐标为包名这里放不下纵坐标为包名出现次数
出现的频率越低那么我们越认为他是一方库或者二方库。
3.2 对于 Android
对于 Android情况稍微复杂一点首先 Android 的 Crash 中其实是不能明确标识包名的而且 Android 的 Package Name 并不是一个词而是一长串的以点分隔的包名, 例如
com.aliyun.emasha.cache。
如果单纯的还以包名的词频比来做匹配的话那么就会出现下面的问题 a.历史数据 只出现 com.aliyun.emasha.cache 的包名 下次出现个 com.aliyun.emasha.login 的就匹配不上了。 b.同样是 com.aliyun.emasha 的前缀匹配到了 com.aliyun.emasha 和匹配到了 com.aliyun.emasha.cache 包名的词频相差很大不符合常理。
所以还要解决这两个问题 a.能够尽可能的覆盖未出现的崩溃情况。 b.随着匹配的前缀越长需要考虑前面的包名匹配带来的影响。
所以这里要引入包名分级和词频分的概念 a.包名分级将包名 split(.) 得到数组从前往后为 1级2级3级这样的分级。 b.包名词频分根据包的词频比多级累加算出来的一个评价包名是否是三方库的分数分数越高是三方库的几率越大。
但这还不够如果我们的词频比只是单纯的累加那么 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 左右比较能区分用户的包名和三方、系统库。
3.3 整体架构
在工程实现上我们也做了一些优化 1.以前业务数据是存储在 OSS 中的但是 EMR-OSS 目前文件处理较慢这里换成了更适合并行处理的 HBase。 2.只计算增量 Crash 日志, 对于存量的数据以 HyperLogLog 的形式存储增量计算后与存量做 Merge。
四、效果评估
常规的利用 Package Name 做判定: F1 Score
使用词频分思路的F1 Score
五、真实效果评估
上面的效果评估只考虑到了每一个包名的情况在生产因素下考虑到崩溃行出现的位置包名出现的频率以及没关键行的情况准确率可能会有所不同所以我们在真实环境做了高亮测试测试方式为对线上50个 App每个 App 取前3条崩溃来做统计总的准确率如下可以说是比较高的。
安卓准确率(333-9)/(333)*100%90.91% iOS准确率(173-0)/(173)*100%100% 总体准确率(503-9)/(503)*100%94%
六、思考
小需求可以做出大深度, 后续我们可以考虑更多跨用户数据的脱敏拉通理解数据为客户带来更多的数据价值。
七、接下来的方向
1.组内算法的朋友说可以通过打标 CNN 的方式来做深度学习下的三方包名判断, 这个后续可以试一试。 2.对于凭经验拍脑袋相出来的参数和方程词频分计算其实都可以通过打标训练的方式做参数和方程的固定这也是一个优化方向。
八、写在最后
移动研发平台 EMAS
阿里巴巴应用研发平台 EMAS 是国内领先的云原生应用研发平台移动App、H5应用、小程序、Web应用等基于广泛的云原生技术Backend as a Service、Serverless、DevOps、低代码等致力于为企业、开发者提供一站式的应用研发管理服务涵盖开发、测试、运维、运营等应用全生命周期。 原文链接 本文为阿里云原创内容未经允许不得转载。
