需求分析：
用户快速连续输入时，如果需要实时响应用户输入。比如实时搜索，那么需要快速响应输入内容，尽快地完成搜索任务。在服务器端，由于性能强大，只要网络流畅，实时搜索并不是问题。国内的百度和国外的 Google 都能实时显示搜索结果。但在移动客户端本地搜索时，如果数据量大，在低端机型流畅地响应实时输入会比较困难。
实现方案：
一个2000条联系人，外加总计人数5000左右的群聊成员的数据量大小。输入完成，要流畅地显示结果并匹配高亮输入文案，要求从输入完成到输入下一个字符的不足1秒的时间内，完成搜索匹配。如果不能完成搜索，就会给用户卡顿的感觉。其实不用在输入文案每次变化都去进行搜索，可以等待一定时间间隔再拿最新的输入数据，去进行匹配。间隔低于指定时间间隔就忽略，控制搜索的频率。在 iOS 端已经有 Message Throttle 方案能够实现消息截流限频。果断引入，创建一个 MTRule，然后应用。
但是实际使用时发现，快速输入时，有两个问题：
- 输入卡顿
- 搜索的结果出现了大的延迟，有时甚至接近1分钟
这个是不能忍受的，必须得解决。
输入卡顿
明显是输入的主线程被阻塞。由于原来的实现都是在主线程进行搜索，必须创建一个并发的全局队列。然后将搜索封装到 NSOperation 中，放进队列里。借助 《NSOperation 的进阶使用和简单探讨 》这篇文章的分析，指定 queuePriority 为NSOperationQueuePriorityVeryHigh，以及 qualityOfService 为 NSQualityOfServiceUserInteractive。
然后等待搜索完成，切换回主线程，渲染 UI。
搜索结果延迟
在搜索任务里面，打印正在搜索的字符串，发现 Message Throttle 并没有起到作用，每一个字符输入后，都会进行一次搜索。
看来得在调用此函数前就限制，即提前截流。
但是仍然会有部分字符串进行了多余的搜索，比如:
连续输入: z h e n, 按照预期，只要执行搜索: zhen 一次即可。
但实际上，还可能搜索了 zhe。
想到 NSOperation 有一个 cancel 方法，可以在加入新的搜索任务前，取消之前的搜索任务。
高兴地添加后，运行发现，还是会有部分多余搜索。详细查看 API说明，发现:
原来， cancel 方法不会取消正在执行的任务，由于是快速输入，之前的搜索是来不及取消的。
仔细思考，突然脑洞一开，不管用户输入多么快，同一时刻输入的文字是唯一的。在搜索任务时，判断下当前最新的输入内容，与分配的搜索任务的字符串是否一致。如果一致，再进行详细的搜索匹配。否则，啥也不做。加了后，最终的实现方案如下图。
小结：
使用 Message Throttle ,实现了限制用户输入频率的效果。使用 NSOperation 和 NSOperationQueue ，将搜索的任务分配到子线程，不影响交互。同时在搜索开始判断当前的最新输入内容是否与将要搜索的内容一致, 一致再继续搜索。
最终，实现了高频输入，丝滑般的体验。基本上在用户输入下一个字符前，能显示搜索的结果。当然，这也得益于搜索算法的高效。关于搜索匹配用到的拼音及拼音首字母匹配算法，详见 《 iOS 字符串搜索匹配拼音或拼音首字母算法实现》。
有不足之处，欢迎指正。
