系统启动过程：
1）开机打开电源
2）BootLoader程序
3）Linux的 init.rc
- init进程
5）Zygote的JVM
6）SystemServer进程
Binder线程池
SystemServiceManager（AMS、WMS、PMS、CameraService等等被启动）
1）启动页白屏及黑屏解决？
2）启动太慢怎么解决？
3）怎么保证应用启动不卡顿？
4）App启动崩溃异常捕捉
5）统计启动时长,标准
App启动速度是用户的第一印象，本章会介绍精准度量启动速度的方式，启动优化的相关工具、常规优化手段等，同时我会介绍异步初始化以及延迟初始化的最优解，以最优雅、可维护性高的的方式获得闪电般的启动速度。...
一. App 启动优化介绍
App Startup time
冷启动：耗时最多、衡量标准。
启动App、加载空白Window、创建进程
随后任务，创建Application、启动主线程、创建MainActivity。
热启动：后台 ——> 前台。最快
温启动：较快。仅仅重走LifeCycle。
优化方向：
Application和Activity生命周期
二. 启动时间测量方式
两种方式：adb 命令 / 手动打点
adb方式
adb shell am start -W packagename/首屏Activity
ThisTime：最后一个Activity启动耗时
TotalTime：所有Activity启动耗时
WaitTime：AMS启动Activity的总耗时
（此方式线下使用方便，不能带到线上。非严谨、精确时间）手动打点：
启动时埋点，启动结束时埋点，两者差值。
写个工具类，读取SystemCurrentTimeMillis
结束时间的记录位置？真实数据展示出来，Feed第一条展示。
onWindowFocusChanged不够准确。
getViewTreeObserver 的 addOnPreDrawListener
三. 启动优化工具选择
主要两个工具：TraceView、Systrace
1. TraceView
图形的形式展现执行时间、调用等。信息全面，包含所有线程
使用方式：Debug.startMethodTracing("");
Debug.stopMethodTracing("");
生成文件在sd卡：Android/data/packagename/files
最大能有 8MB的信息。
图像分析：
Top Down：Self Time、Total Time （Wall Clock Time、Thread Time）是call Chart 的详细文字版本
Call Chart：a调用b，那么a 就在 b 的上面。系统API 橙色、应用自己的绿色，第三放的就是蓝色
Flame Chart：相同调用顺序的过程会合并在一起。
BottomUp：和Top Down相反。
TraceView 运行时开销严重，整体都会变慢。
与CpuProfiler相比，此工具Android Studio中直接使用。可能需要手速很快才能获取到。
2.Systrace
结合Android 内核的数据，生成一个Html报告
API 18 以上使用，推荐TraceCompact
使用方式：
python systrace.py -t 10 [other-options] [categories]
https://developer.android.com/studio/command-line/systrace#command_options
查看CPU 核心运行状况
UIThread 和 Other Threads的对比
通过Slice 查看 start 、wall Duration（代码执行时间）、CPU Duration （代码消耗cpu的时间）
举例：锁冲突
四. 优雅获取方法耗时讲解
常规方法的侵入性太强。重复编辑。
所以，采用AOP方法（Aspect Oriented Programming 面向切面编程）
- 针对同一类问题的统一处理
- 无侵入添加代码
AspectJ使用：
classPath ‘com.hujiang.aspectjx:gradle-android-plugin-aspectjx:2.0.0’
implementation 'org.aspectj:aspectjrt:1.8.+'
apply plugin: 'android-aspectjx'
Join Points:程序运行时的执行点，可以作为切面的地方。
- 函数调用、执行
- 获取、设置变量
- 类初始化
PointCut：带条件的JoinPoints （筛选一下某些点）
一种Hook，要插入代码的位置
Before：PointCut之前执行。Advice，具体插入位置。
After：PointCut之后执行
Around：PointCut之前和之后分别执行
execution：处理Join Point 的类型，call、execution
（* android.app.Activity.on**(..)）:匹配规则
onActivityCalled:要插入的代码
4.1优雅获取方法耗时实操
4.2 异步优化详解
优化技巧：
Theme切换：感觉上的快。
异步优化：
子线程分担住线程任务，并行减少时间。
ExecutorService service = Executors.newFixedThreadPool(CORE_POOL_SIZE);
service.submit(new Runnable(){
public void run(){
方法分别放入；
}
});
不符合异步要求的。部分代码必须运行在主线程当中，那么放弃这种异步优化的方案。
需要在某阶段完成。由于异步执行不知道 子任务何时结束，跳转新界面时 该方法是否完成，
添加
private CountDownLatch mCountDownLatch = new CountDownLatch(1); // 一个简单的开/关锁存器
在条件被满足后
mCountDownLatch.countDown();
try {
mCountDownLatch.await();
} catch(InterruptedException e){
e.printStackTrace;
}
4.3 异步初始化最优解-启动器-1
充分利用CPU多核，自动梳理执行顺序
- 代码Task化，启动逻辑抽象为Task。
- 根据所有任务以来关系排序生成一个有向无环图
- 多线程按照排序后的优先级依次执行
4.4 异步初始化最优解-启动器-2
TaskDispatcher。并向当中要执行的Task 分别继承，在run方法中进行执行。
4.5 更优秀的延迟初始化方案
常规方式，回调方法中执行耗时。很有可能导致feed 卡顿。
对延迟任务进行分批初始化。
- 利用IdleHandler特性，空闲时执行
4.6 启动优化其它方案
异步、延迟、懒加载。
技术、业务相结合。
cpu time才是优化方向
按照systrace 及 cpu time 跑满cpu
IO密集型 和 CPU密集型 操作。
收敛启动代码修改权限。
结合Ci修改启动代码需要Review通知
其他方案：
- 提前加载SharedPreferences。getSharedPreference load到内存中。如果没有完成一直阻塞进行等待。
- Multidex之前加载，利用此阶段CPU覆写 getApplicationContext() 返回 this。 attachBaseContext中
启动阶段不启动子进程，子进程会共享CPU资源，导致主进程CPU紧张。注意启动顺序：App onCreate 之前是ContentProvider
类加载优化：提前异步加载（可以替换掉系统的ClassLoader，每个类加载的时候都打印一个Log）Class.forName() 只加载类本身及其静态变量的引用类。
new 类实例 可以额外加载类成员变量的引用类
启动阶段抑制GC
- CPU锁频
启动速度模拟面试
1）你做启动优化是怎么做的？
- 分析现状、确认问题。（目前启动流程复杂，主线程执行了太多的代码）
- 针对性优化（实现异步初始化）简单异步 指向了启动器。
- 长期保持优化效果。
2）是怎么异步的，异步遇到问题没有？
- 异步演进过程
- 详细介绍启动器
3）有哪些容易忽略的点？
- cpu time 和 wall time。
- 注意延迟初始化的优化
- 介绍黑科技，类加载。Systrace 可能没有给满的CPU，拉高CPU。
4）版本迭代导致的启动变慢有好的解决方式吗？
- 启动器
- 结合CI
- 监控完善
