一. Android 启动时间优化

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

Systrace指令

查看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
监控完善