9

我正在设置NSFileCoordinator并NSFilePresenter在我的应用程序中，因此我可以安全地从我的 AppleWatch 应用程序执行文件 IO。在我的代码中有一些地方我会快速连续多次写入文件。这本身就是一个问题，我正在努力纠正它，但我注意到这个过程中有一些奇怪的行为。

我这样包装我的文章：

//In a class that implements NSFilePresenter:
NSFileCoordinator *coord = [[NSFileCoordinator alloc]initWithFilePresenter:self];
[coord coordinateWritingItemAtURL:self.presentedItemUrl options:0 error:nil byAccessor:^(NSURL *url)
{
  //do my writing here using CFWriteStreamRef or NSOutputStream
}];

在第一次写入时，写入块发生在 1 ms 内。coordinateWritingItemAtURL但在那之后，调用和执行写入块之间大约有 0.5 秒的延迟。

这是预期的行为吗？

一些文档说用于批处理操作NSFileCoordinator，但是当我不批处理时得到这么长时间的延迟似乎很奇怪。NSFilePresenterprepareForReadingItemsAtURLs:writingItemsAtURLs:options:error:byAccessor:

更新：阅读也会发生这种情况。

更新 2： 这是一个重现问题的示例项目。

更新 3：使用此 API 在应用程序及其扩展之间进行协调显然是个坏 主意。但问题仍然存在。

4

2 回答 2

4

参考文件系统编程指南，您可以阅读以下内容：

您可能希望避免直接从文件演示器方法合并更改。相反，将块异步调度到调度队列并在以后处理更改。这使您可以在您的应用方便时处理更改，而不会对 启动更改的文件协调器造成不必要的延迟。当然，当保存或放弃对文件的控制时（例如在 relinquishPresentedItemToReader : 、 relinquishPresentedItemToWriter :或 savePresentedItemChangesWithCompletionHandler : 方法中），您应该立即执行所有必要的操作，而不是推迟它们。

我认为这是您推迟行动的情况。

可能的解决方案：

请仔细阅读这篇文章，为了正确处理多个连续的写入操作，relinquishPresentedItemToWriter可以完成这项工作，同样适用于读取文件relinquishPresentedItemToReader，假设多个不同的对象正在尝试读取和写入同一个文件。

PS：

我不知道你的应用到底是做什么的，但我希望你已经阅读了这个：

如果您正在实现基于文档的应用程序，则不需要将文件呈现器语义合并到您的 NSDocument 子类中。NSDocument 类已经符合 NSFilePresenter 协议并实现了适当的方法。因此，您的所有文档都会自动将自己注册为相应文件的演示者，并执行保存更改和跟踪文档更改等操作。

于 2015-05-13T04:55:06.367 回答
3

在某些情况下是否可以使用选项NSFileCoordinatorReadingImmediatelyAvailableMetadataOnly进行阅读和NSFileCoordinatorWritingContentIndependentMetadataOnly写作？看起来这个 iOS8 选项可以帮助你。

于 2015-05-12T23:06:22.703 回答