前语

冷发动目标是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烘托进程的目的。

c. 结构webview

即new Webview()

1.2 使命分配

为了最大程度缩短主线程耗时，咱们的使命安排如下：

• a. provider预加载，能够异步履行，且没有任何前置依靠，因而放在Application阶段最早的时刻点异步履行即可。

• b. 初始化webview烘托进程，有必要在主线程，因而放到主页首帧完毕之后。

• c. 结构webview，有必要在主线程，在第二步完成时post到主线程履行。这样能够保证和第二步不在同一个音讯中，下降ANR的几率。

1.3 小结

尽管咱们现已将webview初始化拆分为了三个部分，可是耗时占比最高的第二步在低端机或许极端状况仍是或许触达ANR的阈值，因而咱们做了一些约束，例如当时设备会计算并记载webview完好初始化的耗时，仅当耗时低于装备下发的阈值时，敞开上述的分段履行优化。

App假如是经过推送、投放等渠道打开，一般打开的页面大约率是H5营销页，因而这类场景不适用于上述的分段加载，所以需求hook主线程的messageQueue，解析出发动页面的intent信息，再做判别。

受限于开屏广告功用，咱们现在只能对无开屏广告的发动场景敞开此优化，后续将方案运用广告倒计时的间隙履行步骤2，来掩盖有开屏广告的场景。

2.ARouter优化

在当下组件化流行的年代，路由组件现已几乎是一切大型安卓App必备的根底组件，现在得物运用的是开源的ARouter结构。

ARouter 结构的规划是它默许会将注解中注册path途径中第一个路由层级 (例如 “/trade/homePage”中的trade)作为该路由信息所的Group, 相同Group途径的路由信息会合并到终究生成的同一个类 的注册函数中进行同步注册。在大型项目中，关于杂乱事务线同一个Group下或许包括上百个注册信息，注册逻辑履行进程耗时较长，以得物为例，路由最多的事务线在初始化路由上的耗时现已来到了150 ms。

路由的注册逻辑自身是懒加载的，即对应Group之下的首个路由组件被调用时会触发路由注册操作。然而ARouter经过SPI（服务发现）机制来协助事务组件对外暴露一些接口，这样不需求依靠事务组件就能够调用一些事务层的视线，在开发这些服务时，开发者一般会习惯性的依照其所属的组件为其设置路由path，这使得初次结构这些服务的时分也会触发同一个Group下的路由加载。

而在Application阶段必定需求用到事务模块的服务中的一些接口，这就会提早触发路由注册操作，尽管这一操作能够在异步线程履行，可是Application阶段的绝大部分作业都需求访问这些服务，所以当这些服务在初次结构的耗时增大时，整体的发动耗时势必会随之增加。

2.1 ARouter Service路由别离

ARouter选用SPI规划的原意是为了解耦，Service的效果也应该仅仅供给接口，所以应当新增一个空完成的Service专门用于触发路由加载，而原先的Service则需求替换一个Group，后续只用于供给接口，如此一来Application阶段的其他使命就不需求等候路由加载使命的完成。

2.2 ARouter支持并发装载路由

咱们在完成了路由别离之后，发现现有的热门路由装载耗时总和是大于Application耗时，而为了保证在进入闪屏页之前完成对路由的加载，主线程不得不sleep等候路由装载完毕。

剖析可知ARouter的路由装载办法加了类锁，由于他需求将路由装载到库房类中的map，这些map是线程不安全的HashMap，相当于一切的路由装载操作其实都是在串行履行，而且存在锁竞赛的状况，终究导致耗时累加大于Application耗时。

剖析trace可知耗时首要来自频频调用装载路由的loadInto操作，再剖析这里锁的效果，可知加类锁是首要是为了保证对库房WareHouse中map操作的线程安全。

因而咱们能够将类锁降级对GroupMeta这个class目标加锁(这个class是ARouter apt生成的类，对应apk中的ARouter$Provider$xxx类),来保证路由装载进程中的线程安全，至于在此之前对map操作的线程安全问题，则完全能够经过将这些map替换为concurrentHashMap处理，在极端并发状况下会有一些线程安全问题，也能够依照图中增加判空来处理。

至此，咱们就完成了路由的并发装载，随后咱们根据木桶效应对要预载的service进行合理分组，再放到协程中并发履行，保证终究整体耗时最短。

3.锁优化

Application阶段履行的使命多为根底SDK的初始化，其运转的逻辑一般相对独立，可是SDK之间会有依靠联系（例如埋点库会依靠于网络库），且大部分都会触及读文件，加载so库等操作，Application阶段为了紧缩主线程的耗时，会尽或许地将耗时操作放到子线程中并发运转，充分运用CPU时刻片，可是这也不可防止的会导致一些锁竞赛的问题。

3.1 Load so锁

System.loadLibrary()办法用于加载当时apk中的so库，这个办法对Runtime目标加了锁，相当于一个类锁。

根底SDK在规划上一般会将load so的操作写到类的静态代码块中，保证在SDK初始化代码履行之前就预备好了so库。假如这个根底SDK恰巧是网络库这类根底库，会被许多其他SDK调用，就会呈现多个线程一起竞赛这个锁的状况。那么在最坏的状况下，此刻IO资源严重，读so文件变慢，而且主线程是锁等候行列中最后一个，那么发动耗时将远超预期。

为此，咱们需求将loadSo的操作统一管控并收敛到一个线程中履行，强制他们以串行的办法运转，这样就能够防止以上状况的呈现。值得一提的是，前面webview的provider预加载的进程中也会加载webview.apk中的so文件，因而需求保证preloadProvider的操作也放到这个线程。

so的加载操作会触发native层的JNI_onload办法，一些so或许会在其中履行一些初始化作业，因而咱们不能直接调用System.loadLibrary()办法来进行so加载，不然或许会重复初始化呈现问题。

咱们终究选用了类加载的办法，即将这些so加载的代码悉数挪到相关类的静态代码块中，然后再去触发这些类的加载即可，运用类加载的机制保证这些so的加载操作不会重复履行，一起这些类加载的次序也要依照这些so运用的次序来编列。

除此之外，so的加载使命不建议和其他需求IO资源的使命并发履行，在得物App中实测这两种状况下该使命的耗时相差巨大。

4.发动结构优化

现在常见的发动结构规划是将发动阶段的作业分配到一组使命节点中，再由这些使命节点的依靠联系结构出一个有向无环图，可是跟着事务迭代，一些前史留传的使命依靠现已没有存在的必要，可是他会连累整体的发动速度。

发动阶段大部分作业都是根底SDK的初始化，他们之间往往有着杂乱的依靠联系，而咱们在做发动优化时为了紧缩主线程的耗时，一般都会找出主线程的耗时使命并丢到子线程去履行，可是在依靠联系杂乱的Application阶段，假如仅仅将其丢到异步履行未必能有预期的收益。

咱们在做完webview优化之后发现发动耗时并没有和预期一样直接减少了webview初始化的耗时，而是只要预期的一半左右，经剖析发现咱们的主线程使命依靠着子线程的使命，所以当子线程使命没有履行完时，主线程会sleep等候。

而且webview之所以放在这个时刻点初始化不是由于有依靠约束这它，而是由于这段时刻主线程正好有一段比较长的sleep时刻能够运用起来，可是异步的使命作业量是远大于主线程的，即便是七个子线程并发在跑，其耗时也是大于主线程的使命。

因而想进一步扩大收益，就得对发动结构中的使命依靠联系做优化。

以上第一张图为优化之前得物App发动阶段使命的有向无环图，红框标明该使命在主线程履行。咱们着重重视堵塞主线程使命履行的使命。

能够调查到主线程使命的依靠链路上存在几个出口和进口特别多的使命，出口多标明这类使命一般是十分重要的根底库（例如图中的网络库），而进口多标明这个使命的前置依靠太多，他开始履行的时刻点动摇较大。这两点结合起来就说明这个使命履行完毕的时刻点很不稳定，而且将直接影响到后续主线程的使命。

这类使命优化的思路首要是：

• 拆解使命自身，将能够提早履行或许延后履行的操作分出去，可是分出去之前要考虑到对应的时刻段还有没有时刻片余量，或许会不会加重IO资源竞赛的状况呈现；

• 优化该使命的前置使命，让该使命履行完毕的时刻点尽或许提早，就能够下降后续使命等候该使命的耗时；

• 移除非必要的依靠联系，例如埋点库初始化仅仅需求注册一个监听器到网络库，并非建议网络恳求。（推荐）

能够看到咱们在优化之后的第二张有向无环图里，使命的依靠层级显着变少，进口和出口特别多的使命也都基本不再呈现。

比照优化前后的trace，也能够看到子线程的使命并发度显着提高，可是使命并发度并不是越高越好，在时刻片自身就缺乏的低端机上并发度越高体现或许会越差，由于更简单出锁竞赛，IO等候之类的问题，因而要适当留下必定空地，并在中低端机上进行充分的功用测验之后再上线，或许针对高中低端机器运用不同的使命编列。

三、主页优化

1.通用布局耗时优化

系统解析布局是经过inflate办法读取布局xml文件并解析构建出view树，这一进程触及IO操作，很简单受到设备状况影响，因而咱们能够在编译期经过apt解析布局文件生成对应的view构建类。然后在运转时提早异步履行这些类的办法来构建并组装好view树，这样能够直接优化掉页面inflate的耗时。

2.音讯调度优化

在发动阶段咱们一般会注册一些ActivityLifecycleListener来监听页面生命周期，或许是往主线程post了一些延时使命，假如这些使命中有耗时操作，将会影响到发动速度，因而能够经过hook主线程的音讯行列，将页面生命周期回调和页面制作相关的msg移动到音讯行列的队头，这样就能够加快主页首帧内容展现的速度。

详情可期待本系列后续内容。

四、稳定性

功用优化对App只能算作锦上添花，稳定性才是生命红线，而发动优化改造的又都是履行时机十分早的Application阶段，稳定性危险程度十分高，因而务必要在预备好溃散防护的前提下做优化，即便有不可防止的稳定性问题，也要将负面影响降到最低。

1.溃散防护

由于发动阶段履行的使命都是重要的根底库初始化，因而产生溃散时将反常识别并吃掉的含义不大，由于大约率会导致后续溃散或功用反常，因而咱们首要的防护作业都是产生问题之后的止血。

装备中心SDK的规划一般都是从本地文件中读出缓存的装备运用，待接口恳求成功后再刷新。所以假如当发动阶段命中了装备之后产生了crash，是拉不到新装备的。这种状况下只能清空App缓存或许卸载重装，会形成十分严重的用户流失。

对一切改动点加上try-catch保护，捕捉到反常之后上报埋点并往MMKV中写入溃散符号位，这样该设备在当时版本下都不会再敞开发动优化相关的改变，随后再抛出原反常让他溃散掉。至于native crash则是在Crash监控的native溃散回调里履行同样操作即可。

Java Crash咱们能够经过注册unCaughtExceptionHandler来捕捉到，可是native crash则需求借助crash监控SDK来捕捉，可是crash监控未必能在发动最早的时刻点初始化，例如Webview的Provider的预加载，以及so库的预加载都是早于crash监控，而这些操作都触及native层的代码。

为了躲避这种场景下的溃散危险，咱们能够在Application的起始点埋入MMKV符号位，在完毕点改为另一个状况，这样一些履行时刻早于装备中心的代码就能够经过获取这个符号位来判别上一次运转是否正常，假如前次发动产生了一些不知道的溃散（例如产生在crash监控初始化之前的native溃散），那么经过这个符号位就能够及时关闭掉发动优化的改变。

结合溃散之后自动重启的操作，在用户视角其实是调查不到闪退的，仅仅会感觉到发动的耗时约是平常的1-2倍。

线上的技改改变一般都会装备采样率，结合随机数完成逐渐放量，可是装备下发SDK的规划一般都是默许取前次的本地缓存，在产生线上溃散等故障时，尽管及时回滚了装备，可是缓存的规划会导致用户还会由于缓存遭受至少一次的溃散。

为此，咱们能够为每一个开关装备加一个配套的过期时刻戳，约束当时放量的开关只在该时刻戳之前收效，这样在遇到线上溃散等故障时保证能够及时止血，而且时刻戳的规划也能够防止线上装备收效的滞后性导致的crash。

用户视角下，增加装备有效期前后比照：

五、总结

至此，咱们现已对安卓App中比较通用的冷发动耗时事例做了剖析，可是发动优化最大的痛点往往仍是App自身的事务代码，应当结合事务需求合理的进行使命分配，假如一味的靠预加载，延迟加载和异步加载是不能从根本上处理耗时问题的，由于耗时并没有消失仅仅转移，随之而来的或许是低端机发动劣化或功用反常。

做功用优化不仅需求站在用户的视角，还要有全局观，假如由于发动目标算是主页首帧完毕就把耗时使命都丢到首帧之后，势必会形成用户后续的体会有卡顿乃至ANR。所以在拆分使命时不仅需求考虑是否会和与其并发的使命竞赛资源，还需求考虑发动各个阶段以及发动后一段时刻内的功用稳定性和功用是否会受之影响，而且需求在高中低端机器上都验证下，至少要保证都没有劣化的体现。

1.防劣化

发动优化绝不是一次性的作业，它需求长时刻的保护和打磨，根底库的一次技改或许就会让目标一夜回到解放前，因而防劣化有必要要尽早落地。

经过在要害点增加埋点，能够做到在发现线上目标劣化时敏捷定位到劣化代码大约位置（例如xxActivity的onCreate）并告警，这样不仅能够协助研发敏捷定位问题，还能够防止线上特定场景目标劣化线下无法复现的状况，由于单次发动的耗时动摇范围最高能有20%，假如直接去抓trace剖析或许连劣化的大约范围都难以定位。

例如两次发动做trace比照时，其中一次由于遇到IO堵塞导致某次读文件的操作都显着变慢，而另一次IO正常，这就会误导开发者去剖析这些正常的代码，而实践导致劣化的代码或许由于动摇正好被掩盖。

2.展望

关于经过点击图标发动的普通场景，默许会在Application履行完好的初始化作业，可是一些层级比较深的功用，例如客服中心，修改收货地址这类，即运用户以最快速度直接进入这些页面，也是需求至少1s以上的操作时刻，所以这些功用相关的初始化作业也是能够推迟到Application之后的，乃至改为懒加载，视详细功用的重要性而定。

经过投放，push来做召回/拉新的发动场景一般占比较少，可是其事务价值要远大于普通场景。由于现在发动耗时首要来源于webview初始化以及一些主页预载相关的使命，假如发动落地页并不需求一切根底库（例如H5页面），那么这些咱们就能够将它不需求的使命通通延迟加载，这样发动速度能够得到大幅度增加，做到真正含义上的秒开。

*文/Jordas

本文属得物技术原创，更多精彩文章请看：得物技术官网

未经得物技术许可禁止转载，不然依法追究法律责任！