状态住在哪

ViewModel 是来解决什么问题的?

标准答案是「持有 UI 状态、把业务逻辑从 Activity 里挪出来」。这个答案不对 —— 或者说, 它只描述了 ViewModel 的用法,没解释它的存在。

因为要把逻辑挪出 Activity,你随便建个普通类就行了。为什么非得是 ViewModel 这个特定的基类?

那么下一个问题就自然了:如果我不吃「转屏销毁」这个痛呢?

三派,同一个搜索屏幕

与其抽象地比较,不如让它们做同一件事。下面这个 Demo 里,三派并排实现同一个搜索屏幕: 用户输入 → 防抖 → 查数据 → 出结果。点「下一步」,三栏同时推进 —— 你可以横着读: 同一时刻,三派各自在干什么。

走完五步,那张对照表才是重点。现在我们逐派拆开讲。

一 · 官方正统:ViewModel + StateFlow

Now in Android

@HiltViewModel
class SearchViewModel @Inject constructor(
    private val repo: SearchRepository,
    savedState: SavedStateHandle,      // ← 进程死了都能恢复的那份
) : ViewModel() {

    private val query = MutableStateFlow("")

    val uiState: StateFlow<SearchUiState> = query
        .debounce(300)
        .flatMapLatest { q -> repo.search(q) }        // 新的输入来了?旧的请求直接取消
        .map(SearchUiState::Success)
        .stateIn(
            scope = viewModelScope,
            started = SharingStarted.WhileSubscribed(5_000),   // ← 这个 5 秒,下面细说
            initialValue = SearchUiState.Loading,
        )

    fun onQueryChange(q: String) { query.value = q }
}

UI 侧:

val state by viewModel.uiState.collectAsStateWithLifecycle()
//                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
// 不是 collectAsState()!后者不感知生命周期 ——
// app 退到后台了它还在收,白白烧电和流量。

二 · 社区实用主义:Mihon 压根不用 ViewModel

Mihon · Voyager StateScreenModel + Injekt

这是本书最值得琢磨的一个案例。Mihon 是有数百万用户的漫画阅读器, 它的技术栈里没有 ViewModel、没有 Hilt、没有 Room、没有 Retrofit —— 官方推荐的四大件,一件没要。

class SearchScreenModel(
    private val repo: SearchRepository = Injekt.get(),   // ← 服务定位器,不是构造注入
) : StateScreenModel<SearchScreenModel.State>(State()) {

    fun onQueryChange(q: String) {
        mutableState.update { it.copy(query = q) }       // ← 直接改自己那份 state
        screenModelScope.launch {                        // ← 不是 viewModelScope
            val results = repo.search(q)
            mutableState.update { it.copy(results = results) }
        }
    }

    data class State(val query: String = "", val results: List<Manga> = emptyList())
}

它凭什么敢?回到本章开头那句话 —— ViewModel 存在的唯一理由是活过转屏。

那 Injekt 呢?一个运行时服务定位器,在 Hilt 面前看着像倒退十年。它的代价很实在:

三 · Compose 原生:Presenter 本身就是个 @Composable

DroidKaigi · Circuit(Slack)/ Molecule(Cash App)

这一派的出发点是一个观察 —— 而这个观察,一旦你听懂了就再也忘不掉:

Circuit 的答案:presenter 就是个 @Composable 函数,它的返回值就是 state。

class SearchPresenter(private val repo: SearchRepository) : Presenter<SearchState> {

    @Composable                                  // ← 是的,presenter 是 @Composable
    override fun present(): SearchState {        // ← 它 return 一个 state

        var query by remember { mutableStateOf("") }          // 就是 Compose 那套

        val results by produceState(emptyList(), query) {     // 异步也是 Compose 那套
            delay(300)                                        // 防抖
            value = repo.search(query)
        }

        return SearchState(query, results) { event ->         // 事件回调塞在 state 里
            when (event) {
                is QueryChanged -> query = event.q
            }
        }
    }
}

没有 MutableStateFlow,没有 debounce,没有 flatMapLatest,没有 stateIn。 防抖是一句 delay(300),取消是 produceState 的 key 变了自动重启。

那这个 @Composable 函数怎么变成一条状态流?这就是 Molecule 干的事:

// Molecule:把 Compose 运行时跑起来,产出一个 StateFlow
val states: StateFlow<SearchState> = scope.launchMolecule(RecompositionMode.ContextClock) {
    presenter.present()      // ← present() 每重组一次,就吐出一版新的 state
}
// 于是 UI 层拿到的,还是一个普普通通的 StateFlow。
// 但产生它的那段逻辑,是用 Compose 的心智写的。

所以,你该选哪个

状态的归属讲完了。下一章往下走一层 —— 数据从哪来,依赖怎么进来。 你会看到「离线优先」根本不是一个功能,而是 SSOT 这个结构自己长出来的副产品; 以及 DI 这个你以为早就尘埃落定的领域,在 2026 年多了一个新玩家。