同步简介¶

本文档简要介绍了同步在桌面版 Firefox 中的实现方式。

通用、历史、同步引擎的结构¶

本节描述了同步过去是如何工作的——实际上，其中很大一部分仍然如此。虽然我们讨论了这一点是如何缓慢变化的，但这种背景知识很有价值。

对于任何同步的数据类型，往往有 3 个部分

同步 store 与实际的 Firefox 桌面存储交互。例如，在 passwords 引擎中，“存储”是指与 Services.logins 交互的那一层。

tracker 知道哪些内容应该同步。例如，当用户创建或更新密码时，正是跟踪器知道我们现在应该同步，以及应该更新哪些特定密码。

这通常是通过“观察者”通知来完成的——Services.logins、places 等在发生某些事件时都会发送特定的通知（实际上，其中一些是为了同步的利益而添加的）。

engine 将所有内容联系在一起。它与 store 和 tracker 协同工作，并跟踪其自己的元数据（例如，服务器上密码的时间戳，以便它知道如何获取仅更改的记录以及如何将其传递给 store，以便可以更新实际的基础存储）。

以上所有部分通常都在 services/sync/modules/engines 目录中，并且与它们同步的数据分离。

上面描述的系统反映了这样一个事实：同步是相对较晚“附加”到桌面版 Firefox 上的——例如，同步 store 与实际的 store 分离。这导致了许多问题——尤其是在 tracker 和引擎使用的元数据方面，以及对后端存储的更改经常会忘记同步存在的事实。

在过去几年里，同步团队得出结论，同步支持必须更紧密地集成到存储本身中。例如，Services.logins 应该跟踪何时发生会导致项目同步的更改。它还应该跟踪存储的元数据，以便如果（例如）通过创建新的空数据库来恢复损坏的数据库，元数据也应该消失，以便同步知道发生了某些错误并可以恢复。

但是，这是一个缓慢的过程——目前，bookmarks、history 和 passwords 遗留引擎已经得到了改进，因此存储承担了更多的责任。在所有情况下，由于实现原因，同步实现仍然具有 store，但它往往是围绕实际底层存储的薄包装器。

在 application-services 存储库中实现了多个用 Rust 编写的同步引擎。虽然这些通常是为移动平台完成的，但长期希望是它们可以重复用于桌面。代码树中的同步引擎提供了更多关于这些引擎的详细信息。

虽然没有现有的引擎被用 Rust 实现的引擎替换，但 webext-storage 引擎是通过 application-services 用 Rust 实现的，因此它不倾向于使用上面描述的任何基础设施。

希望随着时间的推移，我们将在桌面版 Firefox 中找到更多用 Rust 实现的引擎。