业务运维实战：腾讯是怎么优化APP用户体验的？(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在移动性能管理方面的一点思考及应用,希望大家打造好自己移动端的性能小船,关键时刻,不会说翻就翻.共勉!

文：黄伟俊(henry)

原文出处：高效运维(greatops)

（编辑：ASP站长网）