ViewModel中使用Flow.collect()导致的内存泄漏问题

Kotlin Flow很有用，特别是当它用于将数据从数据层传递到UI时。当正确使用时，复杂的屏幕可以很容易地在数据更改时进行更新，理解和维护起来也非常简单。但是，就像我们所喜爱的Kotlin中的任何东西一样，这种强大功能也伴随着一些不那么明显的风险。

理解在ViewModel中使用collect的问题

ViewModels从存储库观察数据，并将其映射到UI层。一个常见的做法是这样的：

class MyVeryBasicViewModel(private val repository: Repository): ViewModel {
    private val _uiState = MutableStateFlow<UiState>(UiState("initial state"))
    // 将UiState暴露给Fragment
    val uiState = _uiState

    init {
        viewModelScope.launch {
            repository.getDataFlow().collect { something ->
                _uiState.emit(something.mapToUiState())
            }
        }
    }
}

data class UiState(val text: String)

这个ViewModel定义了一个可变的StateFlow，用于发布来自存储库的数据。在其init方法中，ViewModel从存储库中收集数据，并再次发射到MutableStateFlow中。

注意到了什么问题吗？因为没有问题，或者至少问题并不大。不过，还是有一些小小的注意事项：

• • 收集操作在ViewModel创建时就开始了，但是Flow可能在UI中从未被消费。对于大多数情况，你不希望在没有人收集StateFlow时触发请求。

• • 在ViewModel中声明一个MutableStateFlow意味着来自ViewModel中的任何地方都可以发射数据。如果ViewModel变得非常复杂，可能会难以跟踪执行流和调试问题。

这两点只是一些小小的警告，但是当添加更多复杂性的代码会发生什么呢？比如说，UI中有一个刷新按钮，可以是下拉刷新，或者只是在请求失败时显示一个重试按钮。

class MyStandardViewModel(private val repository: Repository): ViewModel {
    private val _uiState = MutableStateFlow<UiState>(UiState("initial state"))
    val uiState = _uiState

    init {
        refresh()
    }

    /** 
     * 再次请求数据。可以从外部调用。
     */
    public fun refresh() {
        viewModelScope.launch {
            repository.getDataFlow().collect { something ->
                _uiState.emit(something.mapToUiState())
            }
        }
    }
}

data class UiState(val text: String)

从存储库中收集Flow并在_uiState中发射的操作已经被移动到了一个单独的方法中，该方法是public的，所以可以从UI中调用以刷新数据。

看起来可能不是很明显，但是这是非常错误的。每次调用refresh()时，都会创建一个新的collector，并且它将一直存在，直到ViewModel被销毁为止。所以，想象一下下拉刷新的情况。每次用户下拉时，都会创建一个新的collector。如果有10次下拉刷新，就会有10个collector发射到_uiState中。这就是泄漏收集器的问题。

每次调用refresh都会泄漏一个collector？并不完全准确。这取决于收集的Flow的类型：

• • 如果Flow只发射有限数量的值，然后结束，就不会有任何问题。Flow在某个时刻会结束，collector会被垃圾回收。不过，如果Flow进行大量的发射，可能也会花费一些时间，并且会在此期间泄漏。

• • 当Flow是一个热Flow时，比如对Room或SharedPreferences中的更改做出反应的Flow，那么这个问题就非常真实了。热Flow永远不会结束，因此收集器永远不会被释放。

即使它取决于Flow的类型，我们应该考虑到从ViewModel的角度来看，我们无法知道底层层次中暴露的Flow是哪种类型，即使你知道（因为代码是你自己的，并且你进行了检查），也不能保证将来不会发生变化。因此，一个正确编码的ViewModel应该只依赖于暴露给它的信息，并且具有鲁棒性。

如何解决这个问题

不要在ViewModel中使用collect，但是...怎么做呢？根据上面的两种情况，让我们看看可以做些什么，这完全基于Flow及其操作符。

非常基本的场景

class MyVeryBasicViewModel(private val repository: Repository): ViewModel {
    private val _uiState = MutableStateFlow<UiState>(UiState("initial state"))
    val uiState = _uiState

    init {
        viewModelScope.launch {
            repository.getDataFlow()
                .onEach { something ->
                    _uiState.emit(something.mapToUiState())
                }
                .launchIn(this@MyVeryBasicViewModel)
        }
    }
}

data class UiState(val text: String)

在这个版本中，我们使用了onEach操作符替换了collect。onEach操作符允许我们处理Flow发射的每个元素，而不需要创建收集器。然后，我们使用launchIn将Flow绑定到viewModelScope中，以确保在ViewModel被销毁时取消收集。

添加更多复杂性的场景

class MyStandardViewModel(private val repository: Repository): ViewModel {
    private val _uiState = MutableStateFlow<UiState>(UiState("initial state"))
    val uiState = _uiState

    private var refreshJob: Job? = null

    init {
        refresh()
    }

    public fun refresh() {
        refreshJob?.cancel()
        refreshJob = viewModelScope.launch {
            repository.getDataFlow()
                .onEach { something ->
                    _uiState.emit(something.mapToUiState())
                }
                .launchIn(this@MyStandardViewModel)
        }
    }
}

data class UiState(val text: String)

在这个版本中，引入了一个refreshJob变量来持有刷新操作的Job。每次调用refresh方法时，首先取消之前的Job（如果存在），然后创建一个新的Job来收集Flow。这样，就可以确保只有一个collector处于活动状态，并且在下一次调用refresh时可以取消之前的collector。

处理热Flow的场景

在处理热Flow的情况下，需要采取不同的策略。由于热Flow永远不会结束，我们不能依赖于launchIn的自动取消功能。相反，需要手动管理收集器的生命周期。

class MyHotFlowViewModel(private val repository: Repository) : ViewModel() {
    private val _uiState = MutableStateFlow<UiState>(UiState("initial state"))
    val uiState = _uiState

    private var collector: Job? = null

    init {
        startCollecting()
    }

    private fun startCollecting() {
        collector?.cancel()
        collector = viewModelScope.launch {
            repository.getHotFlow()
                .onEach { something ->
                    _uiState.emit(something.mapToUiState())
                }
                .catch { throwable ->
                    // 处理错误
                }
                .collect()
        }
    }

    override fun onCleared() {
        collector?.cancel()
        super.onCleared()
    }
}

data class UiState(val text: String)

在这个版本中，使用collect函数手动收集热Flow。使用catch操作符处理任何错误。此外，在ViewModel的onCleared方法中，确保在ViewModel被清除时取消收集器。

这样，就解决了在ViewModel中泄漏Flow收集器的问题。使用Flow的操作符以及对收集器的手动管理来确保正确的收集行为和资源释放。

结论

在ViewModel中使用Flow.collect()可能导致泄漏的收集器，这可能会引发一系列问题。为了解决这个问题，应该避免在ViewModel中使用collect() ，并使用手动管理收集器的方式来替代。

ViewModel是我们应用程序的重要组成部分，因此应该保持它的健壮性和可维护性。通过正确处理Flow的收集行为，我以避免潜在的内存泄漏和不必要的资源消耗，同时确保代码的可读性和可维护性。

转自：ViewModel中使用Flow.collect()导致的内存泄漏问题