「性能优化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);
}
}
如果上面的代码不好理解,那么来看一张图应该就明白了
图中的打点就是记录当前时间。
四、总结
本节使用两种方案获取界面的加载耗时,在日常开发中如果收到测试或者用户反馈在 APP 中显示某个界面时出现界面卡顿的情况,那么开发人可以通过分析对应的这个界面的加载时间,并且根据上一篇博客「性能优化2.1」LayoutInflater Hook控件加载耗时分析哪一个控件的加载是比较耗时,这样就定位到具体的问题所在了。
记录于2019年3月20日