我将 iCloud 与 Core Data 结合使用，基于 Apple 指定的 SQLite“库式”应用程序设计。虽然基本功能运行良好，但我担心事务日志及其管理方式。
虽然我的应用程序的数据库并不大，但它非常活跃，核心数据堆栈在应用程序使用过程中被多次保存。我注意到为每个 核心数据保存创建了一个新的事务日志。最终结果是我有大量事务日志，它们占用的空间比实际数据库多得多。
1) 事务日志是否会自动修剪/合并，或者它们会继续无限增长，最终达到数千个并占用许多兆字节？似乎手动清除事务日志并重新创建 .baseline 存档的唯一方法是禁用然后重新启用 iCloud(删除无处不在的容器并重新开始)。但这显然不是一个好的解决方案。
2) 我目前的架构经常保存核心数据堆栈，即使是微小的变化。通常，这是有道理的，因为我的数据库很小，并且经常保存可以确保数据库文件始终是最新的。但是，考虑到事务日志的上述问题，我认为我应该尽量减少对数据库的保存。也许定时和/或在应用程序转换状态下这样做。
3) 即使我通过减少保存数据库的频率来最小化事务日志的数量，这里似乎也存在一个问题，因为日志的数量会随着时间的推移继续增长。最终，“事务日志”设计的好处将成为使用的 iCloud 存储量和添加新设备时初始 iCloud 同步方面的负担。
由于 Apple 提供的有关 iCloud 的信息非常少，而且几乎没有以“最佳实践”的形式提供任何信息，因此我非常感谢社区的任何见解。
最佳答案
我就此问题提交了雷达并收到了以下回复。他们注意到它应该在 iOS 5.1 中正常工作，尽管我自己还没有验证过这一点。
对任何可能误解以下内容的人进行澄清。事务日志将由核心数据内部清理。这不应该由应用程序本身执行。
Engineering has provided the following feedback regarding this issue:
The transaction logs are intended to be deleted after all the active peers have had a chance to read them, and they exceed a threshold of space consumed. There was a previous issue that prevented the devices from correctly doing so.
关于iphone - 管理核心数据 iCloud 事务日志，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8704662/