我一直在使用+[NSURL fileURLWithPath:]
它,因为它很方便,但在分析中我发现这是瓶颈的来源,因为它在调用+[NSURL fileURLWithPath:isDirectory:]
(或 Core Foundation 等效项)之前会查询文件系统:
path
如果它以斜杠结尾,则此方法假定它是一个目录。如果path
不以斜线结尾,则该方法检查文件系统以确定path
是文件还是目录。如果path
存在于文件系统中并且是一个目录,则该方法附加一个尾部斜杠。如果path
文件系统中不存在,则该方法假定它表示文件并且不附加尾部斜杠。
如果可能的话,我想避免这种开销。但我并不总是提前知道我正在构建的 URL 是否是目录。例如,可能只给我一个路径,或者给我一个目录和其中的项目(未知类型)的名称。我的问题是,即使结果可能不准确,总是忽略NO
是否可以?isDirectory
特别是,我想确保这不会搞砸-[NSURL getResourceValue:forKey:error:]
并且NSFileManager
.
一些基本测试并没有发现这种优化有任何不良后果,但这并不意味着没有。我并不完全清楚为什么 NSURL
首先关心isDirectory
。查看CFURL 源代码,代码似乎试图确保目录路径始终以斜杠结尾。但是,除了出于显示目的之外,我不清楚为什么这对文件系统路径很重要。NSString
(在使用来表示路径时,这从来都不是问题。)文档+[NSURL fileURLWithPath:isDirectory:]
说isDir
是:
一个布尔值,指定
path
在解析相对路径组件时是否将其视为目录路径。YES
如果路径指示目录则通过,否则NO
。
事实上,如果我使用-[NSURL initWithString:relativeToURL:]
,新的 URL 不包括最后一个组件,baseURL
除非它是用YES
for创建的isDirectory
。但是,我认为我从未调用过此方法,而且系统似乎不需要代表我这样做(对于上述用例)。我注意到-[NSURL URLByAppendingPathComponent:]
在必要时插入斜杠,而不是假设IS_DIRECTORY
标志是正确的。那么,除了创建相对 URL 之外,这个标志是否重要?即使我愿意,在一般情况下似乎也不可能总是传递正确的值。文件系统总是可以从我下面改变。如果我使用该路径,系统也无法始终确定它,+[NSURL fileURLWithPath:]
因为文件系统中可能尚不存在该路径。