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