我正在我的应用程序中设置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秒的延迟。这是预期的行为吗?
Some of the documentation和
NSFileCoordinator
的Here表示将NSFilePresenter
用于批处理操作,但是当我不进行批处理时,得到如此长的延迟似乎很奇怪。更新:这也发生在阅读中。
更新2:apparently是一个重现该问题的示例项目。
更新3:使用此API在应用程序及其扩展名之间进行协调是bad和idea ojit_a。但是问题仍然存在。
最佳答案
引用 File System Programming Guide ,您可以阅读以下内容:
我认为这是您在推迟操作的情况下。
可能的解决方案:
请仔细阅读 this ,以正确处理多个连续的写入操作, relinquishPresentedItemToWriter 可以完成此工作,同样适用于读取文件, relinquishPresentedItemToReader ,假设多个不同的对象都试图读取和写入同一文件。
PS:
我不知道您的应用程序到底能做什么,但我希望您已阅读以下内容: