专栏首页QAPM-腾讯客户端性能分析透视QAPM Android新卡顿&新启动分析的技术方案
原创

透视QAPM Android新卡顿&新启动分析的技术方案

春节快乐,干货来袭。QAPM团队已服务于公司内外包括国有大行的50+产品,声音大呀,但是之前的卡顿与启动个例是真心不好用,也让不少团队憋着对我们的吐槽来推广他们的新方案。何苦呢?我们怎么能站着茅坑不XX!新方案其实一直在路上,一直在路上,现在终于来了。本文,我们会描述两个“在路上”的曲折与思考,也透视出新方案的技术核心与优势。

切肤之痛,个例单堆栈根本无法定位准确

例一:堆栈显示正常创建一个对象,这个地方怎么会卡呢

例二:堆栈显示的是个空方法

类似的反馈我们收到了太多了,卡顿方案的缺陷也一直是我们的痛点。一个事件下存在大量的执行函数,而方案是基于阈值满足的前提下才执行的堆栈抓取,这样会产生堆栈偏移,有可能真真实实捕获到了卡顿所在的函数,但更多的是一些不卡的函数,只是刚好被捕获到了~

一直在路上之一,方法插桩,稳定+可靠+性能好

通过在方法的开始和结束点插入方法,统计并记录方法名与方法耗时。微信和闪现社区用的都是这个方案。经过微信的打磨,在其开源的Matrix中已经非常完善,稳定可靠,性能好。这么好,是不是直接用微信的方案吧,但是我们很犹豫。而这犹豫源自于一个我们执迷不悟的坚持。

我们团队都是专项测试出身,跨产品做性能分析与优化是家常便饭,也因此对于我们来说,可以泛化的分析方法,价值更大。系统方法调用栈就是构成这个分析方法的核心,例如文件与数据库的主线程I/O,IPC/RPC的调用导致的卡顿/ANR,其实都有可以总结的优化方法和思路。而这个美好的插桩方案让我们犹豫的核心原因就是,没有系统方法调用。然后我们就一直犹豫,不想放弃原来的方案。

一直在路上之二,一个“无效”的突破

正当我们犹豫之际,我们的nicky同学在受到闪现社区的冲击(技术人的冲击就是这么地简单纯粹),又一个团队选择了插桩。这时,nicky开始深入研究JVMTI的黑科技,希望可以有个完美方案。最终我们成功绕过了debug包的限制,在不侵入的前提下,在release包下可以拿到各个方法的进出及耗时。原本以为胜利就在前方,但却被现实泼了冷水。在JVMTI开启的情况下,性能消耗是原来的100%。。。一番考虑下,APM这边暂时不将该方案合入,但JVMTI的突破,的的确确给了我们更多的发展空间,如线程监控、内存分配监控等等。

终于来了,谁说采堆栈不能优化

撞了南墙也要破个洞穿过去!采集堆栈的方法真的无解吗?在这之前,我们来总结下,目前主流的实时获取耗时信息的方案:插桩法、定时堆栈法、jvmti法。其优缺点和典型的代表如下:

JVMTI法:由于性能问题,APM暂时不做考虑;定时堆栈法:精准度低,性能消耗大;插桩法:无系统和应用层的调用关系,侵入性强且后续有包体优化的成本。这样看来,好像没有一个方法是合适的。但我们的内心是喜欢定时堆栈的,无他,为了那个具备问题解决方案泛化价值的系统调用栈。

"方法总比问题多",执迷不悟的我们还是尝试从问题着手,去尝试优化那个别人抛弃的定时堆栈。而核心就是要破除这个看似无解的问题,性能差-精度低。精准度低:事件内多函数执行,达到阈值才去抓取堆栈只能靠运气的抓到真耗时函数,大部分抓到的可能是耗时短的函数;性能消耗大:堆栈转换成字符串时容易造成太多GC,而为了提升精度,还会要增加捕获的堆栈,也增大了性能的消耗。下面来看看,针对这两个问题,我们是如何突破的。

解决精准度低的问题:

在事件进入时,开启一个延时的定时任务,如果任务在规定时间内完成则取消掉,否则开始间隔30ms抓取堆栈对象,最多抓取3秒数据的堆栈,即100个堆栈对象。

解决性能消耗大的问题:

一个小小的细节:

一个堆栈对象,真的没有可以利用的空间了吗?一个堆栈由包名、文件名、方法名和行号组成,但其实我们还忽略了一个比较重要的信息,是该栈距栈底的距离。而通过行号及栈深的计算,基本可以确定栈的唯一性

抓取到的堆栈对象中的每一行栈,转成字符串做map存储计数,就能大概分析出卡顿的点了,但如果使用字符串去匹配,那内存的消耗则会大大的上升,那如何不使用字符串匹配又能知道出现次数最多的栈呢?

整型的计算,远远会比字符串的操作消耗要低。通过行号及栈深来记录该栈的出现次数,应该就能初步解决消耗大的问题。

为什么说是初步?试想一下,极端情况下,我们抓到了100个堆栈数组,且每个堆栈数组的深度有50行+,在每个堆栈都需要计算存储的前提下,我们至少得需要5000+次的计算任务。这里其实也是有不小的消耗的。那能不能减少这里的计算和存储成本呢?其实是可以的。APM对于一个堆栈数组的处理是这样的,从找到第一个非系统栈开始,保留业务栈的上层系统栈,从当前栈开始,往下追五层,如果连续超过5层还有业务栈,则不再处理新的业务栈,且当再次碰到系统栈或者遇到handleCallback等方法时,结束处理当前堆栈数组。

将堆栈归类后,现在就要找到大头卡顿的栈,怎样算大头卡顿的栈呢?这个其实也没有一个太好的标准。目前卡顿阈值是200ms,30ms取栈一次,大于3次则认为是卡顿的源头了。在寻找大头卡点时,又碰到了另一个问题,就是怎么去除重复的栈。举个例子:如果连续出现多个同样的堆栈数组且堆栈数组内有多个业务栈,就会发现会有多个key指向同一个堆栈,如下图

这种情况多出现于该函数发生长卡顿的,对于这种情况,我们采用的是有序的map来进行存储,栈存储时是由上往下遍历存储,所以读取时我们从下往上遍历。如上图的情况,我们会先找到了行号为410的栈,发现他的儿子栈为70,于是往上追,再发现他的儿子栈为613,以此类推,最终找到了618的栈顶类,这个时候再来做处理,就可以避开另外三个的栈处理。

最后找到最大头的卡点进行上报

最终我们借助真实的App测试了性能消耗

这里特别感谢手Q和视频团队提供的测试环境。

通过WeTest和PerfDog的性能测试工具,分别对带有新卡顿和旧卡顿的包进行了多场景下的性能测试,在获取更多堆栈,更多逻辑处理的基础上,大部分数据与旧卡顿相差无几。而且普通的系统方法获取堆栈,绝对没有任何兼容性问题,安全可靠,而且还有那个我们梦寐以求的系统调用在其中。

最后

小小的细节,大大的改变。如对方案有异议或有更好的建议,欢迎批评指正(QAPM是个很开放的团队哦~)

--

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • QAPM — 一款强大且细腻的APP性能专项解决方案

    QAPM是我们腾讯云专项测试技术中心其中一个较为成熟的产品,是针对移动App的一个一站式性能解决方案。

    QAPM腾讯客户端性能分析
  • QAPM新版本:AI聚合,效率提升305%(Android2.5.2)

    QAPM是一款全方位定位检测 APP 应用性能的 SDK,简单易用、并能提供多维度检测及分析,只需简单的调用几个接口,就能对 APP 做全方位的性能检测。

    QAPM腾讯客户端性能分析
  • 微视iOS SIGKILL BUG实例

    微视iOS接入QAPM作为项目的性能监控工具已有一年多,打开的功能包括掉帧率、卡顿、SIGKILL、内存触顶、VC泄露和大块内存监控。在QAPM同学的日常运营过...

    QAPM腾讯客户端性能分析
  • 告别重复告警打扰--基于堆栈相似度的全新QAPM告警方案

    导语 为了能够及时的发现问题并及时解决,QAPM提供了一套卡顿告警机制。正如同常规的阈值触发的告警机制一样,QAPM早期的告警也会使测试开发人员陷入告警风暴的影...

    QAPM腾讯客户端性能分析
  • 【私有化质量实践1】出了问题要“坐牢”的SDK

    后台都还好,SDK跟着这些金融类产品发布。我们总开玩笑说,一旦出问题,都是“坐牢”的事情,瑟瑟发抖呀。当然,也许“坐牢”不必,但是前一阵某金融行业内部的产品,就...

    010101011001
  • 技术揭秘,QAPM的这位Android内存分析“专家”

    QAPM原有Android内存快照分析是基于那个颇具历史感的MAT的命令行版本开发的。MAT到现在都依旧是最最强大的内存快照分析工具,就是他那个类SQL的查询能...

    010101011001
  • 金九银十准备换场地?对标腾讯T3的Android高级工程师面试大纲及时雨来了

    1、Activity是什么 2、Activity四种状态 3、Activity生命周期 4、进程的优先级 5、Activity任务栈 6、Activity启动模...

    Android技术干货分享
  • QAPM小程序性能监控难点与解决方案

    目前公司内外存在多个小程序的监控方案,包括微信提供的原生方案、Aegis、Fundebug和听云等,那么对比这些的监控方案,QAPM的小程序质量套件有什么不同呢...

    010101011001
  • 动效歌词之全新实践

    一、 背景 1. 现状 歌词浏览已经成为音乐app的标配,展示和动画效果也基本上大同小异,主要是单行的逐字染色的卡拉OK效果和多行的滚动效果。当然,我们也不例...

    QQ音乐技术团队
  • 动效歌词之全新实践

    一、 背景 1. 现状 歌词浏览已经成为音乐app的标配,展示和动画效果也基本上大同小异,主要是单行的逐字染色的卡拉OK效果和多行的滚动效果。当然,我们也不例...

    QQ音乐技术团队
  • Android 中的卡顿丢帧原因概述 - 系统篇

    在Android 中的卡顿丢帧原因概述 - 应用篇[1]这篇文章中我们列举了应用自身原因导致的手机卡顿问题 , 这一篇文章我们主要列举一些由 Android 平...

    字节流动
  • Android APP性能优化分析

    本文通过Android APP性能优化的四个方面做了详细分析,并对原理和重点做了详细解释,以下是全部内容:

    砸漏
  • 【私有化质量实践2】最“年轻”的云原生数据服务

    随着云架构的不断普及,“未来的软件一定生长于云上”的理念被越来越多的人所接受。云提供了一种面向企业应用实现按需进行资源分配的模型,以一种全新的、高效的方式来部署...

    010101011001
  • Android开发高手课NOTE

    内存优化 卡顿的原因 频繁 GC 造成卡顿、物理内存不足时系统会触发 low memory killer 机制,系统负载过高是造成卡顿的俩个原因。

    六月的雨
  • 2019 金九银十多家BAT大厂Android面试真题锦集干货整理

    又到了金九银十的面试季,自己也不得不参与到这场战役中来,其实是从去年底就开始看,android的好机会确实不太多,但也还好,3年+的android开发经历还是有...

    Android技术干货分享
  • 一位30K大佬的面试经验!Android高级开发岗必问知识点,赶紧收藏

    最近这两年移动开发遭遇寒冬,再加上培训机构以及很多应届生的加入,很多从事Android和IOS开发的同学,都出现了工作难找的情况。基于此种情况下,这段时间基于以...

    Android技术干货分享
  • 各种风格的Android面试题,进来了解一下?

    又到了面试旺季,自己也不得不参与到这场战役中来,其实是从去年底就开始看,android的好机会确实不太多,但也还好,3年+的android开发经历还是有一些面试...

    Android技术干货分享
  • Android面试|任何东西只要够深,都是一把刀!性能优化都没搞好就别想着去找对象了

    您瞧清楚了,我是互联网公司技术开发一枚,渴了喝咖啡,饿了吃外卖,晕了上医院的那种。房贷没还清,车子自己买,人家休假我加班。还有最重要的是,我是一条单身狗。不要想...

    Android技术干货分享
  • Android卡顿监控系统

    Android 由于机型配置和系统的不同,项目复杂App场景丰富,代码多人参与迭代历史较久等,实际测试时候也会偶尔发现某些业务场景发生卡顿的现象...

    likunhuang

扫码关注云+社区

领取腾讯云代金券