如需转载请评论或简信，并注明出处，未经允许不得转载
系列文章
目录
前言
在进行启动优化之前，我们应该先了解如何对启动的时间进行测量，这样就能更加准确的衡量我们优化的成果
adb命令测量
adb shell am start -W packagename/首屏Activity
Tips：这个命令可以打开Launcher Activity，如果在打开别的Activity的时候遇到问题，可以在清单文件中配置Activity的exported = true
- ThisTime：一般和TotalTime时间一样，除非在应用启动时开了一个透明的Activity预先处理一些事，再显示出Activity，这样将比TotalTime小
- TotalTime：应用的启动时间，包括创建进程+Application初始化+Activity初始化到界面显示
- WaitTime：一般比TotalTime大点，包括系统响应的耗时
这三个时间不好理解，我们可以把整个过程分解，如下所示：
前一个应用的
activity的onPause()系统调用AMS耗时
第一个
activity启动耗时第一个
activity的onPause()耗时第二个
activity启动耗时
ThisTime表示5
TotalTime表示3、4、5总共的耗时
WaitTime则表示所有的操作耗时，即1、2、3、4、5所有的耗时
开发者一般只要关心 TotalTime 即可，这个时间才是自己应用真正启动的耗时
使用adb命令测量启动时间的特点：
- 应用的启动过程往往不只一个
Activity，有可能是先进入一个启动页，然后再从启动页打开真正的首页。某些情况下还有可能中间经过更多的Activity，这个时候需要将多个Activity的时间加起来 - 将多个
Activity启动时间加起来并不完全等于用户感知的启动时间。例如在启动页可能是先等待某些初始化完成或者某些动画播放完毕后再进入首页。使用命令行统计的方式只是计算了Activity的启动以及初始化时间，并不能体现这种等待任务的时间 - 这种方式只能在线下使用，不能再线上使用
手动打点测量（推荐）
手动打点就是启动时埋点，启动结束埋点，计算二者差值。这种方式比较精确，可以带到线上测量用户的启动时间，所以推荐使用这种方式
那么什么时候算启动开始，什么时候算启动结束呢？
我们先写一个测量启动时间的工具类
public class LaunchTimer {
private static long sTime;
public static void startRecord() {
sTime = System.currentTimeMillis();
}
public static void endRecord() {
endRecord("");
}
public static void endRecord(String msg) {
long cost = System.currentTimeMillis() - sTime;
LogUtils.i(msg + " cost " + cost + "ms");
}
}
启动时间点
启动时间点比较好记录，我们一般会在Application attachBaseContext()开始记录，因为在这之前 Context 还没有初始化，一般也干不了什么事情，当然这个是要视具体情况来定，其实只要保证在 App 的具体业务逻辑开始执行之前记录起始时间点即可
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
LauncherTimer.startRecord();
}
结束时间点
我们究竟要在哪里进行启动结束的记录呢？
一个 Activity 走完onCreate onStart onResume 这几个生命周期之后，完成了应用自身的一些配置,比如 Activity 主题设置 window 属性的设置 View 树的建立，但是其实后面还需要各个 View 执行 measure layout draw等。Activity的首帧时间实际上是 Activity.onWindowFocusChanged，下面是它的注释：
/**
*Called when the current {@link Window} of the activity gains or loses
* focus. This is the best indicator of whether this activity is visible
* to the user. The default implementation clears the key tracking
* state, so should always be called.
...
*/
我们可以在onWindowFocusChanged中进行打点，用于统计应用从启动到首帧绘制的时间
private boolean mHasRecord;
@Override
public void onWindowFocusChanged(boolean hasFocus) {
super.onWindowFocusChanged(hasFocus);
if (!mHasRecord) {
mHasRecord = true;
LaunchTimer.endRecord("onWindowFocusChanged");
}
}
但是实际上对于用户来说，onWindowFocusChanged()所统计出的首帧时间，并不能够代表这个页面真正被展现出来了，为什么呢？举个例子，假设我们的APP首页是一个列表，这个列表的数据一般是从网络上获取的，那么用户看到的”首帧“，往往就是网络请求成功后列表的第一个Item展示出来的时间。我们做性能优化主要是为了能更好的改善用户的体验，而不仅仅是为了数据上面的好看，所以在做启动优化的时候，我们不仅仅要考虑虑onWindowFocusChanged()前的过程，也要考虑onWindowFocusChanged()后一直到用户真正看到页面的过程
正确的解答方式是我们要等真实的数据展示出来，这样才算启动结束了，这里我们采用Feed第一条数据的展示作为启动结束
public class HomeAdapter extends RecyclerView.Adapter {
....
//只需要记录一次
private boolean mHasRecorded;
@Override
public RecyclerView.ViewHolder onCreateViewHolder(ViewGroup parent, int viewType) {
......
return viewholder;
}
@Override
public void onBindViewHolder(final RecyclerView.ViewHolder holder, int position) {
if (position == 0 && !mHasRecorded) {
mHasRecorded = true;
holder.itemView.getViewTreeObserver().addOnPreDrawListener(new ViewTreeObserver.OnPreDrawListener() {
@Override
public boolean onPreDraw() {
//注销监听
holder.itemView.getViewTreeObserver().removeOnPreDrawListener(this);
//启动结束
LauncherTimer.endRecord("feedShow");
return true;
}
});
}
.....
}
@Override
public int getItemCount() {
return datas.size();
}
}
通过这种方式测量出来的启动时间和通过onWindowFocusChanged()测量的启动时间一般差距是比较大的，大家也可以自己实践一下
Tips：addOnDrawListener要求API 16，所以这里使用了addOnPreDrawListener
总结
本文我们介绍了启动优化时间的测量，有adb和手动打点两种方式，adb方式的缺点是测量结果和实际表现有偏差和不能带到线上使用，所以这里我推荐使用手动打点的方式进行启动时间测量，因为我们做启动优化要从真实用户体验的角度出发，而不是仅仅追求数据上的结果
