作者简介：黄卫军（henry），腾讯高级运维工程师，多年研发运维经验。专注于（移动+服务器）性能管理，在大数据分析领域的探索与实践。简介目前，用户体验已经成为一种新的产品价值。当技术实现不再是产品的核心竞争力，产品的竞争就是用户体验的竞争。用户触手可及的性能体验对于用户体验尤为重要。由于用户手机型号多样、手机操作系统版本不一致、APP版本难以统一，移动互联网产品很难在开发或测试过程中彻底解决手机APP的性能问题。这使得移动APP产品在运维过程中，不得不面临用户体验差、性能差的问题。如何让开发能够高效定位性能问题？让开发、测试、运维清晰的把控每个产品的性能状态？我们结合目前业界商用的APM技术，实现了一套myAPM解决方案，用于腾讯社交运维。什么是我的APM？APM（ApplicationPerformanceManagement）应用性能管理，它是一个集终端、网络、服务器性能管理为一体的监控解决方案。在这里，我就不介绍了。myAPM专注于移动性能管理。不仅可以监控定位性能问题（慢卡），还可以应用于日常APP性能运行分析，提升产品用户体验。监控方式myAPM采用BCI注入方式，实现对业务方法的细粒度监控。在选择注入技术时，myAPM采用类ASM注入技术，其注入效率、纠错能力、学习成本均优于ASM。在注入阶段，myAPM实现了性能监控和功能开发的零耦合。在编译阶段注入监控能力，零开发意识。myAPM特点：实现方法粒度的自动注入监控；myAPM采用插件化设计：各种特性和功能可以自由组合，满足开发者的定制化需求。我的APM能做什么？目前我们利用myAPM的能力主要从以下四个方面进行探索和实践：1.Apk包大小分析2.App卡慢监控分析3.App启动性能分析4.App核心链接性能分析1.Apk包大小分析一个app，随着新功能的不断增加，其apk的大小也在不断的扩大。Apk大小问题越来越困扰和制约开发者，影响了某些功能的上线，同时降低了用户体验。同时，App运行时间越长，功能迭代/代码重构越多，“垃圾”代码（即未实际调用过的代码）也会增加。由于代码量大，代码调用深度大，每个开发人员只负责部分功能开发。如果让开发者手动分析全局的“垃圾代码”，显然难度很大，效率也很低。myAPM的apk包大小分析就是用来帮助开发者快速暴露这些“垃圾代码”的。开发者只需要集中精力对已经整理出来的问题代码做进一步的确认和清理。1、Apk包大小分析原理myAPM会在类或方法中注入一个唯一的ID；内测环境部署，通过大量自动化用例，过滤掉有调用关系的代码；重新注入未调用代码，灰度网收集真实用户在线行为。通过内网测试，可以过滤掉一些常见的代码，从而减少因注入而增加的app包量。通过与大量用户的长期数据运营，无需实际调用即可定位代码。开发者可以集中精力对这些问题方法进行确认和清洗。2、apk包大小分析应用场景定位完全没有调用或引用类；（粗粒度，易清洗）定位孤岛方法：即没有主调用和被调用方法（细粒度，全面清洗）定位无调用的方法链3.Apk包大小分析特征结合离线模拟测试行为大数据结合线上用户实际行为分析大数据分析性能消耗小自动注入4.开源工具&apk包分析可能有同学会列出一系列开源工具也可以轻松识别app等非调用代码。但是对于一个有调用关系的链接（一组方法），仅仅通过离线分析是无法判断是否被调用过的。我们只能通过大量在线用户的真实行为分析来更好地判断和确认。5、方法注入样本上报唯一ID（14236），既避免了代码中敏感信息泄露的风险，又大大节省了上报量。6.Qzone-android应用示例Qzoneandroidapp，对于业务代码和第三方封装代码，采用免类调用解析。（类中的所有变量或方法都没有被引用或调用。）内测阶段：在内部测试中，由于模型的原因，测试用例有限，分析结果是42%的类没有被调用或参考。灰度外网阶段：灰度外网用户发现后，调用或引用所有类。但是40%的类被调用的次数少于10次。由于灰度用户数是50W，也就是40%的代码只有2/10,000用户有调用。对于这些，我们可以分析调整这些类的启动加载顺序（如：延迟加载）。结论：在目前的QQ空间APP中，没有多余的非调用文件。后面在监控粒度方面，我们将从“类法”进行深入挖掘分析。2.App变慢的分析在app用户体验方面，除了crash故障外，认为app的主线程（负责与用户交互的线程）变慢是用户最难以忍受的。我们这里所说的卡慢分析，是指对app主线程代码的慢监控分析。一、工作原理myAPM卡慢监控实现了目标代码的“方法粒度”注入和卡慢监控。其实质是在调用目标方法前后注入时间，监控分析卡慢。示意图如下：2.卡慢分析全过程编译时，注入：同上述“apk包大小分析”的注入阶段：类编译后，实现监控逻辑注入。在注入的时候，我们会根据当前注入方法的“调用方法-被调用方法”方法对生成一个ID。同样，它也用于信息加密和节省报告量。App卡慢监控：app版本上线后，myAPM会监控目标方法在线运行耗时，如果卡慢，会触发慢卡方法的上层全链路上报，并上报当前应用程序的基本软硬件CPU占用率等环境信息。myAPM后台会根据app上报的一组ID恢复链接。开发者可以对慢卡方式和上层链路进行性能分析；解释：myAPM报的慢卡链接恢复运行调用业务方法的过程。是一个轻量级堆栈/快照。好处是避免打印堆栈的性能开销。因为，在卡慢监控中，最耗性能的就是打印栈。收集堆栈，辅助分析：如果有些慢卡方法无法通过慢卡链接分析定位，可以将指定方法推送到指定用户的app，当在线用户指定的慢卡方法再次出现时，对应的栈信息用于辅助开发同学的分析定位。3、卡慢实例在主线程卡慢监控中，比较常见的情况是：主线程加载文件，底层DB读写，图片处理是比较耗时的操作。我们优化的方案通常是将这些耗时的操作移到异步线程中去处理。以下是四个case片段：例1：主线程执行DB查询，导致卡慢。平均耗时查看：myAPM后台会先统计慢速链接的数量，计算出链接中每个节点的平均耗时。卡慢链接中最后两组值的含义：（代码调用行号），【方法平均耗时】。耗时单位为ms。详情视图：在详情视图中，我们会列出所有的卡慢实例，以及用户的基本环境信息。卡慢链接中最后两组值的含义：（代码调用行号），【方法耗时】。耗时单位为ms。例子2：在主线程加载dex文件导致卡慢的例子。示例3：在主线程中，加载本地xml文件导致卡变慢。例子4：在主线程中，图片处理时间比较长。Process()方法用了1.3秒，setFacadeImage()又用了1秒。4、myAPM卡慢监控的优点监控粒度：myAPM卡慢监控的粒度是方法。性能消耗：myAPM卡慢方案采用卡慢业务链路上报，属于轻量级业务栈，避免了直接使用原生栈。避免了堆叠的性能消耗。（打印原生栈：1-3ms，打印业务链接：0.1-0.3ms）。数据报告：使用的一组链接ID。而不是堆栈信息。上报量小，无需加解密过程。代码依赖：卡慢逻辑与业务代码完全解耦，对开发者透明，零感知。仅用于测试，在发布前注入。五、不足之处及解决办法myAPM也有不足之处。由于采用注入方式，apk包会稍微大一些。使用qzoneandroidapk注入全业务代码时，apk大小增加0.5M，增长率为2.79%。解决方案：如果用户对apk大小比较敏感，可以采用部分注入分析。可以配合myAPM的apk包大小分析方案做apk瘦身分析。MyAPM的新特性appcardslowness仅用于有问题方法的性能优化。其实对于一款产品，我们不仅需要关注和处理卡慢问题，还需要关注app应用的总体性能状态和监控。因为，这种性能波动不会像卡慢那么明显。但在新版本迭代中，它会降低整体性能。1.监控app启动性能我们可以自定义缩小卡慢监控的范围，提供个性化的功能：只监控启动方式。通过数据分析对比，我们可以知道：各版本APP的启动性能和变化；每个连接产品的启动性能差异，以便每个产品可以相互学习和改进。2、核心环节分析无论是产品、开发、测试还是运维，你都会想知道：一个APP中哪些代码属于核心环节？这些核心环节的表现如何？在每个新版本中，这些核心链路的性能是否有明显下降？我们可以继续扩大卡慢的上报范围，全额上报。通过数据分析筛选，挖掘出核心环节及其性能数据；3、延迟加载通过链接特征分析，我们还可以提取出很少被调用，主场景不调用的代码。对于这些代码，我们可以在应用程序开始加载时使用延迟加载。从而提高APP的启动效率。续篇描述对于App启动性能分析和App核心链路性能分析，我们后面会单独介绍。最后，myAPM是基于部门实际需求，结合APM理念，对移动绩效管理的全新探索与实践。不仅针对性能问题的定位，还针对日常的app性能和运行分析。简单分享一下myAPM在移动性能管理方面的一些思考和应用。希望大家在移动端打造属于自己的表演船。在关键时刻，他们不会被推翻。共勉！【责任编辑：库木TEL：（010）68476606】
