频繁（5Hz）核心数据保存的性能开销答案

【问题标题】：Performance overhead for frequent (5Hz) Core Data saves频繁（5Hz）核心数据保存的性能开销
【发布时间】：2012-04-05 15:45:20
【问题描述】：

对于一个播放音频文件的 iPhone 应用，我正在开发一个系统来跟踪用户在他们收听的任何一集中的进度（例如，他们收听 file1 的前 4:35，然后开始另一个文件，然后返回到 file1，它从 4:35 开始）。

我已经设置了一个 Core Data 模型来存储元数据，但我想知道在播放期间我可以/应该多积极地缓存当前位置。

目前我刚刚卡住了保存：调用以前用于更新时间标签和 UISlider 播放头的方法。 NSTimerInterval 每 0.2 秒调用一次该方法。

0.2 秒的精度比我需要跟踪的进度缓存要高得多。无论如何，这些值都会四舍五入到最接近的秒数，因此基本上每次保存的 4/5 是多余的。

不过，鉴于这几乎是 Core Data 正在做的所有事情，它只在任何给定时间处理单个记录的单个值，我想知道做额外的事情是否更有意义，不必要的保存：或管理第二个计时器以减少更新频率。

Instruments 报告每个事件的保存持续时间约为 800，在 2000 年左右达到峰值。我不确定如何解释这些结果。模拟器中的实际应用性能似乎没有受到显着影响。

如果这种保存方法如此便宜以至于将代码复杂度保持在较低水平（仅管理一个计时器）是有意义的，我会保持原样，但我的直觉是，无论如何，这都是很多操作便宜。

【问题讨论】：

你可以跳过保存，当用户移动到另一个流时，只记录音频流中的当前位置吗？
我可以，但我有点担心，即使我做了一些跑腿工作以确保它总是在应用程序退出之前得到保存，如果它崩溃或（例如）连接断开并且对文件的访问丢失，或者其他一些边缘情况，它不会得到更新。我永远不想失去超过 10 秒的进度，所以我至少需要做一个 10 秒的计时器；但我不想仅有 10 秒的精度。
我明白了 - 您节省了多少数据？你真的只需要每
我只是将单个 NSNumber 属性保存在一个文档中。 10 秒是我在没有明确进行保存的情况下想要达到的最大值，所以我试图弄清楚每 5 秒、每 1 秒、五次之间存在什么样的性能差异（如果有的话）每秒等等。如果我可以在已经存在的当前计时器上搭载这个操作，我可以保持我的代码非常精简。如果我需要开始管理第二个计时器，事情会变得有点复杂，因为我使用的音频播放器库在下面工作。

【解决方案1】：

在性能方面的差异应该不会像在电池消耗方面看到的那么大。

在 iOS 设备中使用闪存写入磁盘比在计算机上写入旋转盘式 HDD 快得多。此外，与保持电镀旋转相比，写入 HDD 不会花费太多电力。但是，相对于读取或仅保留闪存而言，写入闪存存储需要更多功率。

换句话说，在 iOS 设备上写入的功耗不可忽略。如果您可以摆脱 4hz，那么很容易显着改善您的应用的电池消耗量。

【讨论】：

你能知道多少额外的电池吗？我意识到做同样的事情三倍的频率将使用三倍的功率。但是，假设收听一个小时长的播客，以 1Hz 的频率保存，会占用 2% 的电池（包括所有其他电话操作）。去 3Hz 会使用 6% 的面糊吗？还是像 2.1%？
嗯，这很难说。这取决于设备的具体型号、您的应用程序执行这些写入的秒数以及当时正在执行的其他操作。 Instruments 确实有一个工具可以模拟查看面糊消耗量。在这里查看：developer.apple.com/library/ios/#documentation/DeveloperTools/…
更正：上面评论中提到的工具可以帮助您测量实际设备上的电池消耗。