启动指定 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定位启动优化问题的实例，读者可参阅:
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
其中：-t 10是指跟踪10秒，-o 表示把文件输出到指定目录下，-a 是指定应用包名。
输入完这行命令后，可以看到开始跟踪的提示。看到 Starting tracing 后，手动打开我们的应用。
等到运行结束后打开输出的trace.html
除了以上外，我们也可以通过TraceCompact.beginSection来指定关注的时间段
更多关于Systrace使用的实例，读者可以参阅:
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文档比较强大，从数据结构到拓扑排序，到设计到详细的说清楚了,有一系列文章，这也是我最后决定使用它的原因
AnchorTask by 程序员徐公
简单使用如下，可以通过链式调用灵活的配置任务与依赖：
val project = 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即可,实现如下：
public class DelayInitDispatcher {
private Queue mDelayTasks = new LinkedList<>();
private MessageQueue.IdleHandler mIdleHandler = new MessageQueue.IdleHandler() {
@Override
public boolean queueIdle() {
if(mDelayTasks.size()>0){
Task task = mDelayTasks.poll();
new DispatchRunnable(task).run();
}
return !mDelayTasks.isEmpty();
}
};public DelayInitDispatcher addTask(Task task){
mDelayTasks.add(task);
return this;
}public void start(){
Looper.myQueue().addIdleHandler(mIdleHandler);
}}
//调用
DelayInitDispatcher delayInitDispatcher = new DelayInitDispatcher();
delayInitDispatcher.addTask(new DelayInitTaskA())
.addTask(new DelayInitTaskB())
.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取出来
