我正在运行自己的测试，但我也对其他iOS设备的体验感兴趣，以及Apple是否记录了这种行为（因为我找不到它）。
此外，我很好奇处理依赖于不间断文件I / O（如Core Data / sqlite数据驱动应用程序）的应用程序的这种情况的最佳实践。是否是通过UIDevice检查电池的最佳解决方案，如果电池电量不足则不会尝试写入数据库？
动机：我有一位iPod Touch用户在应用程序正在使用设备电量耗尽后报告重大数据丢失。看来DB文件已损坏。根据用户的操作，可能会在设备关闭之前触发Core Data保存操作。
更新：我正在努力从用户那里获取实际的数据库文件以分析它是如何被破坏的（我推断它已损坏，因为应用程序的当前行为表明持久存储已加载而某些可以读出数据，但无法保存新的更改）。我愚蠢地没有办法在应用程序中内置。但是，我认为可以使用this实用程序从设备的用户非加密iTunes备份中提取数据库文件。
答案 0 :(得分：1)
我猜它就像设备耗尽内存一样被杀死了。您应该在进入后台状态时执行所有需要执行的保存到硬盘驱动器。
基本上总是假设一旦应用程序进入后台，它将永远不会被带到前台。
答案 1 :(得分：-1)
使用ios 5.1已经有好几年了，我们有几个关于电池关闭不足的报告也破坏了核心数据应用程序中的数据。
如果在保存操作期间发生这种情况，您最终会得到原始数据库（db.sqlite说）以及中间数据库（db~ .sqlite）。原始文件被销毁（数据库中没有表数据，但它仍然在应用程序中正确打开，并且几分钟之前几乎没有返回数千个实体）。我们的解决方法是检测这个，然后删除原始文件并重命名中间文件。我不知道这是否是推荐的，但这不是它的用途吗？
唯一的缺点是中间数据库filesize要大几倍。可疑？哦，是的，我的朋友！但它似乎有效。