性能优化的方案不少，但能落地应用到项目中的却不多
前段时间学习布局优化时，总结了不少布局优化的方案，但最后却无法在项目中应用：【从入门到放弃】android布局优化深入解析
今天一如既往，不做标题党，给大家介绍一些可以实用的启动优化方案~
对于android APP来说，启动时间是用户的第一体验，如果启动时间过长，很可能会流失用户，所以启动优化也是我们做性能优化的一个重要方向
本文主要包括以下内容
1.启动优化有哪些优化方向？
2.如何精准测量启动时间？
3.有哪些实用的优化手段？
启动优化有哪些优化方向？
应用有三种启动状态，每种状态都会影响应用向用户显示所需的时间：冷启动、温启动或热启动。在冷启动中，应用从头开始启动。在另外两种状态中，系统需要将后台运行的应用带入前台。
本文所说的启动优化都是指冷启动优化
要优化应用以实现快速启动，了解系统和应用层面的情况以及它们在各个状态中的互动方式很有帮助。
冷启动
冷启动是指应用从头开始启动：系统进程在冷启动后才创建应用进程。
发生冷启动的情况包括应用自设备启动后或系统终止应用后首次启动。
这种启动给最大限度地减少启动时间带来了最大的挑战，因为系统和应用要做的工作比在另外两种启动状态中更多。
在冷启动开始时，系统有三个任务，它们是：
1.加载并启动应用。
2.在启动后立即显示应用的空白启动窗口。
3.创建应用进程。
系统一创建应用进程，应用进程就负责后续阶段：
1.创建应用对象。
2.启动主线程。
3.创建主Activity。
4.填充视图。
5.布局屏幕。
6.执行初始绘制。
一旦应用进程完成第一次绘制，系统进程就会换掉当前显示的后台窗口，替换为主Activity。此时，用户可以开始使用应用。
如上所示，Application与Activity的生命周期就是我们的优化方向
一般为Application onCreate方法与首个Activity加载耗时
如何测量启动时间？
最简单方法
通过查看logcat可以快速了解启动时间
在Android Studio Logcat中过滤关键字Displayed，可以看到对应的冷启动耗时日志。
命令测量
for i in `seq 1 10`do adb shell am force-stop com.xx.xx sleep 2 adb shell am start-activity -W -n 包名/activity名称 | grep "TotalTime" | cut -d ' ' -f 2done复制代码
有时候我们需要统计app的冷启动性能，单次结果往往不准确 还需要多次统计以后做平均值
如上，使用脚本启动10次首页Activity,可以比较准确的获取冷启动性能
命令测量方式线下使用方便，可以测试竞品
但是不能带到线上,不能精准控制测量时间
所以我们通常还需要手动埋点
埋点测量
埋点测量关键点在于合适的开始与结束时间
我们一般使用Application attachBaseContext作为开始时间
而启动结束时间则有很多选择
IdleHandler
IdleHandler在MessageQueue空闲时会回调,也就是所在线程任务已经执行完时，线程处于空闲状态时才会执行Idle列表中的任务。
正常情况下，当主线程程处于空闲状态时，可以认为冷启动已经完成，是一个比较不错的打点时机
但有个问题，如果UI线程的任务一直不执行完呢？如果有其他任务加入了MessageQueue但是页面已经可见了呢？
IdleHandler具有一定的不可控特性，读者可根据项目特性判断是否使用
onWindowFocusChanged
当Activity回调onWindowFocusChanged时，我们可以认为Activity已经可见了，所以可以在此时打点
不过onWindowFocusChanged方法只是Activity的首帧时间，是Activity首次进行绘制的时间，首帧时间和界面完整展示出来还有一段时间差，不能真正代表界面已经展现出来了。
但是onWindowFocusChanged方式与业务耦合少，侵入性低，使用起来比较方便
在我们的项目中回调时间与界面展示时间相差很少，可以作为一种可选方案，根据实际情况使用
onPrewDrawListener
如上面所说，正确的计算启动耗时的时机是要等真实的数据展示出来，比如在列表第一项的展示时再计算启动耗时。
我们可以在给列表的第一项添加onPreDrawListener监听，这种方式比较准确
不过这种方式与业务代码强相关，侵入性较大。读者也可根据实际情况使用
AOP测量方法耗时
我们的Application中初始化了很多第三方库，有时我们需要统计每个方法的耗时，确定是哪个方法比较耗时，如果一个一个添加是很麻烦的
这种时候就可以使用AOP面向切面编程
如果想了解详情，请参阅使用AOP测量方法耗时
TraceView与SystraceView使用
TraceView
TraceView可以跟踪App某段时间内所有调用过的方法，这是测量应用执行性能常用的方式之一.
通过它我们可以查出App启动时具体都调用了方法，都花了多长时间。
这个功能是Android系统提供的，我们可以通过在代码里手动调用android.os.Debug.startMethodTracing()和stopMethodTracing()方法来开始和结束Tracing，然后系统会把Tracing的结果保存到手机的.trace文件里。
此外，除了通过写代码来Trace，我们也有更方便的方式。例如也可以通过Android Studio Profiler里的Method Tracer来Trace。但是，针对App的冷启动，我们则通常会用Android系统自带的Am命令来跟踪，因为它能准确的在App启动的时候就开始Trace：
# 启动指定 Activity，并同时进行采样跟踪,-P在app进入idle状态时profiler结束adb shell am start -n com.xxx.android/com.xxx.android.app.ui.activity.MainActivity -P /data/local/tmp/xxx-startup.trace --sampling 1000# 拉取 .trace 文件到本机当前目录adb pull /data/local/tmp/xx-startup.trace .复制代码
如上所示：-P参数表示在app进入idle状态时会自动结束，这样就不必手动打点了
在启动结束后，通过adb pull拉取trace文件后，直接拖到android studio中打开就可以查找耗时方法了
更多关于TraceView定位启动优化问题的实例，读者可参阅:
知乎 Android 客户端启动优化 - Retrofit 代理
Systrace
TraceView虽然是找出耗时方法的利器，但是执行TraceView时的运行环境和用户最终运行的环境会有极大的差距，因为TraceView会严重拖慢App的执行速度。
即使使用采样跟踪，测量得到的结果和实际结果肯定还是有很大偏差，只能作为参考。
而且TraceView更偏向于追查应用的内因，对于运行环境等外因（锁、GC、资源匮乏等）的追查显得很无力。
所以，我们可以借助另一个Google官方极力推荐的工具 - 「Systrace」来跟踪 App 实际运行时的情况
运行app后，手动杀掉。然后cd到SDK目录下的platform-tools/systrace下，使用命令：
python systrace.py -t 10 -o /Users/xxx/trace.html -a com.xx.xxx复制代码
其中：-t10是指跟踪10秒，-o表示把文件输出到指定目录下，-a是指定应用包名。
输入完这行命令后，可以看到开始跟踪的提示。看到Starting tracing 后，手动打开我们的应用。
等到运行结束后打开输出的trace.html
除了以上外，我们也可以通过TraceCompact.beginSection来指定关注的时间段
更多关于Systrace使用的实例，读者可以参阅:
知乎 Android 客户端启动优化 - Retrofit 代理-Systrace
小结
1.TraceView可以用来定位具体耗时的方法
2.TraceView运行时开销严重，导致整体性能变慢，可能会带偏优化方向
3.Systrace开销小，可以直观反映Cpu使用率，便于查找运行环境等外因(锁,GC)等引起的问题
4.TraceView与Systrace都可以埋点，指定关心的区域
常规优化手段
1.Theme切换
Theme设置可以说是启动优化的一个必备手段了
启动Activity的windowBackground主题属性预先设置一个启动图片（layer-list实现），在启动后，在Activity的onCreate()方法中的super.onCreate()前再setTheme(R.style.AppTheme)。
优点
1.使用简单。
2.避免了启动白屏和点击启动图标不响应的情况。
缺点
治标不治本，表面上产生一种快的感觉。
2.异步方案
我们通常会在Application的onCreate中初始化很多任务，比如第三方库初始化，而且是串行的
这些初始化任务的耗时通常还不小，所以一个优化思路就是并行的初始化
这样就将初始化耗时从加法变成了求最大值
核心思路：子线程分担主线程任务，并行减少时间
常规异步方案的问题
1.代码不够优雅
假如我们有 100 个初始化任务，那我们就需要提交 100 次任务。
2.无法限制在onCreate中完成
有的第三方库的初始化任务需要在Application的onCreate方法中执行完成，虽然可以用CountDownLatch实现等待，但是还是有点繁琐。
3.无法实现存在依赖关系
有的初始化任务之间存在依赖关系，比如极光推送需要设备ID，而initDeviceId()这个方法也是一个初始化任务。
异步启动器方案
上面介绍了常规异步方案的几个问题，我们可以通过启动器来解决
启动器的核心思想是充分利用多核CPU，自动梳理任务顺序。
1.第一步是我们要对代码进行任务化，任务化是一个简称，比如把启动逻辑抽象成一个任务。
2.第二步是根据所有任务的依赖关系排序生成一个有向无环图，这个图是自动生成的，也就是对所有任务进行排序。
比如我们有个任务A和任务B，任务B执行前需要任务A执行完，这样才能拿到特定的数据，比如上面提到的initDeviceId。
3.第三步是多线程根据排序后的优先级依次执行，比如我们现在有三个任务A、B、C。假如任务B依赖于任务A，这时候生成的有向无环图就是ACB，A和C可以提前执行，B一定要排在A之后执行。
启动器的大致流程如上所示，我们下面介绍几种开源的启动器方案，供读者参考
JetPack App Startup
1.App Startup这个库提供了一个组件，可以在应用程序启动的时候初始化。
2.开发人员可以使用这个组件精简启动序列和显式地设置初始化的顺序。
3.我们不需要为每个组件定义单独的ContentProvider,App Startup允许您定义的所有组件化共享一个内容提供者。
这样可以极大地减少高应用程序的启动时间,但是App Startup只是支持将多个ContentProvider合并到一个ContentProvider中，并指定一定依赖顺序
它的推出的目的，是管理第三方库使用ContentProvider过多，导致启动速度变慢的问题
不支持异步与异步任务管理，所以并不符合我们的要求
阿里-alpha
Alpha是一个基于PERT图构建的Android异步启动框架，它简单，高效，功能完善。 在应用启动的时候，我们通常会有很多工作需要做，为了提高启动速度，我们会尽可能让这些工作并发进行。但这些工作之间可能存在前后依赖的关系，所以我们又需要想办法保证他们执行顺序的正确性。Alpha就是为此而设计的，使用者只需定义好自己的task，并描述它依赖的task，将它添加到Project中。框架会自动并发有序地执行这些task，并将执行的结果抛出来。 由于Android应用支持多进程，所以Alpha支持为不同进程配置不同的启动模式。
alpha已经基本满足我们的使用，不过它不支持任务是否需要等待，同时它的代码比较旧，感觉已经很久不维护了，所以最后决定使用AnchorTask框架
AnchorTask
AnchorTask与Alpha类似
1.支持多任务并发执行
2.支持任务间依赖与拓扑排序
3.支持任务监听与耗时统计
4.支持指定任务优先级
5.支持指定是否在主线程运行与是否等待
最主要的一点在于AnchorTask文档比较强大，从数据结构到拓扑排序，到设计到详细的说清楚了,有一系列文章，这也是我最后决定使用它的原因
简单使用如下，可以通过链式调用灵活的配置任务与依赖：
valproject = AnchorProject.Builder().setContext(context).setLogLevel(LogUtils.LogLevel.DEBUG) .setAnchorTaskCreator(ApplicationAnchorTaskCreator()) .addTask(TASK_NAME_ZERO) .addTask(TASK_NAME_ONE) .addTask(TASK_NAME_TWO) .addTask(TASK_NAME_THREE).afterTask( TASK_NAME_ZERO, TASK_NAME_ONE ) .addTask(TASK_NAME_FOUR).afterTask( TASK_NAME_ONE, TASK_NAME_TWO ) .addTask(TASK_NAME_FIVE).afterTask( TASK_NAME_THREE, TASK_NAME_FOUR ) .setThreadPoolExecutor(TaskExecutorManager.instance.cpuThreadPoolExecutor) .build()project.start().await()复制代码
延迟初始化方案
常规方案
有些任务我们需要延迟加载，常规方法是通过Handler.postDelayed方法发送一个延迟消息，比如延迟到 100 毫秒后执行。
常规方案的问题
这种方法有以下几个问题
1.时机不便控制,无法确定一个合适的延迟时间
2.代码不够优雅，维护成本高,如果有多个任务，需要添加多次
3.可能造成主线程卡顿，假如把任务延迟 200 毫秒后执行，而 200 后用户还在滑动列表，那还是会发生卡顿。
更优方案
核心思想：对延迟任务进行分批初始化利用IdleHandler在当前消息队列空闲时执行的特性，实现一个延迟启动器
IdleHandler在返回true时会继续监听，返回false结束监听
因此在任务全部完成后返回false即可,实现如下：
publicclassDelayInitDispatcher{privateQueue mDelayTasks =newLinkedList<>();privateMessageQueue.IdleHandler mIdleHandler =newMessageQueue.IdleHandler() {@OverridepublicbooleanqueueIdle(){if(mDelayTasks.size()>0){ Task task = mDelayTasks.poll();newDispatchRunnable(task).run(); }return!mDelayTasks.isEmpty(); } };publicDelayInitDispatcheraddTask(Task task){ mDelayTasks.add(task);returnthis; }publicvoidstart(){ Looper.myQueue().addIdleHandler(mIdleHandler); }}//调用DelayInitDispatcher delayInitDispatcher =newDelayInitDispatcher();delayInitDispatcher.addTask(newDelayInitTaskA()) .addTask(newDelayInitTaskB()) .start();复制代码
极致懒加载与提前加载
首页极致懒加载
我们的首页通常有多个tab,而当我们启动时，只需要初始化一个tab即可
我们通常会利用ViewPager来实现简单的懒加载，比如只有当Fragment可见时才去进行网络请示
这样有一定效果，但是View的inflate,measure,layout也需要一定时间
更加极致的懒加载方案如下：
1.首屏加载时，只往ViewPager中塞入默认要展示的tab，剩余的tab用空的占位Fragment代替
2.占位Fragment中只有一个空白的FrameLayout
3.当占位Fragment可见时，将真正要展示的Fragment添加到空白FrameLayout，进行真正的初始化
通过这种方案，可以做到在启动时，只inflate,measure,layout首页Fragment的View,其他Tab只有可见时才会填充
如果你的Layout比较复杂的话，通过这种方式可以较大的改善启动性能
布局预加载
官方提供了一个类，可以来进行异步的inflate，但是有两个缺点：
1.每次都要现场new一个出来
2.异步加载的view只能通过callback回调才能获得，使用不方便（死穴）
3.如果在Activity中进行初始化，通过callback回调时，并没有减少加载时间，仍然需要等待
由于以上问题，一个思考方向就是，能不能提前在子线程inflate布局，然后在Activity中通过id取出来
核心思想如下
1.初始化时在子线程中inflate布局，存储在缓存中
2.Activity初始化时，先从缓存结果里面拿View，拿到了view直接返回
3.没拿到view，但是子线程在inflate中，等待返回
4.如果还没开始inflate，由UI线程进行inflate
这种方案的优点:
可以大大减少View创建的时间，使用这种方案之后，获取View的时候基本在 10ms 之内的。
缺点
1.由于View是提前创建的，并且会存在在一个map，需要根据自己的业务场景将View从map中移除，不然会发生内存泄露
2.View如果缓存起来，记得在合适的时候重置view的状态，不然有时候会发生奇奇怪怪的现象。
总得来说，优缺点都很明显，读者可根据实际情况(主要是项目中inflate的时间长不长，改用提前加载后收益明不明显？),根据实际情况决定是否使用
具体实现可参阅：神奇的的预加载（预加载View，而不是data）
总结
本文主要总结了启动优化的方向，与精准测量启动时间的方式
重点讲解了几种可以实用的启动优化方案：
1.异步启动器加快初始化速度
2.延迟加载器减少卡顿，代码更加优雅
3.首页极致懒加载，减少首页inflate,measure,layout时间
4.布局预加载方案大大减少View创建时间，读者可根据实际情况使用
这些方案都比较实用，读者可以尝试在项目中应用，看看有多少提升~
