离线数据同步与Compose状态快照：概念与背景

大家好，我是你们这趟旅程的向导。今天咱们聊的这个话题，说白了就是当你的App在后台默默同步数据时，用户在前端划拉屏幕，这俩事儿撞一块儿了，怎么办？

我记得有一次，做一个即时通讯App。用户离线状态下发了一堆消息，等网络恢复，后台线程吭哧吭哧地同步。结果呢？用户正在输入框里打字，突然界面跳了一下，刚才打的几个字不见了。用户直接炸毛了。

这个场景，就是典型的「离线数据同步」与「Compose状态快照」冲突的现场。嗯，咱们这一章，就从这里说起。

什么是离线数据同步？

先把这个概念掰扯清楚。

离线数据同步，说白了就是「用户在没有网络的情况下，对本地数据做了修改。等网络一恢复，这些修改需要跟远程服务器保持一致」。

这个过程，通常包含三个核心动作：

• 本地写入：用户操作本地数据库或文件
• 数据变更：产生一条或多条待同步的记录
• 远程同步：后台将本地变更推送到服务器，并拉取服务器最新数据

什么是Compose状态快照？

Compose有一个核心机制，叫「状态快照」（Snapshot）。你想想看，Compose需要知道「当前时刻，界面上所有的状态值分别是多少」。这样它才能决定怎么画UI。

这个快照机制，有三个特点：

特点	说明
不可变	快照一旦拍摄完成，内容就固定了
线程绑定	每个线程有独立的快照上下文
自动失效	当状态变更时，旧快照自动标记为过期

两种冲突场景

我遇到过的情况，基本可以归为两类：

第一种：UI线程和同步线程「抢」同一个状态

比如说，一个列表数据，用户正在手动排序。同步线程突然把服务器新数据写进来。结果呢？一个状态变量，被两个线程同时读写。Compose的快照机制会抛异常吗？不一定，但UI显示会错乱。

第二种：快照拍摄时数据正处于「未完成」状态

这个更隐蔽。同步线程正在分批写入20条数据。写到第10条时，Compose拍了个快照。好嘛，UI只能看到半份数据。用户一看，以为App坏了。

为什么会这样？因为快照的拍摄是瞬时的，而同步是持续的过程。两者天然存在时间差。

冲突到底长什么样？

咱们直接看代码。假设你有这样一个状态：

@Composable
fun MessageList() {
    val messages by viewModel.messages.collectAsState()
    
    LazyColumn {
        items(messages) { msg ->
            MessageItem(msg)
        }
    }
}

看起来没问题对吧？但假如viewModel.messages是一个Room数据库的Flow，后台同步线程往这个表里插了一批数据。Room的Flow会如何反应？

它会重新发射整个列表。每一次发射，Compose都会重新拍摄快照。

嗯，这里要注意：Room的Flow不是增量发射的。它是全量发射。哪怕只多了一条数据，整个列表都会重新发射。Compose的快照机制，就得重新拍摄整个列表的快照。

用户看到的是什么？列表疯狂闪烁，刚滑动到这个位置，啪，跳回顶部了。

两种冲突类型的对照

我整理了一个表格，方便你对照理解：

冲突类型	发生时机	典型表现	根因
读写冲突	同步线程写入时	列表闪烁、排序错乱	状态被两个线程同时访问
快照时间差冲突	同步进行中，快照拍摄	数据不完整、界面跳跃	快照拍摄时数据是中间态

一个简单的量化对比

假设同步一批数据需要500ms。Compose的快照拍摄需要1ms。在这500ms里，快照被重新拍摄多少次？

理论上是0次到N次。如果用户正在输入，UI不断重绘，每次重绘都可能触发热重组的快照拍摄。那500ms内可能重拍5-10次快照。每次拍到的数据状态都不一样。

第一次拍到：同步了0%
第二次拍到：同步了20%
第三次拍到：同步了50%
第四次拍到：同步了80%
第五次拍到：同步了100%

用户看到的就是一个「一直在变」的界面。而且每次变化之间，可能还有数据不一致的问题。

我们为什么要关心这个？

说白了，如果你不做任何处理，这些问题迟早会来找你。尤其是你的App需要离线使用，用户对数据一致性有要求，那这件事你必须搞明白。

从这一章开始，咱们会一步步解开这些冲突。后面几章会讲到如何用snapshotFlow、如何用状态容器、如何设计同步策略。

但这一章，你只需要记住一句话：离线同步是持续的过程，Compose快照是瞬时的动作。两者天生有个时间差。这个时间差，就是所有问题的根源。

嗯，概念和背景就到这里。你已经知道冲突是怎么来的了。接下来，咱们要开始动手解决它。