前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >实战移动性能优化,性能小船不会翻

实战移动性能优化,性能小船不会翻

原创
作者头像
serena
修改2021-08-03 14:56:06
8190
修改2021-08-03 14:56:06
举报
文章被收录于专栏:社区的朋友们社区的朋友们

作者:黄伟俊

引言

当前,用户体验已成为一种新的产品价值。当技术实现不再是产品核心竞争力时,产品的竞争就是用户体验的竞争。而用户弹指间感知到的性能体验对于用户体验尤为重要。

移动互联网产品因为用户的手机型号繁多、手机操作系统版本不一致、app版本难统一等问题,很难在开发或测试环节就完全解决掉移动app的性能问题,这使得移动app产品在运维过程中,不得不面对用户体验不优、性能不佳的问题。

[1498812041289_6971_1498812041114.png]
[1498812041289_6971_1498812041114.png]
[1498812396516_174_1498812396327.png]
[1498812396516_174_1498812396327.png]

如何让开发可以高效定位性能问题?

让开发,测试,运维清晰的把控各个产品的性能状况?

我们结合了当前业界商用的APM技术,实现了一套腾讯社交运维的myAPM方案。

myAPM是什么

APM(Application Performance Management)应用性能管理,它是一套集终端,网络,服务端性能管理方案。在这里,就不展开介绍了。

myAPM,专注于移动端的性能管理。既能监控定位性能问题(卡慢),也能应用于日常的app性能运营分析,提升产品用户体验。

监控方式

myAPM采用BCI注入方式,实现业务方法粒度监听。

在注入技术选型时,myAPM采用了类ASM的注入技术,其注入效率,校错能力,学习成本,都比ASM要好一些。

注入阶段

myAPM实现性能监控与功能开发零耦合。在编译阶段注入监控能力。对开发零感知。

[1498812790195_9537_1498812790065.png]
[1498812790195_9537_1498812790065.png]

myAPM特点

  1. 实现方法粒度的自动化注入监控;
  2. myAPM采用插件化设计:各个特性功能能自由组合,以满足开发者定制化需求。

myAPM可以做什么

当前,我们利用myAPM的能力,主要从以下四个方面进行探索与实践:

  1. Apk 包大小分析
  2. App卡慢监控分析
  3. App启动性能分析
  4. App 核心链路性能分析

Apk大小分析

一个app,随着新功能的持续增加,其apk的大小也在不断地膨胀。Apk size的问题,越来越困扰和限制着开发同学,影响某些功能的上线,同时,也降低了用户体验。

同时,app运营时间越长,功能迭代 / 代码重构次数越多,“垃圾”代码(就是没有被实际调用过的代码)的数量就会越多。

由于代码量大,代码调用层次深,每个开发同学只负责部分功能开发。如果让开发同学人工去做全局“垃圾代码”的分析,显然,其难度很大,效率不高。

而myAPM的apk包大小分析,就是用来帮助开发同学,快速暴露这些“垃圾代码”,开发同学只须集中精力,针对梳理出来的问题代码,做进一步确认和清理即可。

Apk包大小分析原理

[1498812864644_8977_1498812864564.png]
[1498812864644_8977_1498812864564.png]

1.myAPM会在类或方法中,注入一个唯一ID;

2.内测环境部署,通过大量的自动化用例,过滤掉有调用关系代码;

3.对未调用代码,进行重新注入,灰度外网,收集线上真实用户的行为。通过内网测试,可以过滤掉部分常用代码,从而减少因注入增加的app包量;

4.通过长时间,大用户量的数据运营,我们即可定位出无实际调用的代码。开发小伙伴即可集中精力在这些问题方法的确认及清理。

Apk包大小分析应用场景

1.定位完全无调用或被引用的类(粒度粗,清理方便);

2.定位孤岛方法:即没有主调和被调的方法(粒度细,清理全面);

3.定位无调用的方法链路。

Apk包大小分析特点

1.结合线下模拟测试行为大数据分析 ;

2.结合线上用户实际行为大数据分析 ;

3.性能消耗小 ;

4.自动注入 。

开源工具 & apk包分析

可能有同学,会罗列出一系列开源的工具,也可以很方便地甄别出app这种无调用代码。

但对于有调用关系的一条链路(一组方法),仅仅通过线下分析,无法判断其是否有被调用。我们只能利用线上大量用户的真实行为分析,更好地去判断和确认。

方法注入样例

[1498812958285_6686_1498812957911.png]
[1498812958285_6686_1498812957911.png]

通过一个唯一ID(14236)来上报,既避免了代码中敏感信息的泄漏风险,同时,也大大节省上报量。

Qzone –android应用实例

Qzone android app,针对业务代码以及第三方包代码,采用类无调用分析(类中所有变量或方法,没有被引用或调用)。

内部测试阶段:

在内部测试中,由于机型,测试用例有限,分析结果是42%的类没有调用或引用。

[1498813091298_2301_1498813091152.png]
[1498813091298_2301_1498813091152.png]

灰度外网阶段:

在灰度外网用户后发现,所有类都被调用或引用。但40%类被调用次数少于10次。由于灰度用户是50W,即40%的代码只有万分之二的用户有调用。针对这些,后续我们可以分析,调整这些类的启动加载顺序(如:延时加载)。

[1498813128383_5068_1498813127973.png]
[1498813128383_5068_1498813127973.png]

结论:

  1. 当前QQ空间 APP,不存在多余无调用类文件。
  2. 后续,在监控粒度上,我们会从“类?方法”进行深层面的挖掘分析。

App卡慢分析

在app用户体验上,除了crash故障外,相信app主线程卡慢(负责与用户交互的线程),是用户最不能忍受的。

我们这里所说的卡慢分析,是指对app主线程代码的卡慢监控分析。

工作原理

myAPM卡慢监控,实现对目标代码的“方法粒度”的注入、卡慢监听。

其本质,是在目标方法调用的前后,注入时间,进行卡慢监听及分析。原理图,如下:

[1498813481298_2874_1498813481252.jpg]
[1498813481298_2874_1498813481252.jpg]

卡慢分析全流程

[1498813538261_7010_1498813537951.jpg]
[1498813538261_7010_1498813537951.jpg]

1、app编译时,注入。

跟上面“apk包大小分析”的注入阶段一样:在class编译后,实现监控逻辑注入。

注入时,我们会根据当前注入方法的“主调方法-被调方法”方法对,生成ID。同样,也是用于信息加密及节省上报量。

2、app卡慢监控

app版本上线后,myAPM会监控目标方法线上运行耗时,出现卡慢,则触发卡慢方法上层全链路上报,同时上报app当前基本软硬件CPU等使用率等环境信息。

3、myAPM后台,会根据app上报的一组ID,进行链路还原。开发同学,可以针对卡慢方法,以及上层链路进行性能分析;

说明:myAPM上报的卡慢链路,还原了业务方法运行调用的过程。是一种轻量级的堆栈/快照。其好处是避免打印堆栈的性能消耗。因为,在卡慢监控中,最消耗性能的就是打印堆栈。

4、收集堆栈,辅助分析

若某些卡慢方法,通过卡慢链路没法分析定位出问题,可以将指定方法推送到指定用户app上,收集线上用户指定卡慢方法再次出现时,对应的堆栈信息,用于辅助开发同学的分析定位。

卡慢实例

在主线程卡慢监控中,比较常见的案例是:主线程加载文件,底层DB读写,图片处理这些比较耗时的操作。我们优化的方案,通常是将这些耗时操作移到异步线程中进行处理。

以下是四个案例片断:

实例一:

主线程进行DB查询导致卡慢。

平均耗时视图:

myAPM后台,会先统计卡慢链路的次数,计算链路中每个节点的平均耗时。

卡慢链路最后的两组数值含义:(代码调用行号), 方法平均耗时。耗时单位为ms。

[1498814319655_1074_1498814319252.jpg]
[1498814319655_1074_1498814319252.jpg]

明细视图:

在明细视图中,我们会列出所有卡慢实例,以及用户基础环境信息。

卡慢链路最后的两组数值含义:(代码调用行号), 方法耗时。耗时单位为ms.

[1498814416623_4611_1498814416277.jpg]
[1498814416623_4611_1498814416277.jpg]

实例二:

主线程中加载dex文件引起的卡慢实例。

[1498814593717_7599_1498814593405.jpg]
[1498814593717_7599_1498814593405.jpg]

实例三:

在主线程中,加载本地xml文件导致卡慢。

[1498814624214_9137_1498814623748.jpg]
[1498814624214_9137_1498814623748.jpg]

实例四:

在主线程中,图片处理耗时比较大。

Process()方法消耗了1.3秒,setFacadeImage(),也另外消耗了1秒。

[1498814656695_4472_1498814656222.jpg]
[1498814656695_4472_1498814656222.jpg]

myAPM卡慢的优势与不足

优势:

  1. 监控粒度:myAPM卡慢监控的粒度为方法。
  2. 性能消耗:myAPM卡慢方案,采用卡慢业务链路上报,是一种轻量级的业务堆栈,避免直接使用原生堆栈。避免了打堆栈的性能消耗。(打印原生堆栈:1-3ms,打印业务链路:0.1-0.3ms)。
  3. 数据上报:采用了的一组链路ID。而非堆栈信息。上报量小,不用加解密过程。
  4. 代码依赖:卡慢逻辑与业务代码完全解耦,对开发者透明,零感知。只是在测试,发布前注入。

不足:

myAPM,也存在不足。由于采用注入方式,会使apk的包,稍微变大。

以qzone android apk注入进行全量业务代码时,其apk大小增长0.5M,增长率为2.79%。

方案:

1.若用户对apk大小比较敏感,可以采用部分注入分析。

2.可以配合myAPM的apk包大小分析方案,做apk瘦身分析。

myAPM新特性

app卡慢只是用于问题方法的性能优化。其实,对于一个产品,我们不但要关注及处理卡慢的问题,还需要关注app应用常规的性能状况与监控。因为,这个性能波动,不会像卡慢那么明显。但是在一次次新版本迭代中,可以会让总体性能变慢。

1、监听app启动性能

我们可以将卡慢监控范围进行定制缩小,提供个性化功能:只监听启动方法。

通过数据分析及比对,我们可以知道:

app每个版本的启动性能及变化;

接入的各个产品在启动性能上的差异,让各个产品间可以相互借鉴与提升。

2、核心链路分析

无论是产品,开发,测试与运维,都会想知道:

一个APP中,哪些代码是属于核心链路?

这些核心链路的性能怎样?

每个新版本中,这些核心链路的性能是否受到明显的损耗?

我们可以继续将卡慢上报范围扩大,上报全量方法。通过数据分析及筛选,我们可以挖掘出核心链路及其性能数据;

3、延时加载

通过链路特性分析,我们也可以抽取出调用次数很少,非主场景调用的代码。对于这些代码,在app启动加载时,我们可以使用延时加载。从而提升APP的启动效率。

对于以上myAPM常规性能分析,我们将在后续做单独的介绍。

最后

myAPM,是我们结合部门实际需求和APM理念,在移动端性能管理的一个新探索,新实践。不仅面向性能问题的定位,也应用于日常的app性能运营分析。

简单分享myAPM在移动性能管理方面的一点思考及应用,希望大家打造好自己移动端的性能小船,关键时刻,不会说翻就翻。共勉!

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

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

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

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

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 引言
  • myAPM是什么
  • myAPM可以做什么
  • Apk大小分析
  • App卡慢分析
    • 工作原理
      • 卡慢分析全流程
        • 卡慢实例
          • myAPM卡慢的优势与不足
          • myAPM新特性
          • 最后
          相关产品与服务
          图片处理
          图片处理(Image Processing,IP)是由腾讯云数据万象提供的丰富的图片处理服务,广泛应用于腾讯内部各产品。支持对腾讯云对象存储 COS 或第三方源的图片进行处理,提供基础处理能力(图片裁剪、转格式、缩放、打水印等)、图片瘦身能力(Guetzli 压缩、AVIF 转码压缩)、盲水印版权保护能力,同时支持先进的图像 AI 功能(图像增强、图像标签、图像评分、图像修复、商品抠图等),满足多种业务场景下的图片处理需求。
          领券
          问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
          http://www.vxiaotou.com