gfxinfo 显示 FPS 60UI 流畅度满分。但用户投诉“视频播放时一顿一顿的”。你查了半天帧耗时数据全是正常帧。问题出在哪答案视频帧和 UI 帧是两条完全独立的管线。gfxinfo 只统计 UI 帧视频帧走的是 MediaCodec → Surface 的解码通道。你采的是 A 的数据用户投诉的是 B 的问题。一、视频帧 vs UI 帧两条管线Android 里有两种帧走不同的渲染通道采集方式也完全不同┌─────────────────────────────────────────────────────┐ │ UI 帧管线 │ │ │ │ Choreographer → UI 线程 → RenderThread → Surface A │ │ │ │ 帧率上限 屏幕刷新率60/90/120Hz │ │ 数据源 dumpsys gfxinfo │ └─────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────┐ │ 视频帧管线 │ │ │ │ 网络/文件 → 解封装 → MediaCodec 解码 → Surface B │ │ │ │ 帧率 视频源帧率24/25/30/60fps │ │ 数据源 SurfaceFlinger通用/ media.codec辅助 │ └─────────────────────────────────────────────────────┘ 两个 Surface 最终都交给 SurfaceFlinger 合成到屏幕上。 ↑ 这是检测视频卡顿的关键切入点维度UI 帧视频帧触发方式VSYNC 信号 界面变化视频流的帧间隔帧率上限屏幕刷新率视频编码帧率渲染者App 的 RenderThreadMediaCodec 硬/软解码器卡顿原因布局复杂、主线程阻塞解码慢、buffer 不足、网络卡、音画同步采集工具dumpsys gfxinfoSurfaceFlinger最通用采集时机始终采集仅在视频播放场景启用二、残酷的现实主流 App 几乎绕过了标准播放器 API很多文章推荐用dumpsys media.player来检测视频卡顿。但在实际测试中这个命令对主流视频 App 无效。Android 标准路径App → android.media.MediaPlayer API → MediaPlayerService → 解码 → Surface ↑ dumpsys media.player 采数据的位置主流 App 的实际路径抖音 → TTVideoEngine字节自研引擎→ MediaCodec → Surface 快手 → KSVideoPlayer自研引擎 → MediaCodec → Surface 爱奇艺 → 自研播放器引擎 → MediaCodec → Surface 腾讯视频 → TXLiteAVSDK自研引擎 → MediaCodec → Surface B站 → IJKPlayerFFmpeg 魔改 → MediaCodec / FFmpeg → Surface 优酷 → 阿里自研引擎 → MediaCodec → Surface这些 App 都绕过了android.media.MediaPlayerAPIdumpsys media.player对它们无效。但不管用什么播放器引擎解码后的视频帧最终都必须提交给 SurfaceFlinger 合成上屏。SurfaceFlinger 是所有视频帧的必经之路任何播放器引擎 │ ┌────┴────┐ │ 硬解码 │ 软解码 │MediaCodec│ FFmpeg └────┬────┘ ┘ │ │ ┌────┴──────┴────┐ │ Surface │ ← 所有视频帧必经之路 └────────┬───────┘ │ ┌────────┴───────┐ │ SurfaceFlinger │ ← 在这里截获帧时间戳 └────────┬───────┘ │ 屏幕三、三种数据源通用性对比3.1 SurfaceFlinger --latency主方案通用原理视频通过 SurfaceView 渲染时SurfaceFlinger 记录每帧的上屏时间戳。通过分析相邻帧的时间差可以检测丢帧和卡顿。操作方法播放视频后通过dumpsys SurfaceFlinger --list查找目标 App 的 SurfaceView layer对该 layer 执行dumpsys SurfaceFlinger --latency获取最近 ~128 帧的时间戳提取每帧的actualPresentTime第 2 列实际上屏时间过滤掉无效帧0x7FFFFFFFFFFFFFFF表示未上屏计算相邻帧时间差 → 得到帧间隔序列从帧间隔序列推导所有视频性能指标输出格式说明行内容说明第 1 行16666666屏幕刷新周期纳秒16666666 60Hz后续每行3 列纳秒时间戳第 1 列desiredPresentTime期望上屏时间第 2 列actualPresentTime实际上屏时间第 3 列frameReadyTime帧就绪时间一个关键限制——SurfaceView vs TextureView渲染方式SurfaceFlinger 能分离视频帧吗使用场景SurfaceView能独立 layer大部分全屏视频播放TextureView不能和 UI 共享 Surface部分小窗播放、弹幕叠加判断方法播放视频后查看dumpsys SurfaceFlinger --list是否出现SurfaceView[包名/...]的 layer。有 → SurfaceView没有 → TextureView。3.2 dumpsys media.codec辅助方案原理大部分 App 使用MediaCodecAPI 硬件解码该命令提供解码器级统计。能提供什么信息说明解码器名称判断硬解OMX.qcom./c2.qti.还是软解OMX.google./c2.android.丢弃帧数output buffers dropped部分设备可用平均/最大解码耗时判断解码性能是否足够部分设备可用局限纯 FFmpeg 软解码不走 MediaCodec此时无数据。字段名和格式随 Android 版本差异大。3.3 dumpsys media.player有限场景适用范围极窄——只有使用android.media.MediaPlayer原生 API 的 App 才有数据。播放器是否有效系统原生 MediaPlayer有效自研 App确认用原生 API有效抖音 / 快手 / 爱奇艺 / B站无效IJKPlayer / ExoPlayer无效3.4 三种方案总览能力SurfaceFlingermedia.codecmedia.player主流 App 通用性全覆盖大部分极少数帧间隔序列有无无丢帧数/丢帧率有从帧间隔推导有有帧间隔 CV有无无连续丢帧检测有无无视频实际帧率有间接间接解码耗时无有无解码方式硬/软无有无TextureView 场景不可用可用看实现推荐策略SurfaceFlinger 为主 media.codec 为辅。SurfaceFlinger 提供帧级时间戳分析media.codec 提供解码性能数据两者互补。四、SurfaceFlinger 帧间隔分析方法SurfaceFlinger 输出的原始数据是纳秒时间戳序列核心分析方法是从时间戳 → 帧间隔 → 指标4.1 从时间戳到帧间隔SurfaceFlinger 输出的 actualPresentTime 序列纳秒 T1, T2, T3, T4, T5, ... 帧间隔序列毫秒 (T2−T1)/1000000, (T3−T2)/1000000, (T4−T3)/1000000, ...以 30fps 视频为例理想帧间隔 1000 / 30 33.3ms实际帧间隔序列ms 33.2, 33.4, 33.1, 33.5, 33.2, 66.8, 33.3, 33.4, 33.1, 33.5, ... ↑ 66.8ms ≈ 2× 理想间隔 → 丢了 1 帧4.2 丢帧判定规则帧间隔 1.5× 理想间隔 → 判为丢帧为什么是 1.5 倍而不是 1.0 倍因为即使正常播放帧间隔也有轻微波动。1.5 倍留出合理容差视频帧率理想间隔丢帧阈值1.5×含义24fps41.7ms62.5ms间隔 62.5ms 视为丢帧30fps33.3ms50.0ms间隔 50.0ms 视为丢帧60fps16.7ms25.0ms间隔 25.0ms 视为丢帧4.3 从帧间隔推导丢帧数量帧间隔 66.8ms理想间隔 33.3ms 丢帧数 round(66.8 / 33.3) − 1 round(2.0) − 1 1 帧 帧间隔 133.6ms理想间隔 33.3ms 丢帧数 round(133.6 / 33.3) − 1 round(4.0) − 1 3 帧4.4 连续丢帧检测丢帧率相同但分布不同体验天差地别场景 A1000 帧中10 个不同位置各丢 1 帧 丢帧率 1%卡顿 10 次每次 33ms 用户感受轻微、分散可能不注意 场景 B1000 帧中1 个位置连续丢 10 帧 丢帧率 1%卡顿 1 次持续 333ms 用户感受明显冻帧一定会投诉方法遍历帧间隔序列记录连续超阈值的最大长度。最大连续丢帧数直接决定用户感受到的最严重卡顿。4.5 注意事项过滤无效时间戳0x7FFFFFFFFFFFFFFFINT64_MAX表示帧尚未上屏必须过滤掉过滤异常大间隔帧间隔 5000ms 通常是暂停/切后台不算卡顿视频帧率自动检测无需手动指定视频帧率。先采集一段数据取帧间隔的中位数然后匹配最近的标准帧率24/25/30/48/50/60fps作为 expected_fps。这样同一个工具可以自动适配不同帧率的视频源buffer 上限与去重SurfaceFlinger 最多保留 ~128 帧且--latency不会被 reset 清空——每次调用返回的是最近 128 帧的完整缓冲区。因此必须记录上一轮最后时间戳过滤已处理的旧帧否则同一帧会被重复计数。采集间隔建议30fps 视频 ≤ 4 秒60fps 视频 ≤ 2 秒多 Layer 遍历视频播放时可能存在多个 SurfaceView如视频 弹幕应遍历所有匹配包名的 layer取帧数最多的作为视频指标五、完整指标体系本节定义 10 个视频质量指标。5.1 / 5.2 讲解各指标的定义和计算方式所有判定阈值统一汇总在 5.3 的检查清单中含行业标准对照。5.1 核心指标SurfaceFlinger 可直接获取指标 1视频丢帧率丢帧率 帧间隔超阈值的帧数 / 总帧数 × 100%指标 2视频帧率达成率实际帧率 1000 / 帧间隔均值ms 帧率达成率 实际帧率 / 源帧率 × 100%指标 3帧间隔 CV变异系数CV 帧间隔标准差 / 帧间隔均值和 UI 帧的 CV#12 第五节概念一致但参考基准不同UI 帧的理想间隔 VSYNC 周期屏幕刷新率决定视频帧的理想间隔 视频源帧间隔编码帧率决定指标 4最大连续丢帧数 最大卡顿时长指标计算方式含义最大连续丢帧数连续超阈值帧间隔的最大长度最严重一次冻帧持续几帧最大卡顿时长最大帧间隔值ms最长一次画面停顿多久卡顿次数超阈值帧间隔的总次数发生了几次画面不连续判定标准完整四级阈值见 5.3 检查清单指标优秀良好警告严重最大连续丢帧≤ 1 帧≤ 3 帧4 ~ 6 帧 6 帧最大卡顿时长 50ms 100ms100 ~ 200ms 200ms卡顿次数 / 分钟≤ 1≤ 34 ~ 6 65.2 辅助指标指标 5首帧时间First Frame Latency用户点击播放到第一帧画面渲染到屏幕的延迟。采集方法记录操作时间 T0播放后轮询 SurfaceFlinger第一个有效帧时间戳 T1 出现时首帧时间 T1 − T0。指标 6解码耗时需 media.codec指标阈值建议说明平均解码耗时 视频帧间隔 × 50%30fps → 平均 16.7msP90 解码耗时 视频帧间隔 × 80%30fps → P90 26.7ms最大解码耗时 视频帧间隔30fps → 最大 33.3ms从解码器名称判断解码方式前缀解码方式性能OMX.qcom./OMX.mtk./c2.qti.硬件解码快功耗低OMX.google./c2.android.软件解码慢依赖 CPU指标 7音画同步偏移A/V Sync国际标准ITU-R BT.1359定义了音视频同步的可感知和可接受阈值。人耳对声音先于画面的容忍度远低于声音滞后于画面因此标准阈值是不对称的偏移方向可感知阈值可接受阈值说明音频提前声先于画45ms90ms人眼更敏感容忍度低音频滞后画先于声−125ms−185ms容忍度相对高简化参考测试实用偏移 ±20ms 以内无感知±40ms 敏感用户可察觉±80ms 普通用户注意到唇形对不上 ±120ms 明显不同步。蓝牙耳机场景最容易出问题见场景 5。指标 8Buffer 健康度网络视频指标含义数据来源Buffering 次数buffer 耗尽导致播放暂停的次数logcat 关键词buffering / underrun / emptyBuffering 总时长累计等待数据的时间logcat / 播放器回调指标 9Seek 延迟Seek 延迟用户感知 100ms即时响应100~300ms轻微延迟 300ms明显等待5.3 统一判定标准 检查清单所有指标的判定阈值汇总如下。指标 1~5 是必检项来自 SurfaceFlinger通用性高指标 6~10 按场景选检。核心指标必检#指标数据源优秀良好警告严重红线1视频丢帧率SurfaceFlinger 0.1%0.1% ~ 1%1% ~ 3% 3%2帧率达成率SurfaceFlinger≥ 95%80% ~ 95%60% ~ 80% 60%3帧间隔 CVSurfaceFlinger 0.10.1 ~ 0.30.3 ~ 0.6 0.64最大连续丢帧SurfaceFlinger≤ 1 帧≤ 3 帧4 ~ 6 帧 6 帧5最大卡顿时长SurfaceFlinger 50ms50 ~ 100ms100 ~ 200ms 200ms辅助指标按场景选检#指标数据源优秀良好警告严重红线6首帧时间SurfaceFlinger 200ms200 ~ 500ms500ms ~ 1s 1s7解码耗时media.codec 帧间隔 × 50% 帧间隔 × 80% 帧间隔 帧间隔8A/V 同步偏移logcat / 播放器±20ms±40ms±80ms ±120ms9Buffer 健康度logcat / 播放器0 次暂停≤ 1 次2 ~ 3 次 3 次10Seek 延迟SurfaceFlinger 100ms100 ~ 200ms200 ~ 300ms 300ms5.4 行业标准对照我们的阈值不是拍脑袋定的参考了以下行业标准和工具标准 / 工具领域核心内容和我们的关系PerfDog腾讯移动端性能视频播放推荐 Jank 0Jank 判定采用前 3 帧均值 × 2 固定阈值双条件丢帧率 0.1%优秀对应 PerfDog 的接近零 JankW3C VideoPlaybackQualityWeb 视频droppedVideoFrames / totalVideoFrames 10%触发质量降级我们的红线3%严于 W3C 的 10%面向高品质产品ITU-R BT.1359音视频同步A/V 可感知音频提前 45ms / 滞后 −125ms可接受90ms / −185ms指标 8 直接对齐该标准ITU-T P.1203流媒体 QoE基于 MOS1-5 分的自适应流质量评估综合卡顿、启动、质量波动我们的指标覆盖了 P.1203 关注的核心维度Akamai QoE流媒体每次 rebuffering 降低 14% 满意度启动超 2s 用户开始流失首帧 200ms Buffer 0 次暂停与其一致ExoPlayer AnalyticsAndroid 播放器提供maxConsecutiveDroppedFrames可配置通知阈值无固定标准我们给出了具体的连续丢帧四级标准一句话总结我们的阈值整体严于W3C10%和 ExoPlayer无固定标准对齐PerfDog 和 ITU-R 标准面向高品质产品。帧间隔 CV 是我们的特色指标PerfDog / Perfetto 均未提供。六、数据源可用性验证流程拿到任何 App先做一轮数据源验证Step 1启动 App 并播放视频 Step 2检查 SurfaceFlinger 是否可用 → 执行 dumpsys SurfaceFlinger --list搜索 SurfaceView → 有 SurfaceView layer → SurfaceFlinger 方案可用最佳 → 无 SurfaceView layer → App 用 TextureView 渲染降级到 Step 3 Step 3检查 media.codec 是否可用 → 执行 dumpsys media.codec搜索 codec / drop / decode → 有解码器数据 → media.codec 可用 → 无数据 → 纯软解码回到 SurfaceFlinger大部分场景仍可用 Step 4检查 media.player大概率无效但值得一试 → 执行 dumpsys media.player搜索 numFrames → 有数据 → 额外数据源可用 → 无数据 → 符合预期主流 App 不走这条通道实测兼容性全屏 SurfaceView 播放AppSurfaceFlingermedia.codecmedia.player抖音可用可用不可用快手可用可用不可用爱奇艺可用可用不可用腾讯视频可用可用不可用B站可用可用硬解时不可用微信视频号可用可用不可用自研 AppMediaPlayer可用可用可用自研 AppExoPlayer可用可用不确定七、常见视频卡顿场景 诊断方法场景 1硬解码器繁忙现象多路视频同时播放如信息流部分视频卡顿。原因手机硬件解码器数量有限通常 4~8 路超出后降级为软解码CPU 负担加重。硬解码4.2ms/帧 → 远低于 33.3ms → 流畅 软解码25.8ms/帧 → 接近 33.3ms → 容易掉帧 CPU 降频后的软解码42ms/帧 → 超过 33.3ms → 必然掉帧诊断通过media.codec查看解码器名称OMX.google./c2.android.开头 软解。场景 2分辨率切换冻帧现象网络视频切换清晰度360p → 1080p时短暂冻帧。原因分辨率切换需要重建解码器200~500ms 间隙。SurfaceFlinger 表现帧间隔序列中出现一个 200~500ms 的异常间隔前后帧间隔正常。场景 3网络 buffering现象网络视频播放帧率忽高忽低。原因网络带宽不足解码器输入 buffer 空了。视频规格带宽需求参考30fps 1080p H.264≈ 5~8 Mbps30fps 4K H.265≈ 15~25 Mbps60fps 1080p H.264≈ 10~15 MbpsSurfaceFlinger 表现帧间隔序列中出现间歇性的大间隔数百毫秒夹杂正常间隔。CV 飙高。场景 4CPU 降频导致软解码变慢现象长时间播放后越来越卡。原因设备发热后 CPU 降频软解码器算力不足参考 CPU 系列 #7。诊断交叉分析 CPU 频率比趋势下降和 SurfaceFlinger 帧间隔 CV趋势上升。场景 5A/V 同步异常蓝牙耳机现象连接蓝牙耳机后视频声音和画面对不上。蓝牙编码固有延迟说明SBC170~270ms默认编码延迟最高AAC120~200msiOS 常用Android 上延迟偏高aptX100~250ms标准 aptX中等延迟aptX Low Latency 40ms游戏/视频专用需耳机支持LDAC200~250ms追求音质延迟最高之一LC3LE Audio20~40ms新一代蓝牙低延迟标准场景 6帧率与刷新率不匹配Judder现象24fps 电影在 60Hz 屏幕上有轻微抖动感但不丢帧。原因24 不能整除 60每帧显示时长不均匀3:2 pulldown。24fps 在 60Hz 每帧交替显示 3 或 2 个 VSYNC → 帧间隔交替 50ms/33ms → judder 24fps 在 120Hz每帧固定显示 5 个 VSYNC → 帧间隔恒定 41.7ms → 无 judder 30fps 在 120Hz每帧固定显示 4 个 VSYNC → 帧间隔恒定 33.3ms → 无 judderSurfaceFlinger 表现帧间隔交替出现两种值丢帧率 0%但 CV 偏高 0.2。识别方法丢帧率正常 CV 偏高 帧间隔呈规律性交替 → 大概率是 Judder不是 bug。八、与 UI 帧率的联动分析视频播放和 UI 交互往往同时发生边看视频边滑评论需要同时采集两路数据。联合诊断决策表症状UI 帧率视频帧间隔CPU 频率比可能原因排查方向UI 卡视频不卡低CV 正常正常UI 线程阻塞帧耗时阶段拆解#12UI 不卡视频卡正常CV 高 / 丢帧多正常解码器瓶颈 / buffer 不足media.codec 解码耗时都卡低CV 高低CPU 降频整机算力不足CPU 频率比趋势#7都卡低CV 高正常CPU 被占满top / CPU 核心利用率#8都不卡但音画不同步正常CV 正常正常蓝牙延迟 / 同步逻辑 bug蓝牙编码类型、播放器日志都不卡但画面抖正常CV 偏高正常帧率/刷新率不整除确认 Judder场景 6采集频率建议数据采集方式建议间隔UI 帧率 卡顿dumpsys gfxinfo1~2 秒视频帧间隔SurfaceFlinger --latency2~4 秒解码统计dumpsys media.codec5~10 秒CPU 频率/负载/proc/stat cpufreq5~10 秒九、不同场景的指标优先级不同视频场景关注的指标不同场景必检指标辅助指标可忽略本地视频播放丢帧率、CV、最大连续丢帧解码耗时Buffer、Seek短视频抖音/快手首帧时间、Seek 延迟、丢帧率BufferA/V 同步长视频爱奇艺/腾讯丢帧率、A/V 同步、CVBufferSeek直播Buffer 健康度、丢帧率、首帧时间CVSeek多路视频信息流丢帧率、解码方式硬/软CPU 负载A/V 同步、Seek短视频最核心的指标是首帧时间——用户刷视频时每个视频都有一次首帧加载。首帧慢 每刷一个视频都卡一下。小结知识点一句话核心问题gfxinfo 只采 UI 帧采不到视频帧——两条独立管线通用方案SurfaceFlinger--latency是唯一真正通用的视频卡顿检测方案原理不管什么播放器视频帧最终都提交到 Surface → SurfaceFlinger 上屏SurfaceFlinger 限制TextureView 渲染场景无法分离视频帧需降级 media.codecmedia.player对抖音/快手/爱奇艺等主流 App无效分析方法时间戳 → 帧间隔序列 → 丢帧/CV/连续丢帧/实际帧率必检指标丢帧率、帧率达成率、CV、最大连续丢帧、最大卡顿时长判定标准四级分档优秀/良好/警告/严重对齐 PerfDog、ITU-R BT.1359 等行业标准和 UI 的关系视频帧 UI 帧 CPU 数据三路联合诊断下一篇我们把 FPS 系列所有指标整合到一起给出完整的采集落地方案——从脚本架构到自动化报告。系列目录第 1~4 篇内存泄漏检测 内存采集避坑第 5~9 篇CPU 采集系列入门 → 避坑 → 降频 → 单核 → 落地第 10 篇FPS 帧率采集入门第 11 篇FPS 采集的 8 个坑第 12 篇UI 卡顿量化——用数据回答到底有多卡第 13 篇本篇视频播放卡顿检测第 14 篇下一篇FPS 采集落地方案我是测试工坊专注 Android 系统级性能工程。如果你也在做帧率相关的性能测试欢迎评论区交流 关注我后续更新不迷路。