TextField搜索过滤方案选型及列表内存管理相关技术问询

两种方案没有绝对的优劣，完全取决于你的数据规模和业务场景：

• 全量拉取本地过滤方案
  适用场景：单表数据量低于10000条、数据不会在其他页面/端频繁修改的情况。
  优势：onChange触发的过滤为纯内存操作，响应速度极快，输入搜索时无延迟感，代码逻辑简单，不需要处理异步、防抖、请求乱序等问题。
  劣势：初始加载全量数据时耗时更长，内存占用更高，如果数据存在多端/多页面修改的情况，本地缓存的快照和数据库实际数据会不一致，需要额外做同步逻辑。
• 实时查询数据库方案
  适用场景：单表数据量超过10000条、数据会被频繁修改的情况。
  优势：初始加载速度快，每次返回的都是数据库最新数据，不需要做缓存同步逻辑，内存占用仅和当前搜索结果的数量挂钩，不会因为总数据量大占用过多内存。
  劣势：必须加300~500ms的防抖逻辑，避免每输入一个字符就触发一次数据库IO导致不必要的性能开销，还要额外处理请求取消逻辑，避免前一次慢查询的结果覆盖后一次快查询的结果，出现搜索结果和输入内容不匹配的问题。

通用选型建议：移动端本地SQLite场景下优先选全量本地过滤方案，绝大多数业务场景下的数据量都远低于10000条，用户体验和代码维护成本都更优；如果是数据量极大的特殊业务，再考虑实时查询方案。

是否需要主动清空列表完全取决于列表的存储位置：

• 如果列表存储在页面级状态中：比如StatefulWidget的State属性、当前页面独有的Provider/Bloc实例中，页面销毁时对应状态实例会被GC自动回收，不需要主动清空，不会产生内存泄漏问题。
• 如果列表存储在全局状态中：比如全局单例类、全局共享的Provider/GetX控制器中，不需要使用时必须主动清空，否则数据会一直驻留在内存中，列表数据量大的情况下会导致内存占用过高，低端安卓设备甚至会触发OOM崩溃。
• 特殊场景建议主动清空：如果列表中存储了大对象（比如图片二进制数据、大文件引用），哪怕是页面级存储，主动清空也能加快GC回收速度，降低应用内存峰值；如果业务要求下次进入页面时不能展示上次的旧数据，也可以在页面离开时主动清空列表。

内容的提问来源于stack exchange，提问作者Mohammad Alamoudi