这篇文章讲的是“管道工程”，我不打算为此道歉。我们做的最不起眼的工作——让您的通联记录保持同步的引擎——恰恰是 DxQSO 其他一切功能的基础。如果这个引擎又慢又不可靠，那么构建在它之上的提醒、成就和协作功能也会同样又慢又不可靠。所以我们回过头，把它重建了一遍。
实时，才是关键所在
请记住 DxQSO 究竟是什么：它不是一本日志，而是一个把您已经在用的日志软件、连接到您口袋里的手机和收件箱里的邮件的系统。只有当您的通联记录真正实时时，这一切才能成立。LoTW® 上到达的确认，如果要过几个小时才通知到您，作为提醒就毫无价值。如果记录已经过时，您刚刚通联的新网格就不可能出现在您的成就里，也不会出现在俱乐部的共享动态中。在这里，实时不是锦上添花，它本身就是产品。
早期，随着日志增长到数万条通联，我们最初的同步路径开始吃力。在公园里信号勉强的情况下用手机打开记录，与在家里用高速台式机打开，是完全不同的难题，而第一代引擎并不是为这种场景设计的。因此，我们从头重写了 DxQSO 获取、缓存和更新您通联记录的方式。
底层到底改了什么
简单说，有三点。第一，同步现在是增量式的——系统只请求自上次检查以来发生变化的内容，而不是每次都把整份记录搬一遍。第二，每台设备上保存的数据更聪明了，查看和搜索通联记录不再需要等待网络。第三，我们收紧了用于判断“什么才是真正新增”的时间戳和记账机制——正是这个不起眼的细节，让“自上次以来有什么变化”足够可信，可以触发您能信赖的提醒。
这些都不会以按钮的形式出现。它体现在系统用起来干脆利落，体现在确认和动态几乎实时地送达您，而不是等应用哪天想起来才发现。
为弱信号而生，而非为实验室
真正考验同步引擎的地方，不是接着家用光纤的高速台式机，而是在公园小路尽头、只有两格信号的手机上，电量还得省着用，您只想在收拾设备前确认日志已经上传。这正是我们优化的场景。增量同步意味着在弱信号下的一次同步只传输几 KB，而不是您全部的通联历史。更聪明的本地数据意味着，即使网络完全断开，您已经拉取的记录依然可以随时滚动浏览和搜索。
同样的设计在家里也同样受益。当您的记录多达数万条通联时，“只请求变化”与“再全部拉取一遍”之间的差别，就是一本瞬间打开的日志与一本让您一想到就发怵的日志之间的差别。如今，引擎处理海量记录和少量记录时表现一致——只有这样，工具才能随着您多年来通联的增长而一直好用。
可靠到足以支撑提醒
速度只是一半的工作。提醒框架的可信程度，取决于其底层的时间戳。如果系统无法确定什么才是真正新增的，它要么漏掉确认，要么频频谎报——两者都会迅速消磨您的信任。错过一次新 DXCC 提醒令人失望；一连串的误报更糟，因为您会学会忽略提示音，然后真正重要的那条也就悄悄溜走了。收紧这套记账机制是看不见的工作，却是一条您真正会去处理的通知的全部基础。
正因如此，我们把“自上次以来有什么变化”当作头等问题来对待，而不是事后补救。DxQSO 承诺告诉您的每一个确认、每一个新网格、每一个奖状里程碑，都取决于系统能精确地知道它确实是新的。做对了，提醒就像魔法；做错了，整个理念就会崩塌。
为未来的一切打下基础
大多数公司根本不会提起这样的重建，而我之所以告诉您，是因为它默默支撑着我在未来一年最期待推出的那些功能：从野外和电台室自动采集通联；QSL 提醒即时推送到您的手机和邮箱；确认一到，成就立刻更新；俱乐部和团队实时看到彼此的动态。每一项都依赖于一个足够快、足够可靠、能跟上您实际通联节奏的同步引擎。
您不会在更新日志里看到“我们重写了数据引擎”这样一条。您只会发现：需要时记录总是最新的，提醒总在该到的时候到达，系统也从不碍事。这正是我们的全部目的——为 DxQSO 的其余一切打下实时的基础。
