得物App安卓冷启动优化-Application篇

前言

冷启动指标是App体验中相当重要的指标，在电商App中更是对用户的留存意愿有着举足轻重的影响。通常是指App进程启动到首页首帧出现的耗时，但是在用户体验的角度来看，应当是从用户点击App图标，到首页内容完全展示结束。

将启动阶段工作分配为任务并构造出有向无环图的设计已经是现阶段组件化App的启动框架标配，但是受限于移动端的性能瓶颈，高并发度的设计使用不当往往会让锁竞争、磁盘IO阻塞等耗时问题频繁出现。如何百尺竿头更进一步，在启动阶段有限的时间里，将有限的资源最大化利用，在保障业务功能稳定的前提下尽可能压缩主线程耗时，是本文将要探讨的主题。

本文将介绍我们是如何通过对启动阶段的系统资源做统一管控，按需分配和错峰加载等手段将得物App的线上启动指标降低10%，线下指标降低34%，并在同类型的电商App中提升至Top3。

一、指标选择

传统的性能监控指标，通常是以Application的attachBaseContext回调作为起点，首页decorView.postDraw任务执行作为结束时间点，但是这样并不能统计到dex加载以及contentProvider初始化的耗时。

因此为了更贴近用户真实体验，在启动速度监控指标的基础上，我们添加了一个线下的用户体感指标，通过对录屏文件逐帧分析，找到App图标点击动画开始播放（图标变暗）作为起始帧，首页内容出现的第一帧作为结束帧，计算出结果作为启动耗时。

例：启动过程为03:00 - 03:88，故启动耗时为880ms。

二、Application优化

App在不同的业务场景下可能会落到不同的首页（社区/交易/H5），但是Application运行的流程基本是固定的，且很少变更，因此Application优化是我们的首要选择。

得物App的启动框架任务在近几年已经先后做过多轮优化，常规的抓trace寻找耗时点并异步化已经不能带来明显的收益，得从锁竞争，CPU利用率的角度去挖掘优化点，这类优化可能短期收益不会特别明显，但从长远来看能够提前规避很多劣化问题。

1.WebView优化

App在首次调用webview的构造方法时会拉起系统对webview的初始化流程，一般会耗时200+ms，如此耗时的任务常规思路都是直接丢到子线程去执行，但是chrome内核中加入了非常多的线程检查，使得webview只能在构造它的线程中使用。

为了加速H5页面的启动，App通常会选择在Application阶段就初始化webview并缓存，但是webview的初始化涉及跨进程交互和读文件，因此CPU时间片，磁盘资源和binder线程池中任何一种不足都会导致其耗时膨胀，而Application阶段任务繁多，恰恰很容易出现以上资源短缺的情况。

因此我们将webview拆分成三个步骤，分散到启动的不同阶段来执行，这样可以降低因为竞争资源导致的耗时膨胀问题，同时还可以大幅度降低出现ANR的几率。

1.1 任务拆分

a. provider预加载

WebViewFactoryProvider是用于和webview渲染进程交互的接口类，webview初始化的第一步就是加载系统webview的apk文件，构建出classloader并反射创建了WebViewFactoryProvider的静态实例，这一操作并没有涉及线程检查，因此我们可以直接将其交给子线程执行。

b. 初始化webview渲染进程

这一步对应着chrome内核中的WebViewChromiumAwInit.ensureChromiumStartedLocked()方法，是webview初始化最耗时的部分,但是和第三步是连续执行的。走码分析发现WebViewFactoryProvider暴露给应用的接口中，getStatics这个方法会正好会触发ensureChromiumStartedLocked方法。

至此，我们就可以通过执行WebSettings.getDefaultUserAgent()来达到仅初始化webview渲染进程的目的。