我有一个UIDocument
基于应用程序使用NSFileWrapper
s 来存储数据。 “主”文件包装器包含许多附加的目录文件包装器,每个包装器代表文档的不同页面。
保存仅修改了一小部分页面的大型文档时,UIDocument
在后台花费很长时间编写更改(在writeContents:andAttributes:safelyToURL:forSaveOperation:error:
)。当然,它应该只写出对文件包装器的这一小更改......什么花了这么长时间?
My contentsForType:error:
override 返回一个新的目录文件包装器,其中包含主文件包装器的内容(à laWWDC 2012 会议 218 - 将 iCloud 与 UIDocument 结合使用 http://adcdownload.apple.com//wwdc_2012/wwdc_2012_session_pdfs/session_218__using_icloud_with_uidocument.pdf):
- (id)contentsForType:(NSString *)typeName error:(NSError *__autoreleasing *)outError
{
if (!_fileWrapper) {
[self setupEmptyDocument];
}
return [[NSFileWrapper alloc] initDirectoryWithFileWrappers:[_fileWrapper fileWrappers]];
}
这是来自 Time Profiler 的堆栈跟踪的可爱图片:
顺便说一句,它说工作线程中需要节省约 1.6 秒 - 在实际运行时间中这相当于大约 8 秒。
Edit:
有什么方法可以检查文件包装器是否需要写入磁盘?只是这样我可以确认我没有以某种方式做一些奇怪的事情,例如当我进行小更改时更新每个子文件包装器(尽管我确定我没有......)。
Edit:
我进一步尝试了 CloudNotes 示例应用程序,看起来NSFileWrapper
does实施增量节省,至少在这种情况下!我通过初始化一个包含 100 个注释的文档来测试它,每个注释包含大约 5MB 的数据。我在这里和那里做了一些小编辑(对文本视图的单个字符更改将文档标记为需要保存),并大致记录了每次保存花费的时间。测试相对粗糙(在模拟器上运行),但结果是这样的:
- 第一次写入:~8000ms
- 第二次写入:~4000ms
- 第三次写入:~300ms
- 所有后续写入:~40ms
显然,有很多因素影响它所花费的时间,特别是因为它是在后台线程中使用文件协调来保存的,但总的来说,趋势似乎总是这种指数衰减,直到所有写入变得非常快。
但我仍在试图找出为什么这不会在我的应用程序中发生。对于大型多页文档(很大,但仍然比我上面执行的 CloudNotes 测试的文档小很多倍),用户可能需要等待很多秒才能关闭文档。我不想为实际上应该是瞬时的事情安装一个旋转器。