Animation-Garden项目中的媒体选择器缓存清理机制问题分析

在Animation-Garden项目的4.2.0-alpha02版本中，开发团队发现了一个关于在线源搜索缓存清理的重要技术问题。这个问题实际上可能从4.1.0版本就已经存在，但在新版本中由于某些优化措施变得更加明显。

问题本质

该问题的核心在于媒体选择器(Media Selector)的缓存清理机制未能按预期工作。具体表现为当用户进行在线源搜索时，系统不会自动清理之前的搜索缓存，这可能导致新旧搜索结果混杂，影响用户体验和数据准确性。

技术背景

在项目架构中，媒体选择器涉及两个关键层次：

1. 数据源层(DataSource Layer) - 负责具体的数据获取和处理
2. MediaFetcher层 - 理论上应该负责缓存管理

目前的问题根源在于缓存管理逻辑被错误地放在了数据源层，造成了不必要的耦合，而不是按照设计初衷放在MediaFetcher层。

根本原因分析

经过深入排查，开发团队发现这个问题与EpisodeViewModel中的launchInBackground协程实现有关。具体来说：

launchInBackground {
    selectorMediaSourceEpisodeCacheRepository.clearSubjectAndEpisodeCache()
}

这段代码存在潜在的竞态条件(Race Condition)问题。由于协程的执行时间不确定，当作用域(scope)被取消时，清理缓存的代码可能还没来得及执行就终止了。

版本影响

在4.2.0版本中，由于开启了Proguard优化，导致播放页面退出的处理速度加快，使得缓存清理操作更有可能在完成前就被中断，这使得问题变得更加明显。

临时解决方案

作为临时措施，开发团队决定先禁用缓存功能，以避免问题影响用户体验。但需要注意的是，由于数据库需要永久保持兼容性，这个功能变更无法简单地回滚。

架构改进方向

从长远来看，正确的解决方案应该是：

1. 将缓存管理逻辑从数据源层迁移到MediaFetcher层
2. 重构缓存清理机制，确保其执行不受协程生命周期影响
3. 考虑引入更可靠的清理触发机制，如基于状态变化的观察者模式

这个问题提醒我们在异步编程中需要特别注意资源清理的可靠性，特别是在涉及用户界面交互和后台任务协同的场景中。合理的架构分层和清晰的职责划分对于避免这类问题至关重要。