大家好,我是《 Android 开发高手课》作者、前微信高级工程师张绍文。今天和大家分享的是 Android 应用启动优化的“秘籍”,在优化过程中你会遇到什么问题?该如何分析?又该如何解决?
用户如果想打开一个应用,就一定要经过“启动”这个步骤。启动时间的长短,不只是用户体验的问题,对于淘宝、京东这些应用来说,会直接影响留存和转化等核心数据。对研发人员来说,启动速度是我们的“门面”,它清清楚楚可以被所有人看到,我们都希望自己应用的启动速度可以秒杀所有竞争对手。
那启动过程究竟会出现哪些问题?我们应该怎么去优化和监控应用的启动速度呢?是否还有方法可以做进一步优化吗?怎么证明你秒杀所有的竞品?如何在线上衡量启动优化的效果?怎么保障和监控启动速度是否变慢?
今儿和大家分享我对“启动优化”的理解,对应用性能优化的体会。
业务优化:应用层。开始的时候通过业务代码的优化,我很轻松地就把启动速度优化了 50%。但正如《大停滞》所说的,这只是摘完了“所有低垂的果实”。之后很快就陷入了停滞,就像冲进了一条漆黑的隧道,不知道还可以做哪些事情,很多现象从表面也不知道如何解释:I/O 有时候为什么那么慢?线程的优化应该怎么样去衡量?
Android Framework:系统框架层。为了冲出这条漆黑的隧道,我去研究了 Android 的内存管理、文件系统、渲染框架等各个模块;学习如何去优化和监控 I/O、线程、卡顿以及帧率,建立了各种各样的性能监控框架。为什么我对监控如此重视?这是因为对于大厂来说,“挖坑容易,填坑难”,几十上百人协同开发一个项目,我们不希望只是解决具体的某一个问题,而是要彻底解决某一类问题。但想要实现一个监控框架,前提是需要对 Framework 有非常充分地理解和研究。
Linux Kernel:内核层。再深入下去,我还需要利用 Linux 的一些机制,例如 ftrace、Perf、JVMTI 等。在做 I/O 的类重排、文件重排评估的时候,还需要自己去修改内核的参数,去刷 ROM。
Hardware:硬件层。高端机和低端机的硬件差异究竟在哪里?eMMC 闪存和 UFS 闪存的区别是什么?除了更加了解硬件的性能和特性,到了这个阶段我还希望可以向手机厂商和硬件厂商要性能。例如高通的CPU Boost、微信的 Hardcoder、OPPO 的开放平台等。
启动优化的过程,就像是一个知识爬坡的过程。我们不停地尝试往底层深入,希望去摘更高的果实。同样专栏也是希望帮你补充“爬坡”所需的知识,让你一步步进阶成为高手,并可以用高手的思维去寻找、解决开发中遇到的复杂问题。
还是回到启动优化,既然里面涉及那么多问题,我们该如何具体优化呢?
启动过程分析
在真正动手开始优化之前,我们应该先搞清楚从用户点击图标开始,整个启动过程经过哪几个关键阶段,又会给用户带来哪些体验问题。
我以微信为例,用户从桌面点击图标开始,会经过 4 个关键阶段。
T1 预览窗口显示。系统在拉起微信进程之前,会先根据微信的 Theme 属性创建预览窗口。当然如果我们禁用预览窗口或者将预览窗口指定为透明,用户在这段时间依然看到的是桌面。
T2 闪屏显示。在微信进程和闪屏窗口页面创建完毕,并且完成一系列 inflate view、onmeasure、onlayout 等准备工作后,用户终于可以看到熟悉的“小地球”。
T3 主页显示。在完成主窗口创建和页面显示的准备工作后,用户可以看到微信的主界面。
T4 界面可操作。在启动完成后,微信会有比较多的工作需要继续执行,例如聊天和朋友圈界面的预加载、小程序框架和进程的准备等。在这些工作完成后,用户才可以真正开始愉快地聊天。
启动问题分析
从启动流程的 4 个关键阶段,我们可以推测出用户启动过程会遇到的 3 个问题。这 3 个问题其实也是大多数应用在启动时可能会遇到的。
问题 1:点击图标很久都不响应
如果我们禁用了预览窗口或者指定了透明的皮肤,那用户点击了图标之后,需要 T2 时间才能真正看到应用闪屏。对于用户体验来说,点击了图标,过了几秒还是停留在桌面,看起来就像没有点击成功,这在中低端机中更加明显。
问题 2:首页显示太慢
现在应用启动流程越来越复杂,闪屏广告、热修复框架、插件化框架、大前端框架,所有准备工作都需要集中在启动阶段完成。上面说的 T3 首页显示时间对于中低端机来说简直就是噩梦,经常会达到十几秒的时间。
问题 3:首页显示后无法操作
既然首页显示那么慢,那我能不能把尽量多的工作都通过异步化延后执行呢?很多应用的确就是这么做的,但这会造成两种后果:要么首页会出现白屏,要么首页出来后用户根本无法操作。
很多应用把启动结束时间的统计放到首页刚出现的时候,这对用户是不负责任的。看到一个首页,但是停住十几秒都不能滑动,这对用户来说完全没有意义。启动优化不能过于 KPI 化,要从用户的真实体验出发,要着眼从点击图标到用户可操作的整个过程。
启动优化
启动速度优化的方法和卡顿优化基本相同,不过因为启动实在是太重要了,我们会更加“精打细算”。我们希望启动期间加载的每个功能和业务都是必须的,它们的实现都是经过“千锤百炼”的,特别是在中低端机上面的表现。
“工欲善其事必先利其器”,我们需要先找到一款适合做启动优化分析的工具。
你可以先回忆一下“卡顿优化”提到的几种工具。Traceview 性能损耗太大,得出的结果并不真实;Nanoscope 非常真实,不过暂时只支持 Nexus 6P 和 x86 模拟器,无法针对中低端机做测试;Simpleperf 的火焰图并不适合做启动流程分析;systrace 可以很方便地追踪关键系统调用的耗时情况,但是不支持应用程序代码的耗时分析。
综合来看,在卡顿优化中提到“systrace + 函数插桩”似乎是比较理想的方案,而且它还可以看到系统的一些关键事件,例如 GC、System Server、CPU 调度等。
在拿到整个启动流程的全景图之后,我们可以清楚地看到这段时间内系统、应用各个进程和线程的运行情况,现在我们要开始真正开始“干活”了。
具体的优化方式,我把它们分为闪屏优化、业务梳理、业务优化、线程优化、GC 优化和系统调用优化。
启动优化的进阶方法
当然高手可不是这么容易当的,仅仅完成这些就美滋滋地向老大汇报工作成果:“启动速度提升 30%,秒杀所有竞品好几条街”,启动优化工作就结束了吗?“还有什么方法可以做进一步优化吗?怎么证明你秒杀所有的竞品?如何在线上衡量启动优化的效果?怎么保障和监控启动速度是否变慢?”
除了上面这些常规的优化方法,我还有一些与业务无关的“压箱底”方法可以帮助加快应用的启动速度。当然有些方法会用到一些黑科技,它就像一把双刃剑,需要你做深入的评估和测试。
I/O 优化
数据重排
类的加载
黑科技
未来移动开发无论是变成大前端还是 Flutter 的世界,性能、效率和架构都是永恒不变的主线。今天我们在 Android 开发打下的坚实基础,未来也会帮助我们更好地理解和深入新的开发模式或者新的系统。崩溃、内存、存储、渲染、I/O、网络…这些知识以及它们背后的底层原理依然还是非常重要的。
内容选自极客时间《 Android 开发高手课》专栏
评论