我正在使用UIManagedDocument和ubiquity选项（NSPersistentStoreUbiquitousContentNameKey和NSPersistentStoreUbiquitousContentURLKey）测试Core Data和iCloud。 一切正常。我的设备在合理的时间内没有问题地同步。 DB很小（低于100K）。
正如我所说，我正在测试应用程序并对数据库进行大量更改，因此会生成大量事务日志。我遇到的问题是，如果我在其中一个用于测试的设备上删除并重新安装应用程序（不删除iCloud数据），该应用程序需要很长时间才能打开文档。 openWithCompletionHandler需要几分钟，有时永远不会结束。如果我打开调试（-com.apple.coredata.ubiquity.logLevel 3），我可以看到等待很长时间，然后使用事务日志重建数据库。 如果我删除iCloud数据并在第一个设备上重新插入数据，则第二个同步没有问题。因此，我认为延迟的原因是大量的事务日志（测试时20-30，我可以在developer.icloud.com上看到） 根据{{3}}将自动处理核心数据，但我看不到任何删除。也许这需要更多的时间。
我的问题是：事务日志是否会得到整合？我可以强制整理日志吗？另一个推荐的选择？
我只存储在iCloud Core Data文件中同步所需的基本信息子集。我有另一个带有完整数据库的本地文件，因此我可以重建iCloud数据库而不会丢失任何重大信息。也许当我检测到一堆日志并重新创建它时，我可以删除iCloud DB。你认为这是一个不错的选择吗？
感谢您的帮助。
答案 0 :(得分：2)
事务日志是否得到整合？
这就是它应该如何运作。
我可以强制整理日志吗？
没有。没有API直接影响事务日志的存在。 iCloud系统会在某些时候对它们进行整合，但没有关于何时发生这种情况的文档，而且你无法强迫它。
另一个推荐选项？
您可以间接限制事务日志的数量 - 减少更改频率。事务日志对应于保存Core Data中的更改。它可能没什么区别，因为老实说，20-30个事务日志并不是很多。您可以减少日志文件的数量，但是它们仍然具有相同数量的数据。
事务日志确实不是你的问题。正如您所观察到的，在iCloud开始运行事务日志之前需要等待很长时间。在此延迟期间，iCloud正在与Apple的服务器通信并下载事务日志。其中一些受到网络速度和延迟的影响，其余的只是iCloud的方式。