有种速度让你望尘莫及

“案发现场”数据除了系统资源,如CPU、内存等,最重要的一定是代码的执行堆栈数据.由于移动终端性能资源有限,在采集堆栈数据的时候要非常注意对系统的影响,所以需要定好触发采集堆栈的时机,这边主要也有2种采集方案：

3.3.1 开启额外的线程记录主线程堆栈

额外启动一个子线程,子线程记录着主线程的堆栈数据,当发生卡顿的时候从该线程获取到堆栈数据,优点是只需要引入一个很小的SDK包,而且无视版本的编译方法和虚拟机.获取堆栈的策略也分为 消极策略和积极策略

1. 消极策略：
   认为卡慢卡顿的问题在短时间内只会发生一次,如果错过了将无法获取到真实的现场堆栈.
   该策略的做法是：子线程时刻获取着主线程的堆栈,当主线程发生问题时,通过发生问题的开始时间戳和结束时间戳,在子线程获取到案发时的堆栈数据(如图3-2)

   缺点：需要子线程时刻记录主线程堆栈,开销大

   优点：获取到的堆栈数据准确

图3-1监控主线程函数调用耗时

1. 积极策略：
   认为卡慢卡顿的问题在短时间内会发生几次或持续发生一段时间.

   该策略的做法是：当主线程发生问题时,激活子线程获取堆栈,在接下来的N秒内在子线程获取X个堆栈

   缺点：堆栈有随机性,获取到的堆栈是案发后的堆栈

   优点：额外开销极少,对APP基本没影响

3.3.2 在编译阶段打桩/嵌入埋点

通过在编译阶段使用工具在每个函数调用点加入耗时统计函数

缺点：增加APP包大小,经过测试约增加APP10~20%的包大小,而且不同编译方法和虚拟机需要不同的工具支持打桩嵌入；缺少系统调用数据

优点：无需运行时的额外线程额外开销

2种方案都各有优点各有可取之处,但由于产品对包大小有严格限制,目前在QQ和Qzone主要采用方案1

3.4 大数据聚类分析

前面提到,方案1的消极策略对终端性能影响较大,但是积极策略获取到的数据有随机性,即客户端无法精确的捕获到问题堆栈.

而目前我们主要采用积极策略+大数据聚类分析的方法来分析问题.这一方案的基本思想是如果一段逻辑代码真的有性能问题,那大多数用户都发生.

所以我们采用对堆栈数据做聚类分析的方法,将能形成数据规模的堆栈找出来,过滤掉偶尔由于随机性获取到的无关堆栈.

对堆栈的聚类统计上,我们主要通过构建CT(ClimbingTree)来解决.

ClimbingTree是内部叫法,主要思路是通过堆栈生成堆栈树,并利用海量数据加权计算(主要是函数耗时)到树上,最后根据权重将同层节点运行从左到右进行排序,并将设定阈值以下的节点运行剪枝.

ClimbingTree的特点是同一父节点的子节点权重大小从左到右递减

3.4.1 构建CT(ClimbingTree)图

先将一个用户的一个上报堆栈数据先进行预处理,包括解密文件、翻译堆栈函数、格式化堆栈、过滤掉无关数据等步骤,最终生成一条业务函数调用关系链.

根据调用关系,合并同个用户多个调用关系链,相同节点耗时相加,并按每个树节点的耗时从左到右排序,生成函数调用关系树(见图3-3)

图3-3 函数调用关系树

合并多个用户的调用关系树,剪掉阈值下低权重的节点树枝,就可以生成CT(ClimbingTree).这棵树里就包含了所有问题堆栈的数据聚集,并且问题严重程度从左到右排序(见图3-4).

图假设每个节点耗时为1s,那么CT里A-B-C这条调用关系链很有可能就是问题所在的函数调用关系链(因为C节点对父节点的耗时占比为：2/4=50%)

图3-4 CT图

CT的优点在于将海量的数据聚集统计到少量的森林数据节点里(约压缩90%-95%的数据量)

由于左子节点一定比右节点耗时长,所以往往左子节点即是影响父节点的问题所在,通过分析左子节点占父节点的耗时占比可以得到最根源的耗时函数所在(见图3-4、图3-5)

图3-5 寻找最根源的耗时函数节点

3.5 终端常见性能问题总结

最常见的问题在主线程做长耗时操作,如
· 数据库操作
· 网络连接等待
· 网络数据等待
· 复杂逻辑计算
· SD卡检查或读写

（编辑：衡阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!