NSPredicate 与 NSString：哪个对于查找超字符串更好/更快？

Question

我有大量的字符串正在搜索以查看给定的子字符串是否存在。似乎有两种合理的方法可以做到这一点。

选项 1：使用 NSString 方法 rangeOfSubstring 并测试 .location 是否存在：

NSRange range = [string rangeOfSubstring:substring];
return (range.location != NSNotFound);

选项 2.使用 NSPredicate 语法CONTAINS：

NSPredicate *regex = [NSPredicate predicateWithFormat:@"SELF CONTAINS %@", substring];
return ([regex evaluateWithObject:string] == YES)

哪种方法更好，或者是否有一个我完全缺少的好的选项 3？不，我不确定“更好”到底是什么意思，但可能我的意思是在迭代很多很多字符串时更快。

Answer 1

您应该对使用 NSPredicate 的任何解决方案进行基准测试和计时，因为根据我的经验，NSPredicate 可能会非常慢。

为简单起见，我将使用简单的 for(NSString *string in stringsArray) { } 类型的循环。循环体将包含一个简单的 rangeOfSubstring 检查。通过使用 CFStringFind()，但只有在搜索大量字符串时您才会看到好处。使用 CFStringFind() 的优点是可以避免（非常小的）Objective-C 消息调度开销。再说一遍，当您搜索“很多”字符串（对于某些总是变化的“很多”值）时，切换到该字符串通常只是一个胜利，并且您应该始终进行基准测试以确保确定。如果可以的话，更喜欢更简单的 Objective-C rangeOfString: 方式。

一种更复杂的方法是将 ^Blocks 功能与 NSEnumerationConcurrent 选项结合使用。 NSEnumerationConcurrent 只是一个提示，表明您希望枚举在可能的情况下同时发生，并且如果实现不支持并发枚举，则可以随意忽略此提示。但是，您的标准 NSArray 很可能会实现并发枚举。实际上，这会产生划分 NSArray 中的所有对象并将它们分布在可用 CPU 上的效果。您需要小心如何改变 ^Block 跨多个线程访问的状态和对象。这是一种可能的方法：

// Be sure to #include <libkern/OSAtomic.h>

__block volatile OSSpinLock spinLock = OS_SPINLOCK_INIT;
__block NSMutableArray *matchesArray = [NSMutableArray array];

[stringsToSearchArray enumerateObjectsWithOptions:NSEnumerationConcurrent usingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
    NSRange matchedRange = [obj rangeOfString:@"this"];
    if(matchedRange.location != NSNotFound) {
      OSSpinLockLock((volatile OSSpinLock * volatile)&spinLock);
      [matchesArray addObject:obj];
      OSSpinLockUnlock((volatile OSSpinLock * volatile)&spinLock);
    }
  }];

// At this point, matchesArray will contain all the strings that had a match.

它使用轻量级 OSSpinLock 来确保一次只有一个线程可以访问和更新 matchesArray。您也可以在此处使用上面的相同 CFStringFind() 建议。

另外，您应该注意 rangeOfString: 本身不会匹配“单词边界”。在上面的示例中，我使用了单词 this，它将与字符串 A Palolithist walk in to the bar... 匹配，即使它不包含单词 >这个。

解决这个小问题的最简单的解决方案是使用 ICU 正则表达式并利用它的“增强断字”功能。为此，您有几个选项：

• NSRegularExpression，目前仅在 >4.2 或 >4.3 iOS 上可用（我忘了是哪个）。
• RegexKitLite，来自 RegexKitLite-4.0.tar.bz2
• NSPredicate，通过 SELF MATCHES ' (?w)\b...\b'。这样做的优点是它不需要任何额外的东西（即 RegexKitLite），并且可以在所有（？）版本的 Mac OS X 和 iOS 上使用。 3.0。

以下代码展示了如何通过 NSPredicate 在 ICU 正则表达式中使用增强的断字功能：

NSString *searchForString = @"this";
NSString *regexString = [NSString stringWithFormat:@".*(?w:\\b\\Q%@\\E\\b).*", searchForString];
NSPredicate *wordBoundaryRegexPredicate = [NSPredicate predicateWithFormat:@"SELF MATCHES %@", regexString];
NSArray *matchesArray = [stringsToSearchArray filteredArrayUsingPredicate:wordBoundaryRegexPredicate];

您可以通过替换 (?w: 中的 (?w: 使搜索不区分大小写>regexString 和 (?wi:。

如果您感兴趣，正则表达式基本上表示

• .*(?w:...).* 说“匹配 (?w:...) 部分之前和之后的任何内容”（即，我们只对 (?w:...) 感兴趣 。
• (?w:...) 表示“打开括号内的 ICU 增强断词/查找功能
• ” > （实际上只是一个反斜杠，任何反斜杠在 @"" 字符串内时都必须进行反斜杠转义）表示“在单词边界处匹配”
• \\Q.. .\\E 表示“将紧随 \Q 之后开始到 \E 的文本视为文字文本（认为“Quote”和“End”） ”。换句话说，“引用的文字文本”中的任何字符都没有其特殊的正则表达式含义。

\Q...\E 的原因是您可能想要匹配 searchForString 中的文字字符。如果没有这个，searchForString 将被视为正则表达式的一部分。例如，如果 searchForString 是 this?，那么如果没有 \Q...\E，它将不会< /em> 匹配文字字符串 this?，但是 thi 或 this，这可能不是您想要的。 :)

Answer 2

情况 (n)： 如果您有字符串数组来测试子字符串，那么最好使用 NSPredicate。

NSPredicate *regex = [NSPredicate predicateWithFormat:@"SELF CONTAINS %@", substring];
NSArray *resultArray = [originalArrayOfStrings filteredArrayUsingPredicate:regex];

这将返回包含子字符串的字符串数组。

如果使用NSRange，这种情况下，需要手动循环遍历数组的所有字符串对象，显然会比NSPredicate慢。