APP性能优化系列（四）：App启动速度优化之耗时检测处理

一、应用的启动方式：

1、冷启动：当启动应用时，后台没有该应用的进程，这时系统会首先会创建一个新的进程分配给该应用，这种启动方式就是冷启动。

2、热启动：当启动应用时，后台已有该应用的进程，比如按下home键，这种在已有进程的情况下，这种启动会从已有的进程中来启动应用，这种启动方式叫热启动。

3、温启动 ：当启动应用时，后台已有该应用的进程，但是启动的入口Activity被干掉了，比如按了back键，应用虽然退出了，但是该应用的进程是依然会保留在后台，这种启动方式叫温启动。

二、应用的启动时间统计：

adb shell am start -W [PackageName]/[PackageName.MainActivity]

执行成功后将返回三个测量到的时间：

这里面涉及到三个时间，ThisTime、TotalTime 和 WaitTime。WaitTime 是 startActivityAndWait 这个方法的调用耗时，ThisTime 是指调用过程中最后一个 Activity 启动时间到这个 Activity 的 startActivityAndWait 调用结束。TotalTime 是指调用过程中第一个 Activity 的启动时间到最后一个 Activity 的 startActivityAndWait 结束。如果过程中只有一个 Activity ，则 TotalTime 等于 ThisTime。

 

总结:如果只关心某个应用自身启动耗时，参考TotalTime；如果关心系统启动应用耗时，参考WaitTime；如果关心应用有界面Activity启动耗时，参考ThisTime。

三、性能检查项：

从我们Application开始到首页显示出来，这个过程，我们应该注意一些什么，将这个过程细分一下，会有下面的时间点需要注意。

Application的构造器方法——>attachBaseContext()——>onCreate()——>Activity的构造方法——>onCreate()——>配置主题中背景等属性——>onStart()——>onResume()——>测量、布局、绘制显示在界面上。

因为上面这些阶段全部都是在主线程中执行的，任何不经意的操作都可能拖慢应用的启动速度。所以我们不应在Application以及Activity的生命周期回调中做任何费时操作，具体指标大概是你在onCreate，onResume，onStart等回调中所花费的总时间最好不要超过400ms，否则用户在桌面点击你的应用图标后，将感觉到明显的卡顿。但是有些不得以的任务又必须在UI显示之前执行。所以我们要将任务划分优先级。

• 优先级为1的在应用启动时，就开始加载
• 优先级为2的在首页渲染完成后，开始加载
• 优先级为3的在首页渲染完成后，延迟加载

对于首页渲染完成后，开始加载，或者延迟加载，延迟加载的目的就是界面先显示出来，然后加载，但是你觉得要延迟多久呢？在 Android 的高端机型上,应用的启动是非常快的 , 这时候只需要 Delay 很短的时间就可以了, 但是在低端机型上,应用的启动就没有那么快了,而且现在应用为了兼容旧的机型,往往需要 Delay 较长的时间,这样带来体验上的差异是很明显的。延迟加载有一种方式。

优化的DelayLoad
  getWindow().getDecorView().post(new Runnable() {
    @Override
   public void run() {
        myHandler.post(mLoadingRunnable);
   }
  });

关于这种懒加载机制，参考Android应用启动优化:一种DelayLoad的实现和原理(上篇)：http://androidperformance.com/2015/11/18/Android-app-lunch-optimize-delay-load.html

 四、检测界面是否有掉帧：

        在Choreographer类中有如下代码：

    void doFrame(long frameTimeNanos, int frame) {
        final long startNanos;
        synchronized (mLock) {
            if (!mFrameScheduled) {
                return; // no work to do
            }

            if (DEBUG_JANK && mDebugPrintNextFrameTimeDelta) {
                mDebugPrintNextFrameTimeDelta = false;
                Log.d(TAG, "Frame time delta: "
                        + ((frameTimeNanos - mLastFrameTimeNanos) * 0.000001f) + " ms");
            }

            long intendedFrameTimeNanos = frameTimeNanos;
            startNanos = System.nanoTime();
            final long jitterNanos = startNanos - frameTimeNanos;
            if (jitterNanos >= mFrameIntervalNanos) {
                final long skippedFrames = jitterNanos / mFrameIntervalNanos;
                if (skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT) {
                    Log.i(TAG, "Skipped " + skippedFrames + " frames!  "
                            + "The application may be doing too much work on its main thread.");
                }
                final long lastFrameOffset = jitterNanos % mFrameIntervalNanos;
                if (DEBUG_JANK) {
                    Log.d(TAG, "Missed vsync by " + (jitterNanos * 0.000001f) + " ms "
                            + "which is more than the frame interval of "
                            + (mFrameIntervalNanos * 0.000001f) + " ms!  "
                            + "Skipping " + skippedFrames + " frames and setting frame "
                            + "time to " + (lastFrameOffset * 0.000001f) + " ms in the past.");
                }
                frameTimeNanos = startNanos - lastFrameOffset;
            }

也就是当跳帧数大于设置的SKIPPED_FRAME_WARNING_LIMIT 值时会在当前进程输出调帧的log。由于 SKIPPED_FRAME_WARNING_LIMIT 的值默认为 30，所以此log并不是经常看到，如果我们用反射的方法把SKIPPED_FRAME_WARNING_LIMIT的值设置成1，这样可以保证只要有丢帧，就会有上面的log输出来。

static {
        try {
            Field field = Choreographer.class.getDeclaredField("SKIPPED_FRAME_WARNING_LIMIT");
            field.setAccessible(true);
            field.set(Choreographer.class,1);
        } catch (Throwable e) {
            e.printStackTrace();
        }
    }

01-26 15:31:16.194  8743  8743 I Choreographer: Skipped 2 frames!  The application may be doing too much work on its main thread.
01-26 15:31:16.269  8743  8743 I Choreographer: Skipped 3 frames!  The application may be doing too much work on its main thread.
01-26 15:31:19.730  8743  8743 I Choreographer: Skipped 31 frames!  The application may be doing too much work on its main thread.
01-26 15:31:19.751  8743  8743 I Choreographer: Skipped 1 frames!  The application may be doing too much work on its main thread. 

 

 

转载于:https://www.cnblogs.com/andy-loong/p/8335349.html