在iOS上删除包含大量文件的文件夹的性能 [英] Performance of deleting folder with lots of files on iOS
问题描述
说我的iOS应用的数据目录中有一个文件夹，其中有数千个小文件。删除此文件夹（通过 [NSFileManager removeItemAtPath] ）花费的时间很短。但是在OS X上，删除具有相同内容的文件夹非常快。似乎只是将文件夹与文件系统取消链接。那么，为什么iOS需要这么长时间？有什么区别？
Say I've got a folder in my iOS app's data directory with several thousand small files in it. Deleting this folder (via [NSFileManager removeItemAtPath]) takes a nontrivial amount of time. But on OS X, deleting a folder with the same contents is very fast. It seems to simply unlink the folder from the filesystem. So why does iOS take so long? What is the difference?
编辑：在iPad 3上，删除3个文件夹，每个文件夹5,000至9,000个文件，大约需要35秒。在较旧的Retina MBP上运行的模拟器上，大约需要1.5秒。
On an iPad 3, deleting 3 folders with 5,000 to 9,000 files each takes about 35 seconds. On the simulator running on an older Retina MBP, it takes about 1.5 seconds.
推荐答案
您看到的结构不是真实的-目录
并不是它们似乎包含的文件的物理容器。
目录层次结构是经过精心维护的小说。
The hierarchical structure that you see is not "real" -- directories are not physical containers for the files that they appear to contain. The directory hierarchy is a carefully maintained fiction.
撇开惯用语：原始的Mac文件系统使
更进一步-它使目录结构完全是虚构的
－所有文件都位于（3.5）软盘的根上，并且只有好像是可以放置在文件夹中。幸运的是，这是
被HFS取代。
Irrelevant aside: The original Mac file system took this a step further -- it made the directory structure totally a visual fiction -- all of the files were at the root of the (3.5") floppy) disk, and only seemed to be arranged in folders. Thankfully this was supplanted by HFS.
最好将目录/文件夹视为一种特殊的文件
，其中包含一组文件的索引
It is better to think of directories/folders as a special kind of file that contains an index to a set of files that it is going to pretend to contain.
从概念上讲，这很像经典的可可记忆管理。每个（目录/对象）通过引用
拥有一组（文件/对象）（保留（文件/对象））。
Conceptually, this works much like classical Cocoa memory management. Each (directory/object) "owns" a set of (files/objects) by reference ("retains" the (file/object)).
当您从目录中删除文件时，该文件将被释放。如果没有其他
目录对该文件具有所有权声明，则该文件将被取消分配。
When you delete a file from a directory, it is "released". If no other directory has an ownership claim on that file, it is "dealloc'ed".
您的（文件夹/对象）不包含其拥有的对象。
甚至没有真正拥有它们-它只是对
拥有所有权要求。
Your (folder/object) doesn't contain the objects that it "owns". It doesn't really even "own" them -- it just has a "ownership claim" on them.
来自Wikipedia的文章硬链接：
From Wikipedia's article about Hard Links:
硬链接是将名称与文件系统上的文件关联的目录条目。
包含此类条目列表的一种特殊类型的文件。
"a hard link is a directory entry that associates a name with a file on a file system. A directory is itself a special kind of file that contains a list of such entries."
请注意，由于使用了硬链接，因此一个单一的
物理文件可能出现在多个目录中。这些目录
中的每个目录都拥有对真实文件的引用。每个引用
都和其他引用一样真实。对于
，所有引用都必须取消链接，以将文件标记为已删除。
Note that due to the use of hard links it is possible to have a single physical file that can appear in multiple directories. Each one of those directories owns a reference to the "real" file. Each reference is as "real" as any other. All references have to be "unlinked" for the file to be marked as deleted.
文件甚至可以在不同的文件中具有不同的名称
目录！
The "file" can even have different "names" in the different directories!
硬链接是文件系统功能的链锯-功能强大，但
可能非常危险。请注意，OSX GUI没有提供
产生硬链接甚至符号链接的方法。
Hard links are the chain saw of filesystem features -- powerful, but potentially quite dangerous. Note that the OSX GUI provides no means of producing hard links, or even symlinks.
来自此电子邮件列表项目。
现在关于iOS
[NSFileManager removeItemAtPath：error：]，它在
的作用是循环访问子目录和文件并删除
首先。这需要一些时间。我有兴趣是否有可能
立即执行此操作，甚至不需要隐式递归。只需删除
目录，文件和子目录就会消失？
[NSFileManager removeItemAtPath: error:], what it does under the hood is they iterate through the subdirectories and files and delete them first. This takes some time. I am interested if it is possible to do this instantly, without even implicit recursion. Just remove the directory and the files and subdirectories would disappear?
您能做的是
-
如果您担心这会花费时间，并且需要即时结果，则可以重命名该文件夹（实际上是即时的），然后删除重命名的文件夹，并将其内容放在后台
If you're worried about the time this would take and you need an instant results you could rename the folder (which is virtually instantaneous) then remove the renamed folder and it's contents in a background thread.
如果时间有限，如果没有问题，请尝试在后台线程中运行删除过程。
If time is a constraint, try running the delete process in a background thread, if it is not a problem.
这篇关于在iOS上删除包含大量文件的文件夹的性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
