Activity启动速度测量

一. 背景

 应用页面的打开速度影响着APP的用户体验，也是APP的性能指标之一，任何一个成熟的APP都应该对页面的启动速度进行监控和优化。

二. 相关原理

1. Activity 的启动流程

基于源码 API 29(Android 10)

startActivity.jpg

1）应用通过startActivity或是startActivityForResult方法向ActivityManagerService发出启动请求。

2）ActivityTaskManagerService接收启动请求，创建ActivityStarter，并设置Activity 启动信息。

3）ActivityStarter 解析Intent 信息和要启动的Activity 信息，并处理Activity 的启动模式和flag 等，做完上述处理后，普通情况会调用ActivityStack#resumeTopActivityUncheckedLocked

4）ActivityStack 中会将栈顶resume 的Activity 执行pause，通过发送一个PauseActivityItem 消息来完成。

5）栈顶Activity执行完onPause流程退出后开始启动Activity。这里是在ActivityStackSupervisor 中执行，先判断Activity所在的进程是否存在，存在的话可以直接调用realStartActivityLocked方法，否则通过Zygote进程fork出一个新的进程。然后发送一个LaunchActivityItem 消息创建Activity。

6）PauseActivityItem和LaunchActivityItem 都由ClientLifeCycleManager 处理，最后会调用它们自己的execute 方法，LaunchActivityItem 的execute 方法会调用到ActivityThread 的handleLaunchActivity，然后ActivityThread 中会创建Activity 并进行相关的初始化，然后调用到Instrumentation，再走Activity 的生命周期回调。

7）上述流程都执行完毕后，会去执行栈顶Activity的onStop过程。

2. 如何衡量页面启动速度

 从用户角度讲，体验到的页面启动时间，是点击一个可跳转控件到第二个页面出现内容。从我们的角度来说，是指从调用startActivity 到第二个Activity的View 的首帧的渲染结束。

3. 如何实现测量

• 耗时阶段划分：
  根据我们对Activity 启动流程的分析和衡量启动速度的定义，我们可以把耗时划分下面三个阶段
  1）上一个Activity onPause
  2）当前要启动的Activity 进行 launch，onCreate -> onResume
  3）当前Activity进行 View 渲染
• 统计方法
  1）onPause 时间
   onPause 方法执行前后插桩
  2）launch 时间
   onCreate 方法前、onResume 方法后插桩
  3）渲染时间
   从onResume执行完成到第一帧渲染完成所花费的时间就是Render耗时。Render耗时可以用三种方式计算出来。
  
  setContentView.jpg

addView.jpg

doTraversals.jpg

 i. IdleHandler, IdleHandler 只在线程空闲时候执行

@Override
protected void onResume() {
    super.onResume();
    final long start = System.currentTimeMillis();
    Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() {
        @Override
        public boolean queueIdle() {
            Log.d(TAG, "onRender cost:" + (System.currentTimeMillis() - start));
            return false;
        }
    });
}

  ii. DecorView的两次post
  通过getWindow().getDecorView()获取到DecorView后，调用post方法，此时由于DecorView的attachInfo为空，会将这个Runnable放置runQueue中。runQueue内的任务会在ViewRootImpl.performTraversals的开始阶段被依次取出执行，我们知道这个方法内会执行到DecorView的测量、布局、绘制操作，不过runQueue的执行顺序会在这之前，所以需要再进行一次post操作。第二次的post操作可以继续用DecorView().post或者其普通Handler.post(),并无影响。此时mAttachInfo已不为空，DecorView().post也是调用了mHandler.post()。

@Override
protected void onResume() {
    super.onResume();
    final long start = System.currentTimeMillis();
    getWindow().getDecorView().post(new Runnable() {
        @Override
        public void run() {
            new Hanlder().post(new Runnable() {
                @Override
                public void run() {
                    Log.d(TAG, "onPause cost:" + (System.currentTimeMillis() - start));
                }
            });
        }
    });
}

  iii. new Handler的两次post

@Override
protected void onResume() {
    super.onResume();
    final long start = System.currentTimeMillis();
    new Handler.post(new Runnable() {
        @Override
        public void run() {
            getWindow().getDecorView().post(new Runnable() {
                @Override
                public void run() {
                    Log.d(TAG, "onPause cost:" + (System.currentTimeMillis() - start));
                }
            });
        }
    });
}

  第三种方法和第二种方法的实现原理不同，这是因为ViewRootImpl.scheduleTraversals方法会往主线程队列插入一个屏障消息，代码如下所示：

  ViewRootImpl.java
  void scheduleTraversals() {
            ......
            mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
            mChoreographer.postCallback(
                    Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
            ......
        }
    }

  复制代码屏障消息的作用在于阻塞在它之后的同步消息的执行，当我们在onResume方法中执行第一次new Handler().post方法，向主线程消息队列放入一条消息时，从前面的内容可以知道onResume是在ViewRootImpl.scheduleTraversals方法之前执行的，所以这条消息会在屏障消息之前，能被正常执行；而第二次post的消息就在屏障消息之后了，必须等待屏障消息被移除掉才能执行。屏障消息的移除操作在ViewRootImpl.doTraversal方法，在这之后就将执行performTraversals方法，所以移除屏障消息后，等待performTraversals执行完毕，就能正常执行第二次post操作了。

• Hook 方案
  上面提到的三个阶段的统计方法，都需要对生命周期方法进行插桩，这里可以有两种hook 方案：
  1）Hook Instrumentation
   Hook Instrumentation是指通过反射将ActivtyThread内的Instrumentation对象替换成我们自定义的Instrumentation对象。
   由于所有Activity生命周期的回调都要经过Instrumentation对象，因此通过Hook Instrumentation对象，可以很方便地统计出Actvity每个生命周期的耗时。
   问题：
   由于很多功能，比如插件化都喜欢Hook Instrumentation，为了不影响他们的使用，不得不重写大量的方法执行mBase.xx()。
  2）Hook ActivityThread$H
   每当ASM通过Binder调用到到App端时，会根据不同的调用方法转化成不同的消息放入ActivityThread$H，就能得到所有生命周期的起点。
  另外，Handler事实上可以设置一个mCallback字段（需要通过反射设置），在执行dispatchMessage方法时，如果mCallback不为空，则优先执行mCallback。因此，可以通过反射获取ActivityThread中的H对象，将mCallback修改为自己实现的Handler.Callback对象，实现消息的拦截,而不需要替换Hanlder对象。
   问题：
   不能获取到具体的生命周期方法耗时

3. 工具能力

• 获取Activity 启动耗时
  1）各生命周期方法耗时
  2）输出形式
   log and 图形界面（耗时历史）
  3）耗时过长页面提醒

三. 设计

1. 形式

1）Android Library

2. 流程

Activity启动速度流程图.jpg