Android 线上性能监控详解

什么是卡顿

什么是卡顿,很多人能马上联系到的是帧率 FPS (每秒显示帧数)。那么多低的 FPS 才是卡顿呢?又或者低 FPS 真的就是卡顿吗?(以下 FPS 默认指平均帧率)

其实并非如此,举个例子,游戏玩家通常追求更流畅的游戏画面体验一般要达到 60FPS 以上,但我们平时看到的大部分电影或视频 FPS 其实不高,一般只有 25FPS ~ 30FPS,而实际上我们也没有觉得卡顿。 在人眼结构上看,当一组动作在 1 秒内有 12 次变化(即 12FPS),我们会认为这组动作是连贯的;而当大于 60FPS 时,人眼很难区分出来明显的变化,所以 60FPS 也一直作为业界衡量一个界面流畅程度的重要指标。一个稳定在 30FPS 的动画,我们不会认为是卡顿的,但一旦 FPS 很不稳定,人眼往往容易感知到。

FPS 低并不意味着卡顿发生,而卡顿发生 FPS 一定不高。 FPS 可以衡量一个界面的流程性,但往往不能很直观的衡量卡顿的发生,这里有另一个指标(掉帧程度)可以更直观地衡量卡顿。

什么是掉帧(跳帧)? 按照理想帧率 60FPS 这个指标,计算出平均每一帧的准备时间有 1000ms/60 = 16.6667ms,如果一帧的准备时间超出这个值,则认为发生掉帧,超出的时间越长,掉帧程度越严重。假设每帧准备时间约 32ms,每次只掉一帧,那么 1 秒内实际只刷新 30 帧,即平均帧率只有 30FPS,但这时往往不会觉得是卡顿。反而如果出现某次严重掉帧(>300ms),那么这一次的变化,通常很容易感知到。所以界面的掉帧程度,往往可以更直观的反映出卡顿。

造成卡顿的原因通常是主线程执行了繁重的UI绘制、大量的计算或者IO耗时操作。可以通过一些第三方性能检测开源库进行检测。如BlockCanary、ArgusApm、LogMonitor、Matrix等。

从监控主线程的实现上可以分为两种:

1.BlockCanary监测原理

(1)简介

BlockCanary是Android平台上的一个轻量的,非侵入式的性能监控组件,可以在使用应用的时候检测主线程上的各种卡顿问题,并可通过组件提供的各种信息分析出原因并进行修复

BlockCanary对主线程操作进行了完全透明的监控,并能输出有效的信息, 帮助开发分析、定位到问题所在,迅速优化应用。其特点有:

(2)原理

在Android应用的主线程中,只有一个Looper,所有的Handler都共享共一个Looper。

    public static void prepareMainLooper() {
        prepare(false);
        synchronized (Looper.class) {
            if (sMainLooper != null) {
                throw new IllegalStateException("The main Looper has already been prepared.");
            }
            sMainLooper = myLooper();
        }
    }

所有的Message是通过Looper的loop方法执行的。

public static void loop() {
    ...

    for (;;) {
        ...

        // This must be in a local variable, in case a UI event sets the logger
        Printer logging = me.mLogging;
        if (logging != null) {
            logging.println(">>>>> Dispatching to " + msg.target + " " +
                    msg.callback + ": " + msg.what);
        }

        msg.target.dispatchMessage(msg);

        if (logging != null) {
            logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
        }

        ...
    }
}

可以看到,Printer分别在Message执行前后打印了log信息。如果dispatchMessage卡住那么意味着主线程被卡住了。

而Printer是一个接口,并且可以通过Looper的setMessageLogging方法进行设置。

Looper.getMainLooper().setMessageLogging(mainLooperPrinter);

因此,可以自定义一个Printer实现类,监控Message的执行时间。

@Override
public void println(String x) {
    if (!mStartedPrinting) {
        mStartTimeMillis = System.currentTimeMillis();
        mStartThreadTimeMillis = SystemClock.currentThreadTimeMillis();
        mStartedPrinting = true;
    } else {
        final long endTime = System.currentTimeMillis();
        mStartedPrinting = false;
        if (isBlock(endTime)) {
            notifyBlockEvent(endTime);
        }
    }
}

private boolean isBlock(long endTime) {
    return endTime - mStartTimeMillis > mBlockThresholdMillis;
}

简单的使用如在开发、测试、Monkey的时候,Debug包启用

  • 开发可以通过图形展示界面直接看信息,然后进行修复
  • 测试可以把log丢给开发,也可以通过卡慢详情页右上角的更多按钮,分享到各种聊天软件(不要怀疑,就是抄的LeakCanary)
  • Monkey生成一堆的log,找个专人慢慢过滤记录下重要的卡慢吧

还可以通过Release包用户端定时开启监控并上报log,后台匹配堆栈过滤同类原因,提供给开发更大的样本环境来优化应用。

(3)缺点

1.时效性不是很强,可能会发送偏移 2.无法分析复杂的堆栈,因为 dispatch() 本身的机制,导致,你可能会看到这样的堆栈。

2.使用Choreographer检测卡顿和丢帧

丢帧是引起卡顿的重要原因。在Android中可以通过Choreographer检测Android系统的丢帧情况。

public class MainActivity extends Activity {
    ...
    private MyFrameCallback mFrameCallback = new MyFrameCallback();
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        Choreographer.getInstance().postFrameCallback(mFrameCallback);

        MYTest();
        button = findViewById(R.id.bottom);
        button.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                uiLongTimeWork();
                Log.d(MainActivity.class.getSimpleName(), "button click");
            }
        });
    }

    private void MYTest() {
        setContentView(R.layout.activity_main);
        Log.d(MainActivity.class.getSimpleName(), "MYTest");
    }

    private float getRefreshRate() { //获取屏幕主频频率
        Display display = getWindowManager().getDefaultDisplay();
        float refreshRate = display.getRefreshRate();
//        Log.d(TAG, "屏幕主频频率 =" + refreshRate);
        return refreshRate;
    }

    @RequiresApi(api = Build.VERSION_CODES.JELLY_BEAN)
    public class MyFrameCallback implements Choreographer.FrameCallback {
        private String TAG = "性能检测";
        private long lastTime = 0;

        @Override
        public void doFrame(long frameTimeNanos) {
            if (lastTime == 0) {
                //代码第一次初始化。不做检测统计。
                lastTime = frameTimeNanos;
            } else {
                long times = (frameTimeNanos - lastTime) / 1000000;
                int frames = (int) (times / (1000/getRefreshRate()));
                if (times > 16) {
                    Log.w(TAG, "UI线程超时(超过16ms):" + times + "ms" + " , 丢帧:" + frames);
                }
                lastTime = frameTimeNanos;
            }
            Choreographer.getInstance().postFrameCallback(mFrameCallback);
        }
    }

    private void uiLongTimeWork() {
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

Choreographer周期性的在UI重绘时候触发,在代码中记录上一次和下一次绘制的时间间隔,如果超过16ms,就意味着一次UI线程重绘的“丢帧”。丢帧的数量为间隔时间除以16,如果超过3,就开始有卡顿的感知。

卡顿堆栈信息输出

Choreographer本身依赖于Android主线程的Looper消息机制。 发生在Android主线程的每(1000/UI刷新频率)ms重绘操作依赖于Main Looper中消息的发送和获取。如果App一切运行正常,无卡顿无丢帧现象发生,那么开发者的代码在主线程Looper消息队列中发送和接收消息的时间会很短,理想情况是(1000/UI刷新频率)ms,这是也是Android系统规定的时间。但是,如果一些发生在主线程的代码写的太重,执行任务花费时间太久,就会在主线程延迟Main Looper的消息在(1000/UI刷新频率)ms尺度范围内的读和写。

在Looper的loop()函数中,Android完成了Looper消息队列的分发,在分发消息开始,会通过Printer打印一串log日志:

   logging.println(">>>>> Dispatching to " + msg.target + " " +
                        msg.callback + ": " + msg.what);

同时在消息处理结束后也会打印一串消息日志:

logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);

现在设计一种技巧性的编程方案:在(>>>>> Dispatching to)开始时候,延时一定时间(THREAD_HOLD)执行一个线程,延时时间为THREAD_HOLD,该线程只完成打印当前Android堆栈的信息。THREAD_HOLD即为开发者意图捕捉到的超时时间。如果没什么意外,该线程在THREAD_HOLD后,就打印出当前Android的堆栈信息。巧就巧妙在利用这一点儿,因为延时THREAD_HOLD执行的线程和主线程Looper中的线程是并行执行的,当在>>>>> Dispatching to时刻把延时线程任务构建完抛出去等待THREAD_HOLD后执行,而当前的Looper线程中的消息分发也在执行,这两个是并发执行的不同线程。 设想如果Looper线程中的操作代码很快就执行完毕,不到16ms就到了<<<<< Finished to,那么毫无疑问当前的主线程无卡顿和丢帧发生。如果特意把THREAD_HOLD设置成大于16ms的延时时间,比如1000ms,如果线程运行顺畅不卡顿无丢帧,那么从>>>>> Dispatching to到达<<<<< Finished to后,把延时THREAD_HOLD执行的线程删除掉,那么线程就不会输出任何堆栈信息。若不行主线程发生阻塞,当从>>>>> Dispatching to到达<<<<< Finished to花费1000ms甚至更长时间后,而由于到达<<<<< Finished to的时候没来得及把堆栈打印线程删除掉,因此就输出了当前堆栈信息,此堆栈信息刚好即为发生卡顿和丢帧的代码堆栈,正好就是所需的卡顿和丢帧检测代码。

public class MainActivity extends Activity {
    ...
    private CheckTask mCheckTask = new CheckTask();

        @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        check();
        ...
        button = findViewById(R.id.bottom);
        button.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                uiLongTimeWork();
                Log.d(MainActivity.class.getSimpleName(), "button click");
            }
        });
    }

    private void check() {
        Looper.getMainLooper().setMessageLogging(new Printer() {
            private final String START = ">>>>> Dispatching to";
            private final String END = "<<<<< Finished to";

            @Override
            public void println(String s) {
                if (s.startsWith(START)) {
                    mCheckTask.start();
                } else if (s.startsWith(END)) {
                    mCheckTask.end();
                }
            }
        });
    }

    private void uiLongTimeWork() {
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    private class CheckTask {
        private HandlerThread mHandlerThread = new HandlerThread("卡顿检测");
        private Handler mHandler;

        private final int THREAD_HOLD = 1000;

        public CheckTask() {
            mHandlerThread.start();
            mHandler = new Handler(mHandlerThread.getLooper());
        }

        private Runnable mRunnable = new Runnable() {
            @Override
            public void run() {
                log();
            }
        };

        public void start() {
            mHandler.postDelayed(mRunnable, THREAD_HOLD);
        }

        public void end() {
            mHandler.removeCallbacks(mRunnable);
        }
    }



    /**
     * 输出当前异常或及错误堆栈信息。
     */
    private void log() {
        StringBuilder sb = new StringBuilder();
        StackTraceElement[] stackTrace = Looper.getMainLooper().getThread().getStackTrace();
        for (StackTraceElement s : stackTrace) {
            sb.append(s + "\n");
        }

        Log.w(TAG, sb.toString());
    }
1970-02-14 17:35:06.367 11590-11590/com.yanbing.aop_project D/MainActivity: button click
1970-02-14 17:35:06.367 11590-11611/com.yanbing.aop_project W/MainActivity: java.lang.String.indexOf(String.java:1658)
    java.lang.String.indexOf(String.java:1638)
    java.lang.String.contains(String.java:2126)
    java.lang.Class.classNameImpliesTopLevel(Class.java:1169)
    java.lang.Class.getEnclosingConstructor(Class.java:1159)
    java.lang.Class.isLocalClass(Class.java:1312)
    java.lang.Class.getSimpleName(Class.java:1219)
    com.yanbing.aop_project.MainActivity$2.onClick(MainActivity.java:71)
    android.view.View.performClick(View.java:6294)
    android.view.View$PerformClick.run(View.java:24770)
    android.os.Handler.handleCallback(Handler.java:790)
    android.os.Handler.dispatchMessage(Handler.java:99)
    android.os.Looper.loop(Looper.java:164)
    android.app.ActivityThread.main(ActivityThread.java:6494)
    java.lang.reflect.Method.invoke(Native Method)
    com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:438)
    com.android.internal.os.ZygoteInit.main(ZygoteInit.java:807)

可以看到当点击按钮故意制造一个卡顿后,卡顿被检测到,并且输出和定位到了卡顿的具体代码位置。

性能优化-界面卡顿和丢帧(Choreographer 代码检测)

微信APM-Matrix 原理篇-Matrix TraceCanary源码分析

BlockCanary — 轻松找出Android App界面卡顿元凶

教程来源于Github,感谢zhpanvip大佬的无私奉献,致敬!

技术教程推荐

机器学习40讲 -〔王天一〕

Android开发高手课 -〔张绍文〕

TypeScript开发实战 -〔梁宵〕

编译原理之美 -〔宫文学〕

Go 并发编程实战课 -〔晁岳攀(鸟窝)〕

基于人因的用户体验设计课 -〔刘石〕

程序员的个人财富课 -〔王喆〕

大数据经典论文解读 -〔徐文浩〕

结构思考力 · 透过结构看思考 -〔李忠秋〕