是否值得在 TextChanged 事件上等待几毫秒？答案

【问题标题】：Is it worth waiting a couple of milliseconds on a TextChanged event?是否值得在 TextChanged 事件上等待几毫秒？
【发布时间】：2010-02-14 20:39:44
【问题描述】：

我有一个用于在移动设备上过滤客户操作的文本字段。我想知道当用户输入少于 3 个字符时我是否应该在启动代码之前等待几毫秒，并且仅在文本长于或等于 3 个字符时才执行代码。

执行的代码需要更长的时间（大型数据库上的类似 sql 的语法），并且用户会在列表视图上看到闲逛。

你怎么看？

【问题讨论】：

【解决方案1】：

延迟对文本更改事件的 SQL 查询确实是个好主意。我们确实在整个 Android 中使用了这种技术。我们还始终确保取消任何先前的查询。例如，如果用户键入“ab”，并且我们在用户键入“a”后发布一条消息以启动查询，那么当用户键入“b”时我们会取消该消息。

【讨论】：

【解决方案2】：

如果用户在您的代码启动时看到 hang-outs，我不会立即启动它。

假设查询是根据用户的输入动态执行的，我会等到您输入足够的字符来处理更轻松的查询并且不会让 UI 陷入困境。尤其是使用%LIKE% 语法，您必须使用的字符更少，这意味着更大的查询和更长的用户等待时间。

【讨论】：

【解决方案3】：

由于源代码可用，我会尝试使用与 android 原生应用程序相同的方法。例如Contacts。

在您搜索联系人时检查他们的操作。

【讨论】：

我不明白他们在做什么，这对我来说看起来很复杂。能用文字解释一下吗？
我没有检查他们做了什么。我刚刚告诉过你可以在哪里寻找。
联系人在另一个线程上执行查询。它在获得第一个输入后立即开始查询，并尽可能频繁地运行查询，直到它赶上用户迄今为止输入的任何内容。这允许它同时响应单个字母和一批输入速度快于查询运行速度的字母。

【解决方案4】：

当焦点移动到另一个输入字段时，某些应用程序还会执行输入验证，并且在编辑输入时不检查输入。我不确定这是否是一件好事（我觉得有点混乱），但这绝对是解决问题的一种方法......

【讨论】：

【解决方案5】：

在 iPhone 上，如果您在启动搜索后看到用户输入延迟，您可能需要将查询操作移至后台线程，并能够像 RG 提到的那样取消旧搜索。

前几个字符稍微延迟可能是有意义的，但之后没有延迟 - 大约三到四个之后，您可能有足够的字符开始返回有意义的结果。

【讨论】：