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

通过这个演示文档,我们希望给你介绍我们的QAPM,让你了解我们的愿景和目标。

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

​下面我们将具体从几个方面详细介绍我们的QAPM

性能专项体验,用户体验的重要一环

我们经过十年的沉淀形成的方法论,会把性能拆分成资源类性能与交互类性能,但是如果从用户角度切入,诸如各种性能问题最终都可以收拢成用户能感受到的三类问题:闪退、卡顿、耗电发热。这三类问题也导致了我们从用户反馈、用户上报分析中发现的用户投诉,流失,甚至是资本的损失。

举个例子,例如性能中的内存,我们会关注内存泄漏,然而内存泄漏导致的不可释放的内存增长极少呢?那算是问题吗?或者说怎样才算?当然,从代码质量角度,毫无疑问要改,但从用户影响角度,如果这个泄漏能最终导致OOM或者句柄限制错误(闪退);又或者是导致内存不够用,频繁GC For Alloc,最终导致卡慢,都能说明这是问题,同时当然也是从用户价值层面收拢这些性能问题的一个重要维度。

而这些问题,最终会导致:

  • 用户投诉,如手Q之前10%~15%的投诉;
  • 低端机用户的流失,正面的案例是王者荣耀在高中低端表现的出色,让它能快速突破需要游戏的用户量的瓶颈,成为国民游戏;
  • 甚至最严重的资本损失,如某些收费特性的闪退、卡死,会影响收入,又如隐藏的代码逻辑错误,导致无限重复下载,进而导致极大的带宽消耗,会增大企业的支出。

那么在腾讯,我们是如何通过QAPM预防与解决性能专项体验问题的呢?这里就延伸出六个痛点,大家可以看下有没有命中。

痛点及其解决方案

痛点1:投入专项测试的人力压力

我们的测试工作,除了性能专项,还有其他各种各样的测试,除此之外还要考虑各个性能维度的测评,当然,还要组合上不同的测试用例、测试场景,包括机型、系统、网络等等,有时候,如内存测试,曾经的我们还要反复执行测试用例,来发现内存泄漏。我们相信,大部分团队跟我们一样,功能测试都做不过来,虽然性能也重要,那也没有办法再投入资源了。

下面举一个我们真实的案例。

QAPM配合我们另外一个品牌工具,在研发流程内NewMonkey,从人工发现内存泄漏,到全自动侦查,在研发流程外通过用户执行,也可以帮助发现内存泄漏的问题。

最终我们在多个项目做到了零人力投入内存测试,一年累计有效缺陷6K(开发已修改,未计算未修改的)

下面是我们的原理,透过监听onDestory来自动检查内存缺陷,然后整合从发现、提单再到定位问题的研发流程,简单说就是全自动化,把都自动化起来,来解决专项人力投入的问题。

备注:

  • 重复内存, 如在手Q,之前就出现过头像图片重复缓存的问题,降低了缓存的有效性
  • RGBA8888, 如在电竞等一些项目,图片使用RGBA8888来解码大图,但是图片本身并没有透明图层,对颜色要求也不高,推荐使用RGB565来解码

在QAPM,我们通过分析型数据定位,指标性型数据定性,通过智能分析,自动提单,达到卡顿,内存、耗电、磁盘测试的零人力。未来,我们将来沿着覆盖全部专项维度不断建设后续。

这里具体说两个案例,很多时候,没有接入QAPM之前可能都不知道我们有多少专项风险。

案例1:电量监控

在手Q,我们刚开发出来了电量监控能力,在灰度放出之后,发现许多隐藏的耗电的地方,当然也能节省下来专项测试的人力。

案例2:磁盘性能

每个接入QAPM的产品,都能发现许多隐藏的磁盘性能问题,其中修复效果最显著的就是数据库的I/O问题。通过QAPM,我们就可以知道数据库实际的I/O操作之外,还可以知道溢出页的数量。像上面的案例,溢出页就有1.5w,根据这个结果,我们就可以适当地调整PageSize,提升数据库I/O的性能。但是人力除了测试之外,我们还需要有QA或者测试Leader、开发Leader把控全局,因为我们还有Dashboard,帮助我们从宏观的层面了解App的现状。

通过Dashboard, 我们可以知道几个核心指标的现状,如果要了解更详细的,点击则可以进入我们的详细情况。

上面的性能看板展示数据比较全面,如果想简洁直接的了解app当前的上报情况和实时资源消耗情况,可以查看项目实时性能问题报表页面。

为了让人力效率提升到最佳,不需要有人盯着QAPM,我们有一套“还能用”的告警能力(还有很多需要改进)。通过告警,甚至你可以针对VIP的用户,打造像特斯拉一样的服务体验,在投诉反馈没有开始之前,就主动跟用户接触。

我们还实现了rebuket AI算法智能聚合,利用堆栈相似度的计算算法,计算出了每次告警中堆栈的相似度,并给出了相关的提示。

痛点2:开发定位和重现效率低下

App如果涉及到上百人的团队,那么开发定位性能问题的效率就会非常低。如果是下图提供的缺陷,那简直要了开发的命。在前面的痛点1中,我们说了分析数据上报,这个数据就包含一个开发快速定位问题的利器,堆栈。

基于堆栈,我们在ios与android的SDK之中,构建覆盖各种性能问题的定位能力,助力开发精准打击。

除了堆栈之外,如果深度合作,透过独立的代码diff管理库,我们可以提供更精准的定位能力。

为避免所有卡顿个例逐条上报,导致重点不突出或寻找关键问题花费大量精力,我们通过抽取关键应用层堆栈函数对卡顿个例进行聚合,能够展示这些函数的触发次数和函数耗时情况,以帮助项目发现重点问题进行优化。

痛点3:如何集中精力解决核心专项问题

另外一个问题来了,我们这么多性能问题,固然可以帮助预防风险,但是那些问题需要优先解决呢?要知道除了性能缺陷,一个APP还有许多别的缺陷,这些缺陷是解不完的,究竟哪个更加重要?这里就需要介绍我们的函数级别聚类算法,算法是依据堆栈由函数组成的特征开发的。

无论是内存还是卡顿,我们都通过堆栈聚合,发现核心性能问题。

下面来看看具体的例子。

1.顺向聚合

从栈顶开始到栈底,通过大数据智能聚合之后,我们可以看到导致我们卡顿的核心原因是什么,然后有根据地进行优化。

2.逆向聚合

从栈底开始到栈顶,聚合之后,可以发现影响性能的最底层的方法。做到优化一处,作用在整个App上。

而在实践中,我们发现,一个新的App接入,顺向能发现很多有效的问题,但是当头部问题解决完之后,我们就需要从逆向去发现那些底层的性能问题。下面我来介绍一个手Q的例子。

​在手Q,我们惊奇地发现逆向聚合的头部,居然是判断文件是否存在的方法,那也对,那也是个主线程I/O问题,而且我们发现,当手机使用时间越长,手机的本地文件越多,性能就越差,一个判断要耗费1s~2s都不奇怪。

然后我们想了个办法来回避这个频繁的判断,最终手Q的卡顿率优化从98.2%到了98.8%,对于手Q这种App来说,可以说是成果显著。

痛点4:解决后如何体现解决的价值

正如前面所说,度量很重要,他可以用来决定解决什么问题,当然也可以用来判断App当前的性能是否ok。因为移动端设备碎片化问题,所以仅有全网的抽样数据,才能代表App真正的性能情况,不要只是看“测试报告”。

而QAPM也全力在让我们的度量更加专业完备,而不是掩耳盗铃,这样团队在性能优化上才有目标可循,通过价值推动持续优化。

其中一个最典型的就是Crash率

在大部份情况下很多iOS App的Crash率都不能反应真实的情况,因为Sigkill都是没有被统计的。而QAPM不仅仅统计了,输出了一个新的Crash率-ACrash率,还提供了一个还可以用的分析能力。但是在手Q上效果也很显著,让手机QQ的ACrash率下降了近一半有多。

另外一个更准确的指标就是掉帧率

在游戏和不少App都用FPS来衡量App的流畅度,但是有个问题,如果一个App卡顿了30帧,近500多ms,但是FPS依旧是人类能接受的30帧(24帧都是ok的)。

而我们的计算方法,简单理解就是用 “卡顿时长除以滑动(动画)时长”得到一个越小越流畅的掉帧率,简单理解就是“卡顿的总时长”在“用户滑动的总时长”中的占比。

经过我们长期的使用,我们在大部分腾讯头部项目中,都会定义“大于98%”是及格的分数。 可以理解成, 如果全部用户加起来100秒的滑动“操作时长”中,全部用户加起来的“卡顿时长”只有2秒,其余的98秒时流畅的。 这里,我们认为的“卡顿时长”是指掉帧大于8帧的时长。微视通过一轮一轮优化,终于达到及格的水平。

痛点5:如何真正从监控到真正解决性能问题

对于大部分的APM而言,他们都是提供监控功能,定位分析的能力,但是很少说会提供解决能力。

而QAPM从是手Q等项目中孕育出来的,所以同时也包含了一些真正解决性能问题的推荐代码实现。我们希望这些经验能通过QAPM传递到行业互联网中的更多移动App,提升他们的体验。

下面是我们在磁盘I/O上沉淀的一些解决方案。

在磁盘I/O里面, 我们的解决方案沉淀在了公司的知识管理系统, 后续我们会逐步通过腾讯云的云+社区的团队页面来沉淀这些解决问题的经验,也会关联到我们的缺陷上,提供给大家。在这之前,很欢迎接入QAPM的合作伙伴跟我们咨询在QAPM上发现的性能问题的解决方案。

我们在手Q、空间、音乐等多个产品,落地I/O性能检查,并给予开发对应缺陷的解决方案,效果显著。

痛点6:如何高效准确获取关键问题信息

由于部分内容未开放,局限性可能造成反馈的数据不全面,不能很好地反应项目所有用户的真实情况,或执行操作获取数据耗时过长,且难掌握关键性信息。

考虑到给予用户足够的发挥空间,方便项目自动化调用QAPM接口来进行自动化测试或数据分析,我们做了token的api接口,用户能根据需要自助自由筛选数据源,构建出专业的APP性能报表,还可通过个性化配置定义自己想要的数据展现形式。

在场景对应代码调用QAPM接口,获取区间性能数据,上报后台处理后,可通过QAPM的web页面直接查询性能数据,除了web页,QAPM还集成开源组件Grafana,利用其强大报表能力更直观的展示。

功能总结及用户关心的问题

我们不妨从另外一个大家感兴趣的问题来总结下QAPM,就是它跟其他的APM的区别。

如图,我们的优势,除了借助腾讯云强大的云计算技术外, 我们更专注在移动App的性能上,构建如之前所说的,从发现,定位,解决,度量的一站式性能解决方案,帮助客户真正解决性能问题,而不仅仅局限于监控。

对于QAPM来说,也不是没有弱势的地方,相对于起源于后台应用与网络的听云监控,我们在网络、Web、全链路监控上有待加强,希望与我们的客户共同进步。

另外,一个大家可能很关心的问题,就是QAPM的实际性能消耗。

如下图中表格所示,我们的性能消耗控制在一定的范围内,特别是我们推荐的正式发布配置,而且我们在手Q等产品均是跟随外网发布,有过亿用户的检验。

QAPM还在不断的成长中,欢迎你的加入~

十分感谢一路陪伴我们支持我们的APP~

想了解更多QAPM详情,请咨询:腾讯专项体验助手

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

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

编辑于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券