「性能优化1.0」启动分类及启动时间的测量
「性能优化1.1」计算方法的执行时间
「性能优化1.2」异步优化
「性能优化1.3」延迟加载方案
「性能优化2.0」布局加载原理
「性能优化2.1」LayoutInflater Hook控件加载耗时
「性能优化2.2」获取布局的加载时间

一、获取每一个界面加载耗时

在 Activity onCreate 中我们会通过 setContentView 来加载对应的布局文件。那么这个方法是同步的进行的，因此如果该方法加载时间比较长，那么会拖慢整个界面显示时间，如果当前 Activity 是入口 Activity 的话，那么对应的整个APP启动过程就被拖慢。

我们在前面几篇博客中分析了 APP 的启动耗时，那么在这篇博客中我们来分析如何获取界面的加载耗时。

二、常规方案

常规的实现是我们最先想到的一个点，就是在 setContentView 执行之前和执行之后分别打点，然后计算两个时间差即是setContentView的执行耗时。

伪代码如下：

//MainActivity.java
@Override
protected void onCreate(Bundle savedInstanceState) {    
    long startTime = System.currentTimeMillis();
    setContentView(R.layout.activity_main);
    long cost = System.currentTimeMillis() - startTime;
    Log.i(TAG, "setContentView cost " + cost);
}

三、AOP方案

常规的实现方案缺点比较冥想，对项目的侵入比较大，而且工作量也比较大，这里我们可以使用 AOP 来解决这个问题。 AOP 我们在的博客中已经分享过，具体参考「性能优化1.1」计算方法的执行时间。

在这里可以看到，我们不需要修改 MainActivity 类任何代码即 hook Activity 中的 setContenTView 来计算方法的执行时间。

总结：这种方式是比较优雅的方式，对代码无侵入性。

@Aspect
public class PerformanceAop {

    @Around("execution(* android.app.Activity.setContentView(..))")
    public void hookSetContentViewTime(ProceedingJoinPoint joinPoint) {
        Signature signature = joinPoint.getSignature();
        //开始处打点
        String name = signature.toShortString();
        long startTime = System.currentTimeMillis();
        try {
            joinPoint.proceed();
        } catch (Throwable throwable) {
            throwable.printStackTrace();
        }
        //结束打点，并计算耗时。
        long costTime = System.currentTimeMillis() - startTime;
        Log.i("Aop", "method " + name + " cost:" + costTime);
    }
}

如果上面的代码不好理解，那么来看一张图应该就明白了

hook setContentView 图解

图中的打点就是记录当前时间。

四、总结

本节使用两种方案获取界面的加载耗时，在日常开发中如果收到测试或者用户反馈在 APP 中显示某个界面时出现界面卡顿的情况，那么开发人可以通过分析对应的这个界面的加载时间，并且根据上一篇博客「性能优化2.1」LayoutInflater Hook控件加载耗时分析哪一个控件的加载是比较耗时，这样就定位到具体的问题所在了。

记录于2019年3月20日