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详情，请咨询在线客服：QAPM

​