问题描述
我们最近将代码转换为使用UIDocument而不是直接操作文件系统上的文件，因此我们遇到了一些性能问题。我们想知道我们是否错误地使用了这个类，如果有其他人有这些问题，以及解决它们的常用方法是什么。
We've recently converted our code to use UIDocument instead of manipulating files on the file system directly, and we've encountered some performance issues as a result. We are wondering whether we are using this class incorrectly, if anyone else had these issues, and what are the common ways to address them.
我们有一个鞋盒应用程序管理一堆文档，每个文档由多个图像文件组成，这些文件可能非常重，一个小的元数据文件和一个小的预览图像。用户可能在她的设备上有许多文档（1000多个文档）。每个文档的文件都分组在一个目录中，我们使用NSFileWrapper来读取和写入它们。
We have a "shoebox app" that manages a bunch of documents, each consisting of multiple image files that can be quite heavy, a small metadata file and a small preview image. The user may have many documents on her device (1000+ documents). Each document's files are grouped in an directory and we use NSFileWrapper to read and write them.
当我们的应用程序启动时，它需要所有文档的元数据才能显示文档索引和预览图像的子集。当用户滚动时，会加载更多预览图像。
When our app starts, it needs the metadata of all the documents in order to show a document index, and a subset of the preview images. More preview images are loaded as the user scrolls.
为了获取该信息，我们打开所有文档，阅读其元数据并预览图像（如果需要），关闭他们，然后再按需打开。
In order to get that information, we open all the documents, read their metadata and preview image if we need to, close them, and then open again on demand.
这需要很多时间打开所有文件并阅读他们的元数据。我认为有几个因素会导致这个问题：
- 每个文档打开动作相对较慢
- 打开的文档块和完成块在同一队列上执行，这使得操作的延迟非常糟糕（我的文档是开放的，但是完成块必须等待X打开文档块才能运行）
It takes a lot of time to open all the documents and read their metadata. I think there are several factors contributing to this problem: - Each document open action is relatively slow - The open document blocks and the completion blocks are executed on the same queue, which makes the operation's latency very bad (my document is open, but the completion block has to wait for X open document blocks before it can run)
我们考虑使用单独的索引文件来解决这个问题，但是这种方法的缺点是我们需要在两个地方管理元数据，并且我们需要让它与文件系统同步，以防iCloud更改文件。
We thought about solving this problem using a separate index file, but this approach has the drawback that we will need to manage the metadata in two places and that we will need to keep it synched with the file system in case iCloud changes the files.
每个打开的文档都会创建自己的文件访问线程。当我们同时打开许多文档时，开销会破坏应用程序。
Each open document creates its own "File Access Thread". When we open many documents concurrently, the overhead crushes the app.
我们通过使用信号量同步打开操作来解决此问题。这种方法的缺点是它可以进一步降低负载。
We solved this issue by synching the open operations using a semaphore. This approach has the drawback that it slows down the loading even more.
- 我们使用UIDocument的方式是否存在一些根本问题？如果没有：
- 是否有人遇到类似的加载时间问题？解决它的常用方法是什么？其他应用程序是否保留索引文件？
- 有没有办法让UI文档使用线程池？如果没有，你如何控制资源使用？
谢谢！
推荐答案
好的，这里没有好消息。
Ok, no good news here.
我们尝试咨询业内的朋友，分析UIDocument并使用它的修改后的实现改变其操作的各个方面，以便看看我们是否可以提高其性能但无济于事。
We tried consulting with friends in the industry, profiling UIDocument and using modified implementations of it that alter various aspects of its operation in order to see if we can improve its performance but to no avail.
我的结论是UIDocument不适合这种用法 - 它的设计并不是为了支持我们对开放式操作的延迟和吞吐量要求。只有在想要在任何给定时刻打开少量文件时才能使用UIDocument（很像文字处理器和绘图应用程序）。
不可否认，这正是Apple的文档所说的，但我想我们必须了解它们的严重程度是多么严重:)
My conclusion is that UIDocument is not suitable for this kind of usage - it is just not designed to support the latency and throughput requirements we have for open operations. UIDocument should only be used when you want to open a small number of files at any given moment (much like word processors and drawing apps). Admittedly, this is exactly what Apple's documentation says, but I guess we had to learn just how serious they were the hard way :)
我们最终使用一些改进用户体验的伎俩，我们会尽快离开UIDocument。
We ended up using some "tricks" to improve the user experience, and will move away from UIDocument as soon as we can.
所以我的建议仅限于：
- 您的应用程序本质上类似于基于文档的应用程序，这意味着您在任何特定时刻都不会打开多个文档
- 您不需要文档中的信息来发现它们并将它们显示给用户，或者可以承担管理单独索引文件的开销
- 你真的需要此类的自动保存/撤消/同步/ iCloud功能
然后使用它。否则考虑其他方案。
then use it. Otherwise consider other solutions.
与问题没有直接关系的附注，但我将在此处添加为公共服务：UIDocument的异步模型需要在应用程序架构中进行一些重大更改从直接文件访问转移。如果你打算做这个动作，请仔细评估你需要做的工作。
A a side note which is not directly related to the question but I will add here as a public service: UIDocument's async model required some major changes in the app architecture when we moved from direct file access. If you plan on making this move, evaluate the work you will need to do carefully.
祝你好运未来的程序员。
Good luck future programmers.
这篇关于UIDocument& NSFileWrapper架构和性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！