1、前言
App的启动速度是用户对于App的第一印象，如果App启动的很慢那非常有可能导致用户的流失，因此对于App的启动速度可以说是我们必须要保障的一道关卡！接下来我给大家介绍一下App启动速度优化的常用方案。
2、衡量启动时间
要想优化启动速度首先我们需要知道怎么精确获取App的启动速度，只有先拿到了精确的启动速度才好评估时间到底有多久以及后续的优化效果。对启动速度优化有经验的同学都知道使用 adb shell am start -W 首屏Activity 这个命令可以拿到App的启动速度，一般App做启动速度统计都是这么做的。
那这么做真的可以吗？
答案肯定是No，首先这种adb 命令的方式只能在线下才能使用，这也就意味着如果使用了这种衡量方式，我们在线上根本无从知道用户在实际情况下到底慢还是不慢以及慢的程度，这其实是不可接受的，因为线上用户的实际优秀体验才是我们追求的目标。其次对于这个命令拿到的值，它只是到了Activity的第一帧而已，也就是并不能够代表用户实际看到我们App这个界面了。举个例子：当首页是一个列表的时候，列表的数据需要网络传输回来，那Activity的第一帧早就绘制了，但是用户看不到真实的数据，这样的用户体验依然很糟糕。所以adb 这种方式拿到的启动时间并不能够真实的反映出来用户实际真正看到首页需要的时间。
总结一下这种常规方案的缺点：
- 只能在线下使用
- 不能准确的表现出用户实际的体验
因此更建议大家自己精确的埋点来统计启动时间，关于如何判断启动的结束以及优雅获取启动时间的方法欢迎查看《国内Top团队大牛带你玩转Android性能分析与优化》
3、实际优化
启东速度慢的话我们来进行优化，一般情况下必不可少的就是异步初始化优化，也就是使用异步的方式来分担主线程的工作达到加快启动速度的目的。这里也就涉及到了多线程的使用，实际上这是启动优化中非常重要的一种手段。
但是异步初始化优化就可以解决启动速度慢的所有问题吗？Naive！异步初始化虽然有效，但是我们来想想它可能遇到的问题：主线程中执行的任务如果需要异步初始化中执行的任务配合（也就是有依赖关系），这种情况下怎么处理？简单的说就是要保证异步初始化的某项任务一定要在主线程的某个时刻前执行完成，怎么办？如果你提前这个异步任务也只能保证这个异步任务提前开始而已，你无法保证在每个手机上这项任务一定会在主线程的某个时刻都提前执行完成！
再者：假设你在Application的onCreate中做了异步，但是一些异步的任务需要在onCreate执行完成之前就结束，因为Splash界面可能会直接使用到这些任务。这种情况该怎么处理呢？万一这种情况特别多，怎么处理起来更加优雅呢？
4、延迟初始化
做过启动优化的同学肯定都知道我们可以将部分不重要的任务挪到启动结束之后再去执行，讲道理这也是一种有效的减少启动速度的方法。 但是如果我延迟执行的任务总共需要1000ms才能全部执行完成，那岂不是启动完成之后主线程还要被卡顿1000ms，在这个过程中如果用户有滑动屏幕或者是点击事件等操作呢肯定是执行不了的，用户一定会感受到卡顿，也就是界面虽然打开了但是用户还是操作不了，体验也是非常的差！
这个方案很常见，但是如果用的不好的话很有可能会导致用户虽然看到了界面但是无法操作。因此需要一种特殊的机制来保障即便是使用了延迟初始化也不会影响用户的任何操作。
5、后记
关于App的启动速度优化我在这里提出来几个常见的优化误区，很多时候常规的优化方案如果使用不正确反而会起负面作用，因此需要有更先进的方案来指导我们的优化工作。关于文中所介绍的方案以及问题解决途径，欢迎查看《国内Top团队大牛带你玩转Android性能分析与优化》，让我们一起成为高级工程师吧！
随时随地看视频
