离线优先架构概述与核心原则
先问大家一个问题：当你的应用在飞机上、地铁里、或者是用户家那脆弱的Wi-Fi下，还能流畅使用吗？
我从业这些年，见过太多App一断网就变白板，甚至直接崩溃。用户骂娘，产品背锅，开发加班。其实这不是技术做不到，而是从一开始就没把“离线”当回事。
离线优先架构，说白了就是：把本地设备当作一等公民。网络只是同步手段，不是数据来源。
我个人习惯，设计新模块时一定会先问：“没网络时这功能还能用吗？”如果答案是不能，那就得重新想。
为什么要离线优先？
- 用户体验：秒开、无白屏、不依赖网络状态
- 可靠性：弱网、无网场景下功能不降级
- 省钱省流量：减少重复网络请求
- 竞品优势：你不断网，而对手会
我记得有一次做物联网巡检App，现场工程师经常在矿山、地下室作业，信号几乎为零。我们做了离线优先改造后，他们拿着设备录入数据，上了地面自动同步。产品经理拉着我说：“这功能救了我一命。”——其实救的是用户的命。
离线优先的五大核心原则
1. 本地优先（Local First）
所有数据先写本地数据库或文件，UI从本地读取。网络请求只是后台的“刷新”操作。
// 错误做法：先请求网络再显示
fun loadData() {
networkApi.getData().enqueue { response ->
uiState = response.data // 断网就崩
}
}
// 正确做法：先读本地，网络作为后台刷新
fun loadData() {
localRepo.getData().collect { cached ->
uiState = cached
}
// 异步同步
viewModelScope.launch {
val fresh = networkApi.getData()
localRepo.save(fresh)
}
}2. 乐观更新（Optimistic Updates）
用户操作后立即更新UI，不等待网络确认。后台再尝试同步。
我遇到过一个问题：用户在评论区发了一条消息，网络弱，等了5秒没反应，又点了一次——结果重复提交了。乐观更新可以避免这种焦虑。
3. 冲突解决（Conflict Resolution）
多端同时修改同一数据时，需要策略裁定谁的版本生效。常见策略：
| 策略 | 说明 | 适用场景 |
|---|---|---|
| 最后写入胜利（LWW） | 以时间戳最大的为准 | 简单数据（如昵称） |
| 自定义合并 | 按业务规则合并（如购物车合并） | 复杂对象 |
| 用户介入 | 弹出冲突界面让用户选择 | 重要数据（如合同内容） |
4. 同步策略（Sync Strategy）
何时同步？怎么同步？不能一味猛拉。我个人习惯给用户选择：
- 实时同步：仅Wi-Fi或强网下使用WebSocket
- 定时同步：每15分钟/每小时拉一次
- 懒同步：只在用户打开App时同步一次
- 按需同步：用户手动下拉刷新触发
5. 渐进增强（Progressive Enhancement）
先保证核心功能离线可用，再逐步添加依赖网络的增值功能。就像盖房子先打好地基，再装修。
举个例子：笔记App的“新建笔记”必须离线可用，而“搜索在线图片”可以放在网络通畅时。你想想看，用户最在乎的永远是“我能立刻记下想法”，而不是“我能搜到网络图片”。
离线优先架构的典型分层
从上图可以看出，数据流是单向的：UI只跟本地数据层交互，本地层再把变更交给同步引擎，同步引擎调用网络层，最终推送到服务器。
反过来，服务器数据下来时，也是先写入本地，再触发UI更新。
实践中的避坑指南
- 不要用网络结果直接更新UI：一定要通过本地存储转发，否则一断网UI就乱。
- 千万不要忽略冲突可能性：即使单用户场景，多个设备同时登录也可能产生冲突。我有个项目因为没处理冲突，导致用户的两台手机数据互相覆盖，损失惨重。
- 测试覆盖弱网、断网、恢复网络三个阶段：很多Bug在完美网络下测不出来，只有关掉Wi-Fi才能暴露。
小结：离线优先是一种思维转变
与其说它是一种技术架构，不如说是一种设计哲学。你不再“依赖网络”，而是“享受网络”。
核心就一句话：本地是源，网络是流。
接下来的章节，我会带大家深入Compose的State和Snapshot机制，看看如何保证离线数据在UI层的一致性和正确性。
嗯，这部分很有意思，因为Compose的快照系统天然就适合做乐观更新和局部刷新。