在Fragment的Adapter中更新SeekBar时MediaPlayer音频卡顿问题

嘿，我之前碰到过几乎一模一样的场景，这种卡顿大概率是ViewHolder复用+多实例定时任务冲突搞出来的，要么是多个MediaPlayer的更新任务抢占主线程，要么是RecyclerView频繁重绘拖慢了节奏。给你几个落地性很强的解决方案：

1. 把播放状态管理从Adapter移到Fragment层 #

RecyclerView的ViewHolder会被频繁复用，如果每个Item的MediaPlayer都自己开定时器更新SeekBar，很容易出现N个定时任务同时跑，不仅浪费系统资源，还会把主线程堵得死死的。正确的思路是让Fragment统一管播放：

• 在Fragment里维护两个变量：当前正在播放的Item位置、对应的MediaPlayer实例
• 只给这个「活跃播放项」做SeekBar的定时更新，其他Item一律暂停更新逻辑

2. 用生命周期安全的方式做定时更新 #

别在ViewHolder里直接搞Timer或者Handler，而是在Fragment里创建绑定生命周期的更新任务，避免内存泄漏和无效任务乱跑：

示例代码（Kotlin） #

在Fragment中：

private var currentPlayingPos = -1
private var currentMediaPlayer: MediaPlayer? = null
private val updateHandler = Handler(Looper.getMainLooper())
private val updateRunnable = object : Runnable {
    override fun run() {
        currentMediaPlayer?.takeIf { it.isPlaying }?.let { player ->
            // 只更新当前播放项的SeekBar
            yourAdapter.updateSeekBar(currentPlayingPos, player.currentPosition)
            updateHandler.postDelayed(this, 1000)
        }
    }
}

// 外部（Adapter的ViewHolder）调用这个方法开始播放
fun startPlayback(position: Int, player: MediaPlayer) {
    // 先停掉之前的播放和更新
    stopCurrentPlayback()
    currentPlayingPos = position
    currentMediaPlayer = player

    player.setOnPreparedListener {
        it.start()
        updateHandler.post(updateRunnable)
    }
    player.setOnCompletionListener {
        stopCurrentPlayback()
    }
}

private fun stopCurrentPlayback() {
    updateHandler.removeCallbacks(updateRunnable)
    currentMediaPlayer?.apply {
        stop()
        release()
    }
    currentMediaPlayer = null
    // 重置之前播放项的SeekBar
    yourAdapter.notifyItemChanged(currentPlayingPos)
    currentPlayingPos = -1
}

// 别忘了在Fragment销毁时彻底清理
override fun onDestroyView() {
    super.onDestroyView()
    stopCurrentPlayback()
    updateHandler.removeCallbacksAndMessages(null)
}

在Adapter中添加专属更新方法：

fun updateSeekBar(position: Int, progress: Int) {
    // 直接找到对应ViewHolder更新，避免全量刷新
    val holder = recyclerView.findViewHolderForAdapterPosition(position) as? YourCustomViewHolder
    holder?.seekBar?.progress = progress
}

3. 处理ViewHolder复用的边界情况 #

当ViewHolder被回收时，必须立刻停掉对应的MediaPlayer和可能遗留的更新逻辑，不然复用后会出现「旧播放任务没停，新任务又开始」的混乱：

override fun onViewRecycled(holder: YourCustomViewHolder) {
    super.onViewRecycled(holder)
    // 如果回收的是正在播放的Item，通知Fragment停掉
    if (holder.adapterPosition == fragment.currentPlayingPos) {
        fragment.stopCurrentPlayback()
    }
    // 释放当前ViewHolder的MediaPlayer
    holder.mediaPlayer?.apply {
        stop()
        release()
    }
    holder.mediaPlayer = null
}

4. 优化UI更新的开销 #

• 绝对不要用notifyDataSetChanged()，只用notifyItemChanged(position)更新当前播放项，减少RecyclerView的重绘压力
• 如果是Java项目，记得用WeakReference包装Fragment，避免Adapter持有Fragment强引用导致内存泄漏

这样调整后，整个播放逻辑就集中在Fragment层了，只会有一个定时任务在跑，UI更新也只针对当前播放项，卡顿问题应该就能解决啦。

内容的提问来源于stack exchange，提问作者Paradox