Ani 视频播放器中 VLCJ 缓冲 P2P 资源时的 UI 冻结问题分析

问题背景

在 Ani 视频播放器的开发过程中，我们发现当使用 VLCJ 播放器缓冲 P2P 资源时，用户界面(UI)会出现冻结现象。这个问题影响了多个相关功能，包括播放器销毁操作和用户交互响应。

技术分析

问题根源

问题的核心在于 SeekableInputCallbackMedia 类中的 input.read 方法调用链。具体来说：

1. input.read 方法会调用 P2PInput.read
2. P2PInput.read 内部使用了 runBlocking 协程构建器
3. 这种阻塞式调用导致任何对 VLCJ 播放器的销毁操作都必须等待当前阻塞操作完成

代码层面分析

在 SeekableInputCallbackMedia 的实现中，读取操作直接调用了底层 P2P 输入流：

override fun onRead(media: Media, buf: ByteBuffer, len: Int): Int {
    return input.read(buf.array(), buf.arrayOffset(), len)
}

而 P2PInput.read 的实现则使用了阻塞式协程：

override fun read(b: ByteArray, off: Int, len: Int): Int {
    return runBlocking {
        // 从 P2P 源读取数据的实现
    }
}

这种设计导致了 UI 线程的阻塞，因为 runBlocking 会阻塞当前线程直到协程完成。

解决方案

改进方案

为了解决这个问题，我们需要引入协程作用域(Coroutine Scope)管理机制：

1. 为播放器操作创建独立的协程作用域
2. 在执行 VLC 关闭操作前，先取消相关作用域
3. 使用非阻塞式的协程调用替代 runBlocking

实现要点

改进后的设计应该：

1. 将读取操作移至后台协程
2. 提供明确的取消机制
3. 确保资源释放的顺序正确性
4. 保持数据读取的连续性

技术影响

这个问题的解决将带来以下改进：

1. 提升 UI 响应速度
2. 避免播放器销毁时的卡顿
3. 改善用户观看体验
4. 增强系统的稳定性

总结

通过对 Ani 视频播放器中 VLCJ 与 P2P 资源交互机制的优化，我们解决了 UI 冻结的关键问题。这个案例展示了在多媒体应用中正确处理阻塞操作的重要性，特别是在涉及网络资源加载和用户界面交互的场景中。