Android Paging3 RxJava场景下共享ViewModel引发Fragment内存泄漏如何解决

问题根源 #

你遇到的泄漏是因为cachedIn(viewModelScope)将Paging数据流的生命周期和ViewModel绑定，而ViewModel的生命周期远长于详情Fragment：你在详情Fragment订阅数据流时创建的Consumer匿名内部类会持有Fragment的强引用，即便你调用了disposable.clear()切断了下游接收通道，低版本Paging3内部的Multicaster组件存在未及时清理已取消订阅者引用的问题，导致已销毁的详情Fragment无法被GC回收。

解决方案 #

按改造成本从低到高排序：

1. 升级Paging3到最新稳定版 #

该泄漏属于Paging3低版本的已知问题，3.1.0及以上稳定版本已经修复了Multicaster对已取消订阅者的引用残留问题，无需修改业务代码即可解决：

dependencies {
    implementation "androidx.paging:paging-runtime-ktx:3.2.1"
    // 按需搭配对应RxJava版本的依赖
    implementation "androidx.paging:paging-rxjava3:3.2.1"
}

2. 替换缓存策略为短生命周期热流 #

如果不方便升级依赖，可以修改ViewModel的缓存逻辑，放弃和ViewModel生命周期强绑定的cachedIn，改用shareIn配置短时间保留缓存的热流，既可以在页面跳转时复用请求结果，又会在所有订阅者退出后自动释放资源，不会残留Fragment引用：

class FilesViewModel @Inject constructor(
    settings: SettingsRepository,
    private val filesRepository: FilesRepository
): ViewModel() {

    private val pagedFilesFlow = Pager(PagingConfig(pageSize = 20)) {
        FilesPageSource(fileAPI, baseUrl, "path")
    }.flow

    // 配置规则：所有订阅者退出后保留缓存5秒，足够应付页面跳转间隔，之后自动释放资源
    val cachedFileList = pagedFilesFlow.shareIn(
        scope = viewModelScope,
        started = SharingStarted.WhileSubscribed(5000),
        replay = 1
    ).asFlowable() // 保留RxJava调用方式
}

该方案无需接入数据库，页面跳转间隔在5秒内都会复用已加载的分页数据，不会产生重复请求。

3. 优化订阅逻辑避免强引用 #

如果前两种方案都不适用，可以修改订阅代码切断引用链：

• 改用AutoDispose这类生命周期感知的订阅工具，绑定Fragment的View生命周期，在onDestroyView时自动清除上下游的引用关联：

disposable.add(viewModel.loadPagedFiles(folder)
    .subscribeOn(Schedulers.io())
    .observeOn(AndroidSchedulers.mainThread())
    .autoDispose(viewLifecycleOwner) // 绑定View生命周期，销毁时自动切断引用
    .subscribe(
        { adapter.submitData(lifecycle, it) },
        { error -> println("Error loading files: ${error.message}") }
    )
)

• 也可以将订阅的Consumer改为静态内部类，用弱引用包裹Fragment实例，避免直接持有强引用。

额外检查项 #

确认详情Fragment的CompositeDisposable是在onDestroyView时调用clear()，而不是仅在onDestroy中调用，详情页返回时onDestroyView会先触发，提前释放订阅可以减少引用持有时间。

内容的提问来源于stack exchange，提问作者Jorge Guillermo Negrete