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

你可能感兴趣的:(Activity启动速度测量)