预创建实例的原理：复用实例 vs 按需创建

核心思想：把时间花在启动前

预创建 MediaPlayer 实例，说白了就是一句话——把创建对象的耗时，从用户点击那一刻，挪到应用启动阶段。你想想看，用户点播放按钮的时候，最怕什么？转圈、卡顿、黑屏。如果这时候才去 new MediaPlayer()、配置数据源、准备缓冲区，那几秒钟的等待足以让用户体验跌到冰点。

我个人习惯把这个思路称为「时间换位法」。不减少总工作量，只是把工作提前干完。就像你早上出门前准备好午餐便当，中午直接吃，不用排队等外卖。

我曾经在一个短视频项目中踩过坑。用户快速滑动时，每个视频都要新建 MediaPlayer，结果滑动越快，卡顿越明显。后来改成预创建 3 个实例轮换复用，滑动流畅度直接提升了 40%。嗯，那次之后我就彻底信了预创建的威力。

复用实例：一个萝卜一个坑

复用实例，就是预先创建好一批 MediaPlayer 对象，用的时候从池子里取，用完放回去。说白了，对象池模式。但这里有个关键——MediaPlayer 不是普通对象，它有状态、有资源、有生命周期。

复用的核心条件：

• 状态重置：每次复用前必须调用 reset()，把内部状态清干净
• 资源解绑：上一段视频的 surface、音频焦点、文件描述符都要释放
• 线程安全：池子的存取操作要做好同步，别两个线程抢同一个实例

我建议把复用池设计成 LIFO（后进先出） 结构。为什么？因为刚用完的实例大概率还热在缓存里，重新绑定数据源更快。我自己在项目里做过测试，LIFO 比 FIFO 平均快 12% 左右。

// 一个简单的 MediaPlayer 复用池骨架
public class MediaPlayerPool {
    private final Deque<MediaPlayer> pool = new LinkedList<>();
    private final int maxSize;

    public MediaPlayerPool(int maxSize) {
        this.maxSize = maxSize;
        preCreate();
    }

    private void preCreate() {
        for (int i = 0; i < maxSize; i++) {
            MediaPlayer mp = new MediaPlayer();
            mp.reset();  // 确保初始状态干净
            pool.push(mp);
        }
    }

    public MediaPlayer acquire() {
        MediaPlayer mp = pool.poll();
        if (mp == null) {
            mp = new MediaPlayer();  // 池子空了就兜底创建
        }
        return mp;
    }

    public void release(MediaPlayer mp) {
        mp.reset();
        if (pool.size() < maxSize) {
            pool.push(mp);
        } else {
            mp.release();  // 池子满了就直接释放
        }
    }
}

按需创建：轻装上阵，随用随建

按需创建就是传统的做法——用到的时候 new 一个，用完就 release。这种做法有没有好处？当然有。

按需创建的优点：

• 不占额外内存：只在需要时分配，用完立即回收
• 逻辑简单：没有池子、没有状态管理，不易出错
• 适合低频使用：如果用户一天才看一两段视频，没必要预创建

但缺点也很明显。每次创建都要经历完整的初始化流程：加载 native 库、分配解码器、初始化音频输出……这些步骤在低端机型上可能耗时 200-500ms。用户每点一次播放就等半秒，这谁受得了？

我遇到过这样一个场景：某教育 App 的录播课列表页，用户会快速浏览多个课程预览。按需创建时，每切换一个预览就卡顿一次。后来改成预创建 2 个实例轮换，切换流畅了，但内存也只多了不到 10MB。这个性价比，我觉得很值。

两种策略的硬核对比

我整理了一张对比表，方便你直观地看差异：

看到表格你就明白了——没有的好坏，只有合不合适的场景。我个人习惯：列表页用预创建池，详情页用按需创建。这样既能保证滑动流畅，又不会在非核心页面浪费内存。

策略决策流程

那么问题来了：实际项目中，到底怎么选？我总结了一个简单的决策流程：

1. 看频率：用户在短时间内会播放多个视频吗？是→走预创建；否→走按需创建
2. 看内存：App 当前内存压力大吗？大→限制池大小或走按需；宽裕→可以多预创建几个
3. 看机型：目标用户多是低端机吗？是→强烈建议预创建；高端机可以放松要求
4. 看场景：是列表快速滑动还是单视频播放？前者预创建，后者按需即可

另外要注意，预创建不是越多越好。我见过有人预创建 10 个实例，结果内存飙到 200MB 以上，直接被系统杀后台。池大小建议控制在 3-5 个 以内，具体取决于你的视频分辨率和机型分布。

我的建议：混合策略最稳妥

别在「非此即彼」里钻牛角尖。实际项目中，我几乎都是用 混合策略：

• 列表页 / 滑动场景：预创建 2-3 个实例，用 LIFO 池管理，切换零延迟
• 详情页 / 单视频：按需创建，用完了直接 release，不占额外内存
• 后台预加载：在列表滑动空闲时，提前创建好下一个视频的实例，进一步提升感知速度

这样既能保证高频场景的流畅，又不会在低频场景浪费资源。说白了，就是「把好钢用在刀刃上」。