NSURL书签:更快的替代方案？

Question

上下文

我的应用程序模型是一个对象树,其中每个对象代表给定起始文件夹下的磁盘上的文件系统项(文件夹或文件).

我会定期递归地从上到下遍历这个树,以便将它"同步"到文件系统的实际状态.也就是说,我访问模型中的每个对象并验证它所代表的文件/文件夹是否仍然存在于磁盘上的相同位置.

如果文件/文件夹已移动,我使用NSURL书签来确定文件/文件夹的新位置,以便我可以更新我的模型的状态.(我NSURL在第一次创建模型对象时创建了一个书签,然后将书签数据存储为对象的属性,以便我以后可以解决它.)

---

问题

NSURL书签根本不够高效.我的模型图有20,000个嵌套对象并不罕见.每个人都有一个书签.以下是我在分析性能时所看到的内容:

该recursivelyValidateExistingChildItemsOfParentItem:...方法是我的模型树.所涉及的90%的时间只是解析书签(如果它们是陈旧的,则按Apple的文档中的描述重新创建它们).

这个应用程序需要将近2分钟才能完成步行.所以,我需要一个更快的NSURL书签替代品.

---

我考虑过的

1. 扩展文件属性.我可以为磁盘上的每个文件添加一个UUID属性.我可以走在起始文件夹下面的实际文件系统,而不是走我的模型图.当我找到一个新文件时,我可以看到它是否具有UUID扩展属性.如果是这样,我可以在模型图中搜索具有该UUID的对象来处理移动/重定位的文件.这里的麻烦是许多东西破坏了扩展文件属性 - 它们不能保证坚持下去.

2. BDAlias或NDAlias.我曾经BDAlias在迁移到NSURL书签之前使用过,但这并不是特别高效.

---

底线

我需要一个更快的替代NSURL书签.但我仍然需要能够在我的应用程序的启动过程中跟踪文件,因此只需保持文件描述符打开或使用文件ID不起作用.

我不在乎我的低级水平; 我只需要表现.谢谢!

Answer 1

我知道这个问题很老了。但这是我的答案：

我只使用解析书签作为后备。我将文件路径和 URL 书签数据保存在模型中。当我想打开文件时，首先检查该文件是否仍然存在于先前已知的位置。如果没有，我会尝试解析 url 的书签数据。这会将调用范围缩小到URL.init(resolvingBookmarkData)仅对有限的项目子集。然后，我会在解析书签后使用新路径更新模型，以保持合理的性能。

如果您需要确保使用完全相同的文件，您可以检查文件的日期、大小或特定 EA 作为额外的衡量标准。