启动性能瓶颈分析：创建实例、准备资源、解码器初始化
做多媒体开发的朋友应该都有体会——App 启动时，MediaPlayer 的初始化经常是卡顿重灾区。我早年做过一个短视频 App，冷启动时播放器初始化居然占了 800 多毫秒，用户都刷走两个视频了还没播出来。嗯，今天咱们就来拆解一下，这 800 毫秒到底花在了哪里。
启动性能瓶颈说白了就三个大环节：创建实例、准备资源、解码器初始化。这三步跑完，播放器才能开始干活。你想想看，每一步里都有哪些容易拖后腿的坑？
创建实例的瓶颈
new MediaPlayer() 看起来就是个构造方法，能有多慢？我以前在低端机上测过，光是这行代码平均值就要 80-120ms。为什么会这样？
- Java 反射调用：MediaPlayer 构造方法内部会通过 JNI 调用 native 方法，底层还要反射加载一些系统服务。反射的开销在低端机上特别明显。
- Native 层动态加载：创建实例时会触发 libmediaplayer.so 等一堆动态库的加载。如果这些库还没被系统缓存，光加载链接就能吃掉几十毫秒。
我的一点小经验：不要在 UI 线程跑 new MediaPlayer()。曾经有个项目，所有播放器实例都在主线程创建，结果列表滑动时明显掉帧。后来改成预创建池，提前在线程池里 new 好，问题就解决了。
准备资源的瓶颈
setDataSource() 看起来只是给播放器一个路径，实际上内部要做的事不少。你想想看：
- 文件 I/O：对于本地文件，播放器需要打开文件描述符，甚至要预读一小段数据来判断媒体格式。如果文件在 SD 卡上，I/O 时延能到几十毫秒。
- 网络请求：对于网络流，这一步会触发 DNS 解析和 TCP 连接。我在做直播 App 时发现，弱网环境下 setDataSource 有可能超时 3 秒——嗯，那会儿用户已经怒气值满格了。
避坑指南：我曾经因为没检查 URI 有效性，在 Debug 版上 setDataSource 被系统弹了个异步异常，导致后续 prepare 失败。建议先验证 URI 或文件可读性，再传给 MediaPlayer。
解码器初始化的瓶颈
这是启动性能的「大头」，经常占到总耗时的 50% 以上。prepareAsync() 或 prepare() 内部会经历：
- 媒体格式探测：解析文件头，确定音视频编码格式（H.264、AAC 等）。
- 编解码器查找：Android 系统要通过 MediaCodecList 遍历所有可用的解码器。我见过某些定制 ROM 上有 20+ 个编解码器，遍历一遍就要 30ms。
- 硬件/软件解码决策：如果目标格式支持硬件解码，系统会尝试初始化硬件解码器。硬件解码器首次启动时，需要加载驱动、分配显存，这部分在我的项目里测到过 200ms+。
核心数据：一次典型的 prepare() 调用耗时分布
| 阶段 | 耗时范围 | 占比 |
|---|---|---|
| 媒体格式探测 | 20-60ms | 15% |
| 编解码器查找 | 10-40ms | 10% |
| 硬件解码器初始化 | 100-300ms | 65% |
| 其他（同步等待等） | 10-30ms | 10% |
如果你注意看 Logcat，会发现 MediaCodec 在初始化时会输出类似 initCodec: OMX.qcom.video.decoder.avc 的日志。这里的硬件编码器加载才是真正的性能杀手。我个人习惯是：如果确定要频繁播放同一格式的视频，可以预创建 MediaCodec 实例并把解码器预热好，这样后面第一次播放就能省掉那几百毫秒。
另外要注意的是：prepare() 是同步操作，在 4.0 以上强烈建议用 prepareAsync() 配合监听器。但就算异步，底层解码器初始化的耗时一点不会少，只是不卡 UI 线程罢了。避坑提醒：异步 prepare 时不能立刻调用 start()，否则会抛异常——我曾经踩过这个坑。