ios – UIDocument和NSFileWrapper架构和性能

我们最近将代码转换为使用UIDocument而不是直接操作文件系统上的文件,因此我们遇到了一些性能问题.我们想知道我们是否错误地使用了这个类,如果其他人有这些问题,以及解决它们的常用方法是什么.

我们的应用

我们有一个“鞋盒应用程序”来管理一堆文档,每个文档包含多个图像文件,这些文件可能非常重,一个小的元数据文件和一个小的预览图像.用户可以在她的设备上有许多文档(1000个文档).每个文档的文件都分组在一个目录中,我们使用NSFileWrapper来读取和写入它们.

当我们的应用程序启动时,它需要所有文档的元数据才能显示文档索引和预览图像的子集.用户滚动时会加载更多预览图像.

为了获取该信息,我们打开所有文档,阅读其元数据并预览图像(如果需要),关闭它们,然后根据需要再次打开.

问题#1：加载时间慢

打开所有文档并阅读其元数据需要花费大量时间.我认为有几个因素导致了这个问题：
– 每个文档打开动作都相对较慢
– 打开的文档块和完成块在同一队列上执行,这使得操作的延迟非常糟糕(我的文档是打开的,但是完成块必须等待X打开文档块才能运行)

我们考虑使用单独的索引文件来解决这个问题,但是这种方法的缺点是我们需要在两个地方管理元数据,并且我们需要保持它与文件系统同步,以防iCloud更改文件.

问题#2：线程化

每个打开的文档都创建自己的“文件访问线程”.当我们同时打开许多文档时,开销会破坏应用程序.

我们通过使用信号量同步打开操作来解决此问题.这种方法的缺点是它可以进一步减慢负载.

问题

>我们使用UIDocument的方式是否存在一些根本问题？如果不：
>有没有人遇到类似的加载时间问题？解决它的常用方法是什么？其他应用程序是否保留索引文件？
>有没有办法让UI文档使用线程池？如果没有,您如何控制资源使用？

谢谢！

好的,这里没有好消息.

我们尝试与业内的朋友协商,分析UIDocument并使用它的修改实现来改变其操作的各个方面,以便看看我们是否可以提高其性能但无济于事.

我的结论是UIDocument不适合这种用法 – 它不是为了支持我们对开放操作的延迟和吞吐量要求而设计的.只有在想要在任何给定时刻打开少量文件时才能使用UIDocument(很像文字处理器和绘图应用程序).
不可否认,这正是Apple的文档所说的,但我想我们必须了解它们的严重程度是多么严重:)

我们最终使用了一些“技巧”来改善用户体验,并且我们会尽快摆脱UIDocument.

所以我的建议是,只有在：

>您的应用程序本质上类似于基于文档的应用程序,这意味着您在任何给定时刻都不会打开多个文档
>您不需要文档中的信息来“发现”它们并将它们显示给用户,或者可以承担管理单独索引文件的开销
>您真的需要此类的自动保存/撤消/同步/ iCloud功能

然后使用它.否则考虑其他方案.

一个与问题没有直接关系的旁注,但我将在此处添加为公共服务：当我们从直接文件访问转移时,UIDocument的异步模型需要在应用程序架构中进行一些重大更改.如果您打算采取此行动,请仔细评估您需要做的工作.

祝你好运未来的程序员.

相关文章