Android应用卡顿监控方案原理和对比

最新推荐文章于 2024-05-15 01:39:51 发布

idaretobe

最新推荐文章于 2024-05-15 01:39:51 发布

阅读量218

点赞数

文章标签： android

原文链接：https://zhuanlan.zhihu.com/p/639896487

版权

0 介绍

要监控应用界面是否发生卡顿，需要先了解一下Android应用主线程的渲染机制：
Android 系统提供一个稳定的帧率输出机制，让软件层和硬件层可以以共同的频率一起工作,使我们可以享受稳定帧率的画面。

大部分手机的屏幕都是60Hz的刷新率，系统为了配合屏幕的刷新频率，每过16.6ms就会发出Vsync信号来通知应用进行绘制。如果每个Vsync周期应用都能完成渲染逻辑，那么应用的FPS就是60，给用户的感觉就是非常流畅。

在应用层，实现上述机制的关键类就是Choreographer。每隔16.6ms，Vsync 信号唤醒 Choreographer来做应用的绘制操作。

想要监控卡顿或者是监测App的流畅度，就必须通过代码手段来获取FPS或者每帧耗时，并转化成可以衡量应用卡顿程度的指标。而几乎所有的卡顿监控方案都离不开Choreographer这个类。所以先简单说说Choreographer：

Choreographer

在应用层就是通过Choreographer来接受VSync信号并执行每一帧的渲染逻辑。
每当Vsync到来时，会往主线程消息队列里添加一个Message，最终其doFrame函数将被调用：

//Choreographer.java
public void onVsync(long timestampNanos, long physicalDisplayId, int frame) {
    ......
    mTimestampNanos = timestampNanos;
    mFrame = frame;
    Message msg = Message.obtain(mHandler, this);
    msg.setAsynchronous(true);
    mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS);
}

public void run() {
    ......
    doFrame(mTimestampNanos, mFrame);
}

doFrame函数中执行了应用层的callback，基本上包含了一帧的渲染工作：

//Choreographer.java
void doFrame(long frameTimeNanos, int frame) {
    //自带了掉帧计算
    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.");
        }
    }
    ......
    doCallbacks(Choreographer.CALLBACK_INPUT, frameTimeNanos);
    doCallbacks(Choreographer.CALLBACK_ANIMATION, frameTimeNanos);
    doCallbacks(Choreographer.CALLBACK_INSETS_ANIMATION, frameTimeNanos);
    doCallbacks(Choreographer.CALLBACK_TRAVERSAL, frameTimeNanos);
    doCallbacks(Choreographer.CALLBACK_COMMIT, frameTimeNanos);
    ......
}

其中CALLBACK_ANIMATION是处理动画相关的逻辑，而CALLBACK_TRAVERSAL则会调用到ViewRootImpl的performTraversals() 函数，从而执行到我们所熟悉的View的measure、layout、draw三大流程。

所以可以说，doFrame() 函数包含了应用层绘制一帧的逻辑处理。

由于Choreographer处于如此重要的一个位置，基本上所有的卡顿监控都会围绕着Choreographer进行的，除了自带的掉帧计算，Choreographer 提供的 FrameCallback 和 FrameInfo都是应用层可以直接访问的接口。

下面介绍一下市面上开源方案的几种实现方式和简单对比。

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两个类里。

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);
            }
         }
    }
}

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

方案对比

Choreographer的FrameCallback

优点：
- 简单可靠，维护成本低，使用稳定性高的系统开放API
缺点：
- 调用postFrameCallback()会不断地请求Vsync(scheduleVsyncLocked())，当界面静止时，UI线程也会不断请求VSync信号。主线程不干活的时候也会监测，可能会把有卡顿的场景的数据给稀释掉了。
- 获取到的帧耗时并不是真实的每帧绘制耗时，而获取到≥16ms的两次doFrame的时间间隔。
适用场景：
- 比较粗粒度的掉帧数、卡顿监控。

Matrix（Choreographer + Looper）

优点：
- 可以对UI线程绘制的不同阶段耗时进行较细致的监控
- 不需要postFrameCallback，避免不断请求VSync信号
缺点：
- 维护成本高，对系统api侵入式较强，大量地通过反射来hook Choreographer和Looper，容易出现兼容问题，高版本系统可能会失效
- 只统计了Choreographer的callback队列执行的耗时，即UI操作相关的耗时，没有包含两个VSYNC之间产生的其它非UI操作相关的message的耗时，因此统计出来的帧耗时可能偏低。
适用场景：
- 比较精细化的卡顿监控

JankStats

优点：
- 官方方案，兼容性好，使用简单，可靠稳定。是在系统源码里进行埋点监测并收集数据。
- 数据详尽，FrameMetrics提供了第三方框架难以采集的详细数据，包含总耗时，input、layout&measure、draw甚至是 sync bitmap到GPU的耗时等等（据说和adb shell dumpsys gfxinfo和GPU呈现模式分析的数据一致）
- 使用便捷，内置规则判断当前帧是否卡顿帧，并可以记录当前帧的应用状态。
- 界面停止绘制时，不再生产帧率数据，避免脏数据。
缺点：
- 不支持个性化的定制需求。
- 库还只是alpha版本，不是成熟的release版本，如果有坑则只能等官方更新。
- 集成到老项目时不友好，可能需要升级AndroidX核心库、kotlin插件甚至gradle插件版本，代价大。
适用场景：
- 新项目，需要快速实现卡顿监控

结论

上面三种方案都可以获得当前应用的FPS，要基于项目情况去考虑方案选型。大型项目一般更倾向于维护成本低、稳定性高的基于系统开放API的方案，所以Choreographer的FrameCallback应该是使用最广泛的方案了。
采集到FPS只是应用卡顿监控的第一步，还需要制定科学的卡顿率指标。因为FPS并不能直观的反映应用的卡顿情况，还需要考虑“视觉惯性”，比如电影帧率仅24FPS也不觉得卡顿，但是应用如果一会30FPS一会60FPS，视觉上就会觉得很不流畅。

idaretobe

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
Android应用卡顿监控方案原理和对比

要监控应用界面是否发生卡顿，需要先了解一下Android应用主线程的渲染机制：Android 系统提供一个稳定的帧率输出机制，让软件层和硬件层可以以共同的频率一起工作,使我们可以享受稳定帧率的画面。大部分手机的屏幕都是60Hz的刷新率，系统为了配合屏幕的刷新频率，每过16.6ms就会发出Vsync信号来通知应用进行绘制。如果每个Vsync周期应用都能完成渲染逻辑，那么应用的FPS就是60，给用户的感觉就是非常流畅。在应用层，实现上述机制的关键类就是。
复制链接

扫一扫