有种速度让你望尘莫及(2)
怎么判断终端出现卡慢等性能问题呢?通过上面对andoid和ios的背景介绍,我们的目标放在主线程的监控上,这边主要有2种监控策略:
如图3-1监控屏幕FPS的次数 3.3 堆栈的采集监控的策略有,接下来应该考虑怎样配合监控策略,把“案发现场”的数据获取出来并上报至服务端. “案发现场”数据除了系统资源,如CPU、内存等,最重要的一定是代码的执行堆栈数据.由于移动终端性能资源有限,在采集堆栈数据的时候要非常注意对系统的影响,所以需要定好触发采集堆栈的时机,这边主要也有2种采集方案: 3.3.1 开启额外的线程记录主线程堆栈额外启动一个子线程,子线程记录着主线程的堆栈数据,当发生卡顿的时候从该线程获取到堆栈数据,优点是只需要引入一个很小的SDK包,而且无视版本的编译方法和虚拟机.获取堆栈的策略也分为 消极策略和积极策略
图3-1监控主线程函数调用耗时
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 终端常见性能问题总结最常见的问题在主线程做长耗时操作,如
|