UIDocument & NSFileWrapper体系结构与性能

Question

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

我们的应用

我们有一个“鞋盒应用程序”来管理一堆文档，每个文档由多个可能相当重的图像文件、一个小元数据文件和一个小预览图像组成。用户可能在设备上有许多文档(1000+文档)。每个文档的文件都分组在一个目录中，我们使用NSFileWrapper来读取和写入它们。

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

为了获取该信息，我们打开所有文档，读取它们的元数据，并在需要时预览图像，关闭它们，然后根据需要再次打开它们。

问题1:加载时间慢

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

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

问题2:线程处理

每个打开的文档都创建自己的“文件访问线程”。当我们同时打开许多文档时，开销会使应用程序崩溃。

我们通过使用信号量同步打开操作来解决这个问题。这种方法有一个缺点，那就是它会进一步减缓加载速度。

问题

1. 我们使用UIDocument的方式有什么根本性的问题吗？若否，则：
2. 是否有人遇到过类似的装载时间问题？解决这一问题的共同方法是什么？其他应用程序是否保存索引文件？
3. 是否有办法使UI文档使用线程池？如果没有，如何控制资源的使用？

谢谢!

Answer 1

好吧，这里没有好消息。

我们尝试咨询业界的朋友，对UIDocument进行分析，并使用修改后的实现来改变其操作的各个方面，以确定我们是否能够提高它的性能，但没有效果。

我的结论是，UIDocument不适合这种使用--它的设计并不是为了支持开放操作的延迟和吞吐量需求。只有当你想在任何时候打开少量的文件(就像文字处理器和绘图应用程序一样)，UIDocument才能被使用。诚然，这正是苹果的文档所说的，但我想我们必须了解到，它们是多么的严肃:)

最后，我们使用了一些“技巧”来改进用户体验，并将尽快远离UIDocument。

因此，我的建议是只有在以下情况下：

1. 您的应用程序在本质上类似于基于文档的应用程序，这意味着您在任何特定时刻都不会有超过几个文档打开。
2. 您不需要文档中的信息来“发现”它们并将它们显示给用户，或者可以负担管理单独的索引文件的开销。
3. 您确实需要这个类的自动保存/撤消/同步/iCloud功能

那就用它。否则，考虑其他解决方案。

这是一个与这个问题没有直接关系的附带说明，但我将在这里作为一项公共服务添加:UIDocument的异步模型在我们从直接文件访问转移到应用程序体系结构时需要进行一些重大更改。如果你打算做这件事，请仔细评估你需要做的工作。

祝未来的程序员好运。

Answer 2

文档类具有异步读取的方法。你试过了吗？

Answer 3

这听起来更适合核心数据或SQLite，用于元数据。至少，在Core数据中缓存元数据(整个应用程序的一个存储区，而不是每个文档中的一个)。