结构勘察报告 · 2026 年 7 月

L O A D - B E A R I N G

你离开了一年半。回来后最想问的那个问题 —— 「现在流行什么架构?」 —— 其实是个坏问题。 好问题是:什么没变,什么变了。

好消息是,承重结构一根没动:UI 层 / 领域层 / 数据层的分层,状态与事件的单向流动, Repository 背后的唯一真相 —— 你 2024 年会的这些,今天一字不改仍然作数。

坏消息是,它底下的地基被整个换过一遍。返回栈不再由框架替你保管,而是变成一个你自己持有的 List;Compose 编译器搬进了 Kotlin,顺手把你手写的那些 @Immutable 变成了历史; DI 多了一个编译器插件流派;连「状态该住在哪」这件事,社区都分裂成了三派。

▣ 承重结构 —— 一根没动 UI 层 · Composable 状态持有者 数据层 · Repository 唯一真相 · SSOT 事件 状态 2024 会的,2026 一字不改 ✂ 地基 —— 全换了 导航 NavHost + 路由串 你持有的 back stack 编译器 手写 @Immutable 强跳过,默认开启 DI Hilt 一家独大 Hilt / Metro / Koin 状态 ViewModel 唯一解 分裂成三派 构建 AGP 8 / Kotlin 1.9 AGP 9 / Kotlin 2.x 这五行,就是你要补的课
6 6 个零依赖互动 Demo 三档流派全覆盖 版本号全部取自真实项目 亮色 · 无追踪 · 纯静态

先看三个真实项目

讲架构最没用的方式,是背 Google 那张分层图。所以这本书自始至终吊着三个还活着的开源项目, 它们的技术栈都是我翻它们的 gradle/libs.versions.toml 一行行核对出来的 —— 不是我记忆里的样子,是它们今天真实的样子。

有意思的地方在于:这三个项目几乎没有一个共同的依赖,而它们都跑得很好。

Now in Android Mihon DroidKaigi
是什么 Google 的官方样板 漫画阅读器(Tachiyomi 的继任) 日本最大 Android 大会的会议 app
Kotlin 2.3.0 2.4.0 2.2.0
导航 Navigation 3 Voyager Navigation 3 + adaptive
状态住在 ViewModel + StateFlow ScreenModel(不用 ViewModel) Presenter 就是 @Composable
DI Hilt 2.59 Injekt(服务定位器)
数据库 Room 2.8.3 SQLDelight 2.3.2 Soil query
网络 Retrofit 2.11 裸 OkHttp 5.4 Ktor
代表的路线 官方正统 社区实用主义 Compose 原生 · 下一代
◆ 判词 · 这张表想说的不是「谁对」

Mihon 有五百万用户,它不用 ViewModel、不用 Hilt、不用 Room、不用 Retrofit —— 官方推荐的四大件,它一个没要,活得好好的。

所以别把「官方推荐」读成「唯一正确」。这本书会逐个告诉你:官方那套为什么这么设计(它在替你解决哪个具体的痛), 以及 Mihon 敢不要它们是因为它不吃那个痛。搞清了这一层,你才有资格做选型,而不是抄。

你错过的,浓缩成五行

下面这五条,是 2024 年中到 2026 年中之间,真正会改变你写代码方式的变化。第 2、3 章会把它们一条条拆开。

NavHost + "detail/{id}" 路由串 Navigation 3:back stack 就是个 List 2025-11 转正
这是单点变化最大的一件事。返回栈从框架托管的黑盒,变成你自己持有、能随便 add/removeSnapshotStateList
@Immutable / ImmutableList / remember{lambda} 强跳过,默认开启,你什么都不用做 Kotlin 2.0.20+
Compose 编译器并入了 Kotlin 仓库。你以前为了「稳定性」手工做的那些体操,现在编译器自己做了。
DI 就等于 Hilt Hilt / Metro / Koin / kotlin-inject Metro 2026-04 转正
Metro 是个 Kotlin 编译器插件,支持多平台,能和 Dagger 组件级互操作。Vinted 已在 2026 年 2 月全量迁过去。
ViewModel 是唯一的状态持有者 ViewModel / ScreenModel / @Composable Presenter 持续分裂中
最激进的一派把 Compose 运行时当成通用状态引擎:presenter 本身是个 @Composable,返回值就是 state。
ViewModel / Room / DataStore = Android only 它们全都多平台化了 2024–2025 陆续
这不只是「能跑在 iOS 上」。它意味着 commonMain 里可以放一个真的 ViewModel —— 架构分层第一次能整体下沉。
⚠ 顺带一条坏消息

如果你以前拿 Tivi(Chris Banes 那个 TV 追剧 app)当参考项目 —— 它已经在 2024 年 11 月归档了。 代码还能读,是学 Circuit + KMP 的好材料,但别再拿它对标「当下的最佳实践」。


这本书怎么读

六章,两条线。前半程是补课(什么没变、什么变了、导航为什么要重来一次), 后半程是开工(状态放哪、数据和 DI 怎么选、从零搭一个 2026 年的项目)。 每章配一个能点的 Demo —— 不是动画,是真的在跑一个小模型:重组次数是算出来的,返回栈是真的一个数组,循环依赖是真的用 DFS 找出来的。

幕 I · 承重结构 STILL STANDING

你原来会的那部分,仍然作数

在拆地基之前,先确认哪些墙不能动。

幕 II · 拆除与新建 DEMOLITION

骨架没动,地基被整个换过一遍

18 个月的变更清单,和其中最大的那一件。

幕 III · 三档流派 THREE SCHOOLS

官方正统、社区实用主义、Compose 原生

同一个问题,三个答案。搞清它们各自在优化什么。

幕 IV · 开工 BREAK GROUND

把上面这些变成一个能跑的项目

模块怎么切、版本目录怎么写、三档流派怎么选。

▣ 开始之前,先把这句话放心里

这一年半里,Android 没有发生一次「架构革命」。发生的是一次地基的整体更换 —— 分层还是那三层,单向数据流还是那个单向数据流,Repository 还是那个 Repository。

你需要重学的,是怎么把这些没变的东西,搭在换过的地基上。这比从头学一套新架构轻松得多。