我们的应用
我们有一个“鞋盒应用程序”来管理一堆文档,每个文档包含多个图像文件,这些文件可能非常重,一个小的元数据文件和一个小的预览图像.用户可以在她的设备上有许多文档(1000个文档).每个文档的文件都分组在一个目录中,我们使用NSFileWrapper来读取和写入它们.
当我们的应用程序启动时,它需要所有文档的元数据才能显示文档索引和预览图像的子集.用户滚动时会加载更多预览图像.
为了获取该信息,我们打开所有文档,阅读其元数据并预览图像(如果需要),关闭它们,然后根据需要再次打开.
问题#1：加载时间慢
打开所有文档并阅读其元数据需要花费大量时间.我认为有几个因素导致了这个问题：
– 每个文档打开动作都相对较慢
– 打开的文档块和完成块在同一队列上执行,这使得操作的延迟非常糟糕(我的文档是打开的,但是完成块必须等待X打开文档块才能运行)
我们考虑使用单独的索引文件来解决这个问题,但是这种方法的缺点是我们需要在两个地方管理元数据,并且我们需要保持它与文件系统同步,以防iCloud更改文件.
问题#2：线程化
每个打开的文档都创建自己的“文件访问线程”.当我们同时打开许多文档时,开销会破坏应用程序.
我们通过使用信号量同步打开操作来解决此问题.这种方法的缺点是它可以进一步减慢负载.
问题
>我们使用UIDocument的方式是否存在一些根本问题？如果不：
>有没有人遇到类似的加载时间问题？解决它的常用方法是什么？其他应用程序是否保留索引文件？
>有没有办法让UI文档使用线程池？如果没有,您如何控制资源使用？
谢谢！
解决方法
我们尝试与业内的朋友协商,分析UIDocument并使用它的修改实现来改变其操作的各个方面,以便看看我们是否可以提高其性能但无济于事.
我的结论是UIDocument不适合这种用法 – 它不是为了支持我们对开放操作的延迟和吞吐量要求而设计的.只有在想要在任何给定时刻打开少量文件时才能使用UIDocument(很像文字处理器和绘图应用程序).
不可否认,这正是Apple的文档所说的,但我想我们必须了解它们的严重程度是多么严重:)
我们最终使用了一些“技巧”来改善用户体验,并且我们会尽快摆脱UIDocument.
所以我的建议是,只有在：
>您的应用程序本质上类似于基于文档的应用程序,这意味着您在任何给定时刻都不会打开多个文档
>您不需要文档中的信息来“发现”它们并将它们显示给用户,或者可以承担管理单独索引文件的开销
>您真的需要此类的自动保存/撤消/同步/ iCloud功能
然后使用它.否则考虑其他方案.
一个与问题没有直接关系的旁注,但我将在此处添加为公共服务：当我们从直接文件访问转移时,UIDocument的异步模型需要在应用程序架构中进行一些重大更改.如果您打算采取此行动,请仔细评估您需要做的工作.
祝你好运未来的程序员.
