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