ExoPlayer 初始化位置探讨：ViewModel创建还是单例依赖注入？

在ViewModel中用Builder创建的利弊 #

• 这种方式并非绝对错误，但存在明显局限：
  • 资源浪费：每次ViewModel初始化都会生成新的ExoPlayer实例，重复初始化会消耗额外内存、CPU，甚至引发音频焦点冲突（多个实例同时占用播放资源）。
  • 状态丢失：页面销毁重建（如屏幕旋转）时，新ViewModel会创建新播放器，之前的播放进度、状态无法无缝衔接。
  • 跨页播放受限：无法在多个页面（如列表页到详情页）复用播放器实例，切换页面会中断播放流程。

单例模式（如NewPipe的实现）的优势 #

• 全局复用：整个应用仅维护一个ExoPlayer实例，避免重复初始化，节省系统资源，同时保证跨页面播放状态的一致性（切换页面不中断播放）。
• 统一管理：可以集中处理音频焦点、播放状态监听、资源释放逻辑，避免每个ViewModel各自处理带来的混乱。
• 需注意的细节：
  • 生命周期绑定：将单例的生命周期与Application绑定，在App退到后台时及时暂停/释放资源，防止内存泄漏。
  • 线程安全：创建单例时要保证线程安全，比如用双重校验锁或依赖注入框架的单例注解实现。

依赖注入的价值 #

用Hilt、Dagger等依赖注入框架管理单例ExoPlayer，比手动实现单例更可靠：

• 自动处理生命周期：通过自定义绑定，让播放器实例与Application或特定Scope绑定，避免内存泄漏。
• 解耦优化：ViewModel无需关心播放器的创建细节，只需注入使用，代码更简洁，也便于单元测试（可注入Mock实例）。

总结建议 #

• 如果你的App需要跨页面连续播放、统一播放状态管理，优先选择单例+依赖注入的方案，这也是视频类应用的通用实践。
• 若只是单个页面的简单播放场景，且无需跨页复用，ViewModel内用Builder创建也能运行，但务必在ViewModel.onCleared()中调用ExoPlayer.release()，及时释放资源避免泄漏。

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