2、多媒体启动卡顿现象：典型表现，用户感知

说到多媒体启动卡顿，很多同学第一反应就是「打开播放器转圈圈」。但说实话，真实用户场景远比这复杂。我自己跟过好几个ANR case，发现用户投诉里描述的现象五花八门——有的说「点了播放没反应」，有的说「画面卡在首帧，声音已经跑了」，还有的直接吐槽「手机死机了」。

嗯，这些描述背后其实对应着不同的技术阶段。我们做性能优化，首先得搞清楚：用户到底在感知什么？

典型表现分类

我习惯把多媒体启动卡顿的表现分成三个维度：视觉层、听觉层、交互层。下面这个表格是我做项目时整理的对照表，基本上能覆盖90%以上的用户投诉场景。

从用户投诉反推技术指标

你看，用户说的「没反应」，可能是UI线程卡住（主线程执行了耗时操作）；用户说的「音画不同步」，本质是音视频解码器初始化顺序或时间差没控制好。我最早接手这类问题时也一头雾水，后来学会了一个笨办法——先把用户描述翻译成可量化的指标。

1. 启动总耗时：从用户点击到第一帧呈现，业界基准是 < 1.5秒，超过3秒ANR风险极高。
2. 首帧渲染延迟：SurfaceFlinger合成第一帧的时间戳，理想值 < 300ms。
3. 音频起步延迟：AudioTrack写入第一个buffer到audiotrack开始回调，建议 < 200ms。
4. UI线程空闲率：启动期间主线程执行非UI操作的比例，超过70%就是危险信号。

这些指标在ANR日志里都能找到蛛丝马迹。举个例子，我记得有一次线上反馈「播放器点击没反应，延迟10秒」，我抓了trace一看，主线程卡在MediaCodec.configure()上，调用栈显示它正在执行了一个Looper.loop()死循环——这就是典型的解码器初始化线程把UI线程给阻塞了。

我遇到过的真实案例

说个自己踩过的坑吧。之前做一个短视频App的启动优化，测试同学报了个bug：在低端机上点击视频后屏幕黑了6秒才出画面。我一开始以为是IO读取慢，查了磁盘性能没问题。后来把系统层ANR日志拉下来，发现CPU负载很低，但主线程一直在等一个ConditionVariable——是哪个线程还没准备好呢？

一路跟踪下去，发现是MediaExtractor在刚创建时就去解析整个文件头，而那个视频文件恰好没有moov box（元数据在文件尾），导致它需要把整个文件都读取完才能开始解析。这一下就多了5秒的IO等待。

避坑指南

• 不要只看总耗时：我曾以为只要启动总耗时 < 2秒就安全，结果用户还是投诉「点了没反应」。后来发现是首帧出现时间晚于用户预期——哪怕只晚了1秒，用户的忍耐极限也会被突破。
• 注意「假启动」：有些App在预加载阶段就创建了SurfaceView，但实际播放时又销毁重建，这会导致SurfaceHolder的surfaceCreated回调在启动时被重复触发。我在一个合作项目里就因为这个原因，每次播放都会多一次黑屏闪动，大家排查了三天才发现。
• 音频初始化不能异步化过度：把音频解码器创建放到子线程确实能避免阻塞UI，但如果音频ready得太晚，用户听到的第一声就是「噗——啪」的爆音，比卡顿更劝退。