核心数据 iCloud 交易日志

Question

我正在使用 UIManagedDocument 和 ubiquity 选项（NSPersistentStoreUbiquitousContentNameKey 和 NSPersistentStoreUbiquitousContentURLKey）测试 Core Data 和 iCloud。 一切正常。我的设备可以在合理的时间内毫无问题地同步。数据库很小（低于 100K）。

正如我所说，我正在测试应用程序并对数据库进行大量更改，结果生成了大量事务日志。我遇到的问题是，如果我在用于测试的其中一台设备上删除并重新安装该应用程序（不删除 iCloud 数据），该应用程序需要很长时间才能打开文档。 openWithCompletionHandler 需要几分钟，有时永远不会结束。如果我打开调试（-com.apple.coredata.ubiquity.logLevel 3），我可以看到有很长的等待时间，然后使用事务日志重建数据库。 如果我删除 iCloud 数据并在第一台设备上重新插入数据，则第二台设备同步没有问题。因此，我认为延迟的原因是大量事务日志（测试时为 20-30，正如我在 developer.icloud.com 上看到的那样） 根据Managing Core Data iCloud Transaction Logs 会自动处理核心数据，但我看不到任何删除。或许这还需要一些时间。

我的问题是：事务日志会合并吗？我可以强制合并日志吗？另一个推荐的选择？

我只将同步所需的基本信息子集存储在 iCloud Core Data 文件中。我有另一个包含完整数据库的本地文件，因此我可以重建 iCloud 数据库而不会丢失任何重大信息。当我检测到一堆日志并重新创建它时，也许我可以删除 iCloud DB。您认为这是一个不错的选择吗？

感谢您的帮助。

Answer 1

事务日志会合并吗？

这就是它应该的工作方式。

我可以强制合并日志吗？

没有。没有直接影响事务日志存在的 API。 iCloud 系统会在某个时候整合它们，但没有关于何时发生这种情况的文档，您无法强制。

另一个推荐选项？

您可以间接限制事务日志的数量——减少保存更改的频率。事务日志对应于保存核心数据中的更改。这可能没什么区别，因为老实说，20-30 个事务日志并不是很多。您或许可以减少日志文件的数量，但其中的数据量仍然相同。

事务日志并不是您真正的问题。正如您所观察到的，在 iCloud 开始运行事务日志之前需要等待很长时间。在此延迟期间，iCloud 正在与 Apple 的服务器通信并下载交易日志。其中一些受到网络速度和延迟的影响，其余的只是 iCloud 的方式。