离线优先：一种更可靠的架构思路

开始之前，我想先问你一个问题：你的应用没网了，还能做什么？

我见过太多App，一旦连不上服务器，就直接白屏或转圈圈。用户在地铁上、隧道里、电梯中，只能干瞪眼。这其实就是「在线优先」架构的典型症状——网络不好，一切免谈。

那「离线优先」是什么？说白了，就是让应用在离线状态下依然能用，在在线时自动同步。不是把网络当成必需品，而是当成一种“可选优化”。

什么是离线优先

离线优先（Offline-First）是一种应用架构策略。它的核心逻辑很简单：先保证本地能用，再考虑网络同步。

我习惯用一个比喻：离线优先就像是你随身带了一本笔记本。你写的内容先记在笔记本上（本地），有空了再抄到正式文档里（服务器）。就算你没有带正式文档，甚至笔没墨水了，你依然能翻阅笔记本的内容。

具体到技术实现，离线优先通常包含这几层：

• 本地数据持久化：用 Room、SQLDelight 或文件缓存把数据存下来
• 同步机制：后台任务负责把本地变更推送到远端
• 冲突处理：多端同时修改时，得有策略解决“谁说了算”
• 界面适配：UI 层根据网络状态显示不同提示，比如“你正在离线浏览”

你想想看，如果一开始就按离线优先来设计，很多问题其实能提前规避。

为什么需要离线优先

你可能觉得：“我做的App大部分时候都在线，离线场景很少。”嗯，我以前也这么想——直到有一次我在演示产品时，会议室WiFi断了。

那场面，说实话有点尴尬。台下坐着的客户看着空白的加载圈，一分半钟后终于蹦出一句“数据加载失败”。会后我直接被问住：“这东西没网就不能用？”

从那以后，我就把离线能力列为了刚需。为什么？原因其实很直白：

痛点	在线优先表现	离线优先表现
网络不稳定	频繁报错、白屏	展示缓存数据，用户无感知
用户体验	必须等待网络响应	操作立即生效，体验流畅
设备资源	重复请求浪费流量	仅同步差异数据
可靠性	服务端宕机=应用瘫痪	服务端恢复后自动补全

离线优先 vs 在线优先

这两者的对比，从来不是简单的“哪个更好”。它取决于你的业务场景。但有一点可以确定：离线优先并不是否定网络，而是对网络抱有更现实的预期。

拿我参与过的一个项目来说——知识库应用。最初团队选了在线优先，所有内容都从后端拿。结果呢？用户反馈说“每次打开App都要等3秒，翻页更慢”。后来我们改成离线优先，把常用文档预载到本地，再配合增量同步。响应时间从3秒降到50毫秒以内。

两者的核心区别，我整理成了一张表：

维度	在线优先	离线优先
数据源	服务器是权威	本地是权威
可用性	依赖网络	无需网络
延迟	取决于网络状况	本地操作几乎0延迟
数据一致	实时一致	最终一致
实现复杂度	较低	较高（需处理同步与冲突）

看到这里你可能要问：那离线优先是不是更复杂？是的，实现上确实多了一层。但你要想清楚：复杂度是可以被架构消化掉的，用户的差评却很难挽回。

离线优先的适用场景

并不是所有场景都适合离线优先。我的标准很直接：如果用户在没有网络时会感到沮丧，那你就需要离线优先。

• 笔记类应用（Notion、Evernote）—— 写笔记时谁有网？
• 即时通讯（Telegram、Signal）—— 消息不能丢
• 任务管理（Todoist、Trello）—— 操作都要立即生效
• 新闻阅读（Pocket、Feedly）—— 等有网时再下载内容
• 地图导航 —— 隧道里一样要指路

反过来，一些纯展示类应用（比如后台看板），或对实时性要求极高（比如金融行情低延迟交易），离线优先反而不太合适。

这张图展示了我个人比较推荐的离线优先分层结构。注意看，UI 层只管读取本地数据源，完全不关心网络。同步服务是独立的一层，负责把本地变更推上去，再把远端数据拉下来。

数据流是单向的：用户操作 -> 写入本地 -> 触发同步 -> 远程更新 -> 同步回本地 -> UI 刷新。这种闭环，能最大限度保证用户动作的即时响应。

希望这一章能帮你建立对离线优先的整体认知。接下来，我们会深入 Compose 里如何一步步落地这个架构。