Android启动速度优化-总会遇到的不痛不痒的坎~

#Android启动速度优化-总会遇到的不痛不痒的坎~

###1、直奔主题 来自用户、测试、产品、包括开发人员反馈：

app启动很慢，欢迎页停留过久或者启动黑屏等等，但有时候又不会。

起初一直不过重视，后来随着产品迭代更新，发现启动速度慢的问题愈来愈明显，已经影响到用户体验，甚至为了加快启动速度而要发一个升级包。因而决定优化一下启动速度，研究以后发现，仍是有不少能够拿出来分享的；

###2、基础知识

####冷启动： 当后台不存在该应用的任何进程或者服务时，用户点击icon图标启动，咱们称之为冷启动。 ####热启动 当后台存在该应用的进程或者服务时，用户点击icon图标启动，咱们称之为热启动。 通常是用户按了home键回到桌面，或者返回键没有杀进程，或者app自己作了进程重启的机制。 ####启动组成时间 咱们主要优化冷启动时间，只要冷启动时间优化了，热启动其实也跟着优化了。 冷启动时间分布以下： application启动时间+欢迎页停留时间 按用户体验的启动时间应该是： application启动时间+欢迎页停留时间+进入主页后显示主题的话时间；

###3、优化点

###一、Application的启动优化-兵家必争之地；

Application启动会通过attachBaseContext-->onCreate;

这两个方法不执行完是不会出现lanucher页面的；因此用户反馈点击图片后，要过一会才出现欢迎页的缘由如下几个：

一、这两个方法太过费时致使的。
二、application的Theme被设置会透明的（系统通常默认有个白色或者黑色的）
三、对启动页不要作自定义动画，效果没有原声的好，会有一点点影响。

####attachBaseContext优化

这个方法在没有MultiDex的app中或者没有特殊业务的app中通常是不用重写的，可是因为业务须要，咱们的app须要集成multidex，致使咱们须要在此方法里进行MultiDex.install操做,这个操做实际上是耗时的，没办法优化，可是也不能让用户傻等. #####（1）优化初次启动 咱们知道5.0如下初次安装启动须要进行dexopt的过程，这个过程是很是耗时的，在一些比较低端的机子上甚至能到达20秒，并且只能在主UI线程进行，若是咱们直接执行install的话，颇有可能出现ANR,黑屏，等各类很是很差的体验，怎么办呢，咱们能够绕过咱们的主进程: 咱们开启一个新的进程用于install操做，并弹出一个欢迎页；而后再咱们的主线程一直检测是否安装完成，超时时间设置为30秒；完成以后弹出主进程的欢迎页面（注意：为了让用户无感知，这两个页面必须如出一辙，且中间不能用过渡动画）。通过实践：基本上这套方案能够适用全部目前兼容的机型。

#####（2）Application Theme建议设置为透明的（处于用户体验的考虑）

####onCreate优化

每次application启动或者重启的时候都会触发onCreate；若是这个方法耗时超过500ms的话，你能够很明显的感觉到点击icon以后，欢迎页不会马上展现出来。

然而不幸的是，不少第三方的组件，如友盟，百川等等都须要在此进行初始化，缘由是防止进程被回收以后他们还有机会进行从新初始化而不影响业务。

缘由上咱们能够接受，但一旦初始化耗费时间多少彻底没法控制，彻底看第三方“良心”了，但即便在 咱们既没法改变第三方初始化速度慢的问题，也不能将其从application移除的状况下，咱们依然要优化启动速度，由于用户体验是在过重要。

####迎难而上吧！

优化思路：最大的优化思路就是onCreate什么都不执行，先让欢迎页弹窗出来；这个想法初步很简单，也很好实现，然而存在几个问题：

（1）进程被回收重启后，如何从新初始化？

（2）通知栏推送后，进入到目的页面，如何防止由于没初始化致使的闪退或者功能异常？

（3）application oncreate什么都不作，那初始化放在哪里作呢；

只要这两个问题解决了，基本上application的优化就算完成了，怎么解决呢，咱们采用了下面的办法 咱们在application只干了一件事，并且几乎不费时，他就是：监听页面的生命周期: #####registerActivityLifecycleCallbacks 这个方法可让咱们监听全部页面的生命周期，包括启动，可见，销毁等等，而启动的时候android自己带了一个参数 public void onActivityCreated(Activity activity, Bundle savedInstanceState)；中的Bundle，若是Bundle不为空，说明是回收回来的，咱们能够在这里进行从新初始化，而不影响其余功能；所以（1）（2）问题迎刃而解； 关于（3）的问题是正常流程问题，若是放在欢迎页初始化，是不妥的，并非全部的入口都走欢迎页； 因此咱们在application接收了一个初始化的事件，只要收到这个事件，就能够进行初始化，初始化完了以后，再发出初始化完成的通知； （其实这一步是为了优化欢迎页作的准备，继续往下看。）

####application经过以上几步优化以后，就只剩下5.0如下dexopt和multidex.install消耗的时间优化的，要作到不执行Multi.install多个dex，只能本身动态实现dex的加载，也就是插件化，还有一段很长的路要走，继续往下说。

###二、启动页启动优化-用户可见的第一感知

application优化完了之后，就会执行启动页的onCreate,咱们发现oncreate一旦耗时，也会致使启动页有一顺气的卡顿，精益求精，咱们把启动页的启动逻辑延迟初始化并通知application进行初始化，而后等待application初始化完成的事件以后，继续往下走，知道进入主页； 启动也的优化逻辑比较简单，只是纯业务的上的调整。

###三、主页优化

主要优化onCreate便可。把能够放线程初始化的都放到线程里去。

通过以上几步优化以后，咱们发现启动速度有了很是明显的提示，其实大部分的时候都花在了业务的整理和application启动的优化上边，比较容易出bug的地方是咱们至关于改变了应该在appliation oncreate初始化方式，因为有些组件初始化是异步的，仍是可能出现初始化未完成就被使用的状况，这须要业务上进行相关的处理。贴一组优化后的数据，效果很理想。

####优化前：

application正常启动 耗时：1299	
application延迟启动 耗时：4081
Welcome 启动 耗时：289
Tab启动 耗时：1143

###优化后： D/耗时统计: meiyou : application onCreate 耗时:3 D/耗时统计: meiyou : application initNeedAtApplication 耗时:190 D/耗时统计: meiyou : welcome oncreate耗时:89 D/WelcomeController: meiyou : welcome handleGo 耗时:324 D/耗时统计: meiyou : welcome initLogic 耗时:324 D/耗时统计: meiyou : MainActivity onCreate 耗时:136 D/耗时统计: meiyou : HomeFragment onCreate 耗时:72

总的来讲，对于一个比较大型的app的启动逻辑仍是蛮复杂的，有必要的话都须要整理并优化一下，欢迎你们吐槽，共勉。

Done

QQ:452825089

mail:452825089@qq.com

wechat:ice3897315

blog:http://iceAnson.github.io