Android应用卡顿监控方案原理和对比_android jankstats，面试完腾讯我才发现这些知识点竟然没掌握全

用户068374141344
167 阅读6分钟

1 Choreographer的FrameCallback

TinyDancer 就是通过这种方式计算出FPS。 核心代码：

Choreographer.getInstance().postFrameCallback(object : Choreographer.FrameCallback {
    override fun doFrame(frameTimeNanos: Long) {
        if (lastFrameTimeNanos > 0) {
            val frameTime = (frameTimeNanos - lastFrameTimeNanos) / NANOS_PER_MS
        }
        lastFrameTimeNanos = frameTimeNanos
        Choreographer.getInstance().postFrameCallback(this)
    }

})

通过记录doFrame回调的间隔时间作为每帧耗时frameTime，如此也很容易计算出FPS=1000/frameTime，掉帧数=frameTime/16.6。

2 Choreographer + Looper

Tencent/matrix 虽然也是基于Choreographer，但其监测FPS的机制和上面的FrameCallback方案不太一样。 由前面Choreographer的介绍可知，所谓每一帧其实指的就是input、animation、traversal三种事件对应的三个doCallback方法的执行结果，而matrix统计帧耗时就是通过监测这三个方法的执行总时间来表示。matrix监测FPS的主要实现在LooperMonitor和UIThreadMoniter两个类里。

  1. LooperMonitor为主线程Looper设置一个Printer来监听UI线程每个Message的开始、结束，从而得到Message的执行耗时。（方案同 BlockCanary ）
class LooperPrinter implements Printer {
    @Override
    public void println(String x) {
        ......
        dispatch(x.charAt(0) == '>', x);
    }
    
    private void dispatch(boolean isBegin, String log) {
        for (LooperDispatchListener listener : listeners) {
            if (isBegin) {
                listener.onDispatchStart(log);
            } else {
                listener.onDispatchEnd(log);
            }
         }
    }
}
  1. UIThreadMoniter通过java反射向Choreographer的CALLBACK_INPUT、CALLBACK_ANIMATION、CALLBACK_TRAVERSAL三个事件的callback队列的头部插入自定义callback。
```java
    //UIThreadMonitor.java
    @Override
    public void run() {
        doFrameBegin(token);
        doQueueBegin(CALLBACK_INPUT);

        addFrameCallback(CALLBACK_ANIMATION, new Runnable() {
            @Override
            public void run() {
                doQueueEnd(CALLBACK_INPUT);
                doQueueBegin(CALLBACK_ANIMATION);
            }
        }, true);

        addFrameCallback(CALLBACK_TRAVERSAL, new Runnable() {
            @Override
            public void run() {
                doQueueEnd(CALLBACK_ANIMATION);
                doQueueBegin(CALLBACK_TRAVERSAL);
            }
        }, true);
    }

前面提到Choreographer收到VSync信号时，也是往主线程消息队列里放入一个Message最终触发doFrame。而LooperMonitor监控了每个Message执行的开始/结束，如果UIThreadMonitor的doFrameBegin被执行，则说明当前在 Looper 中正在执行的消息就是渲染的消息。然后再在Message结束的时候作为当前帧绘制的结束。这个整个一帧的监控就闭环了。
所以在Matrix中，完整的一帧耗时是onDispatchStart -> doFrame -> onDispatchEnd。

因为UIThreadMonitor是在Choreographer的callback队列的头部添加callback，所以可用于记录每种类型callback队列执行的开始时间，在队列里的callback都执行完毕后，就可以计算对应的事件的耗时（CALLBACK_INPUT、CALLBACK_ANIMATION、CALLBACK_TRAVERSAL），比如CALLBACK_INPUT耗时 = CALLBACK_ANIMATION开始时间 - CALLBACK_INPUT开始时间。

所以Matrix不仅可以得到每一帧的耗时，还能进一步得到每一帧内触摸事件、动画、View渲染三种事件的耗时情况。

3 官方方案——JankStats

JankStats —— 是官方推出的Jetpack套件中的一个新库，最早发布于2022年2月，该库提供了在运行时获取界面的每帧性能的回调，可以让开发者监测到性能问题及其发生的原因。
项目中依赖：

dependencies {
    implementation "androidx.metrics:metrics-performance:1.0.0-alpha03"
}

简单使用：

val listener = JankStats.OnFrameListener { frameData ->
    // A real app could do something more interesting, like writing the info to local storage and later on report it.
    Log.v("JankStatsSample", frameData.toString())
}
jankStats = JankStats.createAndTrack(window, listener)
jankStats.isTrackingEnabled = true

简单几行代码就可以在OnFrameListener回调中获取每一帧的性能数据FrameData， 同时JankStats库还提供了PerformanceMetricsState供开发者记录当前的界面状态，并通过FrameData回调出来，有助于了解用户在那一帧期间做了什么交互。

open class FrameData(
    frameStartNanos: Long,//当前帧开始时间
    frameDurationUiNanos: Long,//当前帧耗时
    isJank: Boolean,//是否发生了卡顿
    val states: List<StateInfo>//业务代码记录的UI状态，可以通过PerformanceMetricsState在关键业务代码处埋点
)

原理

JankStats是一个典型的Android X库：在不同的Android版本和不同的设备上，实现行为一致的框架。

    class JankStats private constructor(window: Window, private val frameListener: OnFrameListener) {
        init {
            val decorView: View? = window.peekDecorView()
            implementation =
                when {
                    Build.VERSION.SDK_INT >= 31 -> {
                        JankStatsApi31Impl(this, decorView, window)
                    }
                    Build.VERSION.SDK_INT >= 26 -> {
                        JankStatsApi26Impl(this, decorView, window)
                    }
                    Build.VERSION.SDK_INT >= 24 -> {
                        JankStatsApi24Impl(this, decorView, window)
                    }
                    Build.VERSION.SDK_INT >= 22 -> {
                        JankStatsApi22Impl(this, decorView)
                    }
                    Build.VERSION.SDK_INT >= 16 -> {
                        JankStatsApi16Impl(this, decorView)
                    }
                    else -> {
                        JankStatsBaseImpl(this)
                    }
                }
        }
    }

阅读源码可以发现监测机制在API 24（7.0）前后有差异：
Android7.0及其以上系统，直接通过 Window 的新方法addOnFrameMetricsAvailableListener，监听回调每一帧的详细数据FrameMetrics：

internal open class JankStatsApi24Impl() {
    @RequiresApi(24)
    private fun Window.getOrCreateFrameMetricsListenerDelegator():
        DelegatingFrameMetricsListener {
        .....
            val delegates = mutableListOf<Window.OnFrameMetricsAvailableListener>()
            delegator = DelegatingFrameMetricsListener(delegates)
            //Window的这个方法可以监听每一帧的详细数据
            addOnFrameMetricsAvailableListener(delegator, frameMetricsHandler)
        }
        return delegator
    }
}

Android7.0以下设备，还是需要基于Choreographer，通过反射 Choreographer 的 mLastFrameTimeNanos 来获取当前帧的起始时间，然后通过 ViewTreeObserver的 OnPreDrawListener来感知绘制的开始，并往主线程的消息队列头部插入runnable来获取当前帧的UI线程绘制任务结束时间。

//JankStatsApi16Impl.kt
internal open class DelegatingOnPreDrawListener() : ViewTreeObserver.OnPreDrawListener {
    override fun onPreDraw(): Boolean {
        val frameStart = getFrameStartTime()
        with(decorView) {
            //往主线程的消息队列头部插入runnable
            handler.sendMessageAtFrontOfQueue(Message.obtain(handler) {
                val now = System.nanoTime()
                val frameTime = now - frameStart//获得每帧绘制的真实耗时
            })
        }
        return true
    }
    
    //反射 Choreographer 的 mLastFrameTimeNanos
    private fun getFrameStartTime(): Long {
        return choreographerLastFrameTimeField.get(choreographer) as Long
    }
}

获取到了当前帧的起始时间和绘制的Message结束时间，则可以计算出每帧绘制的真实耗时frameTime = now - frameStart

方案对比

  1. Choreographer的FrameCallback
    • 优点：
      • 简单可靠，维护成本低，使用稳定性高的系统开放API
    • 缺点：
      • 调用postFrameCallback()会不断地请求Vsync(scheduleVsyncLocked())，当界面静止时，UI线程也会不断请求VSync信号。主线程不干活的时候也会监测，可能会把有卡顿的场景的数据给稀释掉了。
      • 获取到的帧耗时并不是真实的每帧绘制耗时，而获取到≥16ms的两次doFrame的时间间隔。
    • 适用场景：
      • 比较粗粒度的掉帧数、卡顿监控。
  2. Matrix（Choreographer + Looper）
    • 优点：
      • 可以对UI线程绘制的不同阶段耗时进行较细致的监控
      • 不需要postFrameCallback，避免不断请求VSync信号
    • 缺点：
      • 维护成本高，对系统api侵入式较强，大量地通过反射来hook Choreographer和Looper，容易出现兼容问题，高版本系统可能会失效
      • 只统计了Choreographer的callback队列执行的耗时，即UI操作相关的耗时，没有包含两个VSYNC之间产生的其它非UI操作相关的message的耗时，因此统计出来的帧耗时可能偏低。
    • 适用场景：
      • 比较精细化的卡顿监控
  3. JankStats
    • 优点：
      • 官方方案，兼容性好，使用简单，可靠稳定。是在系统源码里进行埋点监测并收集数据。
      • 数据详尽，FrameMetrics提供了第三方框架难以采集的详细数据，包含总耗时，input、layout&measure、draw甚至是 sync bitmap到GPU的耗时等等（据说和adb shell dumpsys gfxinfo和GPU呈现模式分析的数据一致）

最后

我见过很多技术leader在面试的时候，遇到处于迷茫期的大龄程序员，比面试官年龄都大。这些人有一些共同特征：可能工作了7、8年，还是每天重复给业务部门写代码，工作内容的重复性比较高，没有什么技术含量的工作。问到这些人的职业规划时，他们也没有太多想法。

其实30岁到40岁是一个人职业发展的黄金阶段，一定要在业务范围内的扩张，技术广度和深度提升上有自己的计划，才有助于在职业发展上有持续的发展路径，而不至于停滞不前。

不断奔跑，你就知道学习的意义所在！

以上进阶BATJ大厂学习资料可以免费分享给大家，需要完整版的朋友，【点这里可以看到全部内容】。

avatar
文章
阅读
粉丝