同步引擎：关键概念、类型与工作机制

什么是同步引擎？

同步引擎 — 是位于本地数据库和远程 API 之间的架构层，管理双向数据流。其任务包括：跟踪变更、将其发送到服务器、接收服务器变更以及解决冲突。用户操作本地数据，同步引擎则无缝地与服务器同步数据。

同步引擎可以是内置的（Firebase Firestore、Couchbase Lite、Realm）或自定义的——为特定业务逻辑编写。内置引擎提供现成的离线优先功能和冲突解决。自定义引擎则提供对数据格式、同步协议和冲突策略的完全控制。

根据《移动同步引擎设计模式》一书作者Sravan Kartik（2024年）的说法，自定义同步引擎适用于业务逻辑复杂的应用（金融、医疗、物联网），其中自定义合并规则至关重要。对于典型场景（笔记、聊天、信息流），内置的 Firestore 或 Realm 就足够了。

interface SyncEngine {
    suspend fun pull(lastSyncTimestamp: Long): SyncResult
    suspend fun push(operations: List<QueuedOperation>): PushResult
    suspend fun resolve(conflicts: List<Conflict>): ResolutionResult
    fun observeSyncState(): Flow<SyncState>
}

该接口描述了同步引擎的最小契约：pull（从服务器获取变更）、push（发送本地变更）、resolve（处理冲突）和observe（观察同步状态）。这种抽象允许在不修改表示层的情况下更改实现。

同步类型：全量、增量和推送

全量同步 — 每次会话都从服务器下载完整数据集。实现简单，但不适用于大量数据：每次打开应用都下载10,000条记录会消耗流量和电池。全量同步适用于更新频率低的参考数据（国家列表）。

增量同步 — 仅传输自上次同步以来更改的记录。服务器存储每个记录或整个集的最后更改时间戳。客户端发送lastSyncTimestamp，仅接收 updated_at 大于此值的记录。根据Instagram Engineering（2024年）的数据，增量同步与全量同步相比减少了97%的数据传输量。

推送同步（服务器发起的同步） — 服务器通过 FCM（Firebase Cloud Messaging）、WebSocket 或 SSE（服务器发送事件）自行通知客户端需要同步。客户端不会因定期轮询而浪费资源。推送同步是实时应用（聊天、通知、点赞）的最佳选择。Google Firebase Firestore 使用 WebSocket 进行实时同步，并自动回退到 HTTP 轮询。

混合方法 — 组合多种类型：启动应用时全量同步基础数据，然后增量同步更新，关键事件通过 FCM 进行推送同步。这样既保证速度又节省资源。

增量同步 — 检查点和增量如何工作

检查点 — 客户端在同步会话之间存储的值。通常是最后成功同步的记录的updated_at字段。下次同步时，客户端将检查点发送到服务器，服务器返回所有 updated_at 晚于检查点的记录。基于游标的分页 — 高级版本，服务器随数据一起返回游标（指向下一页的指针）。

增量同步 — 服务器计算数据当前状态与客户端看到的快照之间的差异。不发送所有记录，仅传输操作（插入、更新、删除）。这对于仅更改了几条记录的大型数据集特别有效。Google Drive API（2025年）使用带有 pageToken 的 changes.list 进行文件增量同步。

「延迟增量」策略 — 在移动客户端上，更改不会立即发送，而是在离线队列中缓冲。达到阈值（10次操作或30秒）后，形成增量包并发送到服务器。根据Dropbox Mobile Engineering（2024年）的数据，批量处理增量使 HTTP 请求数量减少了65%，电池消耗降低了12%。

data class SyncCheckpoint(
    val lastUpdated: Long,
    val pageToken: String?,
    val version: Int
)

suspend fun syncIncremental(checkpoint: SyncCheckpoint): SyncResult =
    api.pullChanges(
        since = checkpoint.lastUpdated,
        token = checkpoint.pageToken
    )

SyncCheckpoint 既存储时间戳，也存储长列表的分页游标。双参数检查点确保在同步大数据集时不会遗漏或重复任何记录。

推送同步 — 通过 WebSocket 和 FCM 即时同步

WebSocket — 客户端与服务器之间的永久双向连接。服务器在数据更改后立即发送更新。WebSocket 适用于实时应用：聊天、流媒体、协作工作。缺点：为维持连接（心跳）而消耗电池和流量。Android 上的OkHttp WebSocket和 iOS 上的URLSessionWebSocketTask是内置实现。

Firebase Cloud Messaging（FCM） — 服务器发送的推送通知不是为了向用户显示，而是为了触发同步。收到静默推送（数据消息）后，应用被唤醒并运行同步引擎。FCM 不需要永久连接，对于不频繁的通知比 WebSocket 更经济。

SSE（服务器发送事件） — 服务器通过单向通道向客户端发送事件。实现比 WebSocket 简单，但不支持双向通信。EventSource API（JavaScript）和OkHttp SSE（Android）是流行的库。当客户端不需要通过同一通道发回数据时，SSE 适用于新数据的通知。

根据WhatsApp Engineering（2024年），他们的同步引擎结合使用 WebSocket 进行活动会话和 FCM 在后台唤醒应用：WebSocket 在5分钟不活动后断开，后续更新通过静默推送传递。

快照同步与数据版本控制

基于快照的同步 — 服务器定期创建数据的完整快照并分配版本号。客户端存储当前版本号。如果过期，则下载新快照。这是一种简单可靠的策略，但对于频繁更改效率低下——每次都下载完整数据集。

记录级版本控制 — 每条记录都有一个version字段。同步时，客户端发送所有记录的版本，服务器仅返回版本已更改的记录。这比快照同步更高效，但需要在客户端存储版本。向量时钟 — 分布式系统的高级技术，每个节点分配自己的版本，冲突按偏序解决。

带增量差异的快照 — 混合方法：罕见的完整快照（每天一次）+ 之间的增量同步。长时间缺席后，客户端下载快照，频繁同步时仅下载增量。类似 Git 的方法 — 每个数据提交都有哈希值，客户端知道从哪个提交开始。这在 Couchbase Lite Sync Gateway（2024年）中实现，是可靠性的标准。

data class VersionedEntryT(
    val id: String,
    val data: T,
    val version: Long,
    val deleted: Boolean
)

fun SyncEngine.resolveVersion(local: VersionedEntry*, remote: VersionedEntry*): VersionedEntry* =
    when {
        local.version > remote.version -> local
        remote.version > local.version -> remote
        else -> resolveConflict(local, remote)
    }

版本解决规则：如果版本匹配，则无变更。如果本地版本更新，则本地获胜。如果服务器版本更新，则服务器获胜。仅在版本相等但数据不同时，才调用冲突解决器。Last Write Wins 带 version 标志——最简单但可靠的策略。

如何为移动应用构建同步引擎

第1步：定义数据模型 — 哪些实体需要同步，变更频率如何，数据量多大。为每个实体确定策略（增量/全量/推送）和允许的同步延迟。

第2步：选择协议 — 带检查点的 REST、带订阅的 GraphQL 或带双向流的 gRPC。GraphQL 订阅是现代应用的热门选择：一个协议同时用于拉取和推送。Apollo Client（2025年）支持通过设备缓存进行离线同步。

第3步：实现离线队列 — 带幂等键的本地变更存储（参见《离线队列》一文）。队列是可靠同步引擎的基础：没有它，同步无法保证变更的传递。

第4步：选择冲突解决器 — 简单情况用 LWW，协作编辑用 CRDT，业务逻辑用自定义合并。规则：解决器必须是幂等的——重复应用相同操作必须产生相同结果。

第5步：监控和指标 — 记录每次同步：记录数量、执行时间、冲突数量、错误。Firebase Crashlytics 或 Sentry（2025年）允许实时跟踪同步错误。

根据Realm 团队（2024年）的数据，典型移动应用的同步引擎每台设备每天处理100–500次同步，每次会话平均传输50–200 KB数据。协议优化——使用 Protobuf 压缩代替 JSON——可将传输数据量再减少40–60%。