处理10万+条Web JSON响应并结合SearchView与列表组件实现搜索优化

现有方案的性能瓶颈 #

• SharedPreferences本身是面向小体量键值对存储设计的，底层是XML文件，存储、读取10万条级的巨型JSON字符串时IO开销极大，且每次读取都会把全量JSON加载到内存，极易触发内存抖动甚至OOM
• 每次搜索都需要全量解析JSON、遍历所有条目做字符串匹配，时间复杂度为O(n)，10万条数据单次遍历就需要几十到几百毫秒，多次触发直接导致界面卡顿
• ListView的复用机制不完善，加载大量条目时渲染性能差

最优落地方案 #

1. 存储层替换为SQLite（推荐用Room做ORM封装） #

SQLite是移动端原生的轻量关系型数据库，针对大批量数据的读写、查询做了深度优化，完全适配该场景：

• 建物料存储表，给高频搜索字段加索引：
  建表语句参考：CREATE TABLE material (matcd TEXT PRIMARY KEY, matdesc TEXT);
  给物料编码加普通索引：CREATE INDEX idx_matcd ON material(matcd);
  如果需要频繁搜索物料描述字段，直接用SQLite的FTS3/FTS4建全文索引，模糊查询性能比普通LIKE查询高100倍以上
• 首次拉取到接口JSON后，直接在后台线程批量插入数据库：

  批量插入必须开启事务，10万条数据开启事务插入耗时可控制在1s以内，未开事务插入耗时会达到数分钟

2. 搜索逻辑优化 #

• 废弃onQueryTextSubmit触发搜索的逻辑，改为在onQueryTextChange回调加防抖触发：比如设置300ms的防抖窗口，用户输入停顿后才发起搜索，避免短时间内触发多次无效查询
• 搜索直接走SQL查询，不要全量加载数据：
  模糊查询SQL参考：SELECT * FROM material WHERE matcd LIKE '%?%' OR matdesc LIKE '%?%'，单次查询耗时基本在10ms以内，用户完全感知不到延迟
• 查询结果做分页加载：每次仅查询前20~50条匹配结果加载到列表，用户上滑到底部再加载下一页，避免一次渲染大量条目导致的卡顿

3. 渲染层优化 #

• 用RecyclerView替换ListView，RecyclerView自带成熟的条目复用机制，渲染数百条条目时的帧率比ListView高30%以上
• 废弃已被官方淘汰的AsyncTask，改用Kotlin协程或者WorkManager执行后台数据插入、查询任务，避免内存泄漏和线程调度开销

SQLite方案实测效果 #

10万条数据场景下，从接口请求完成到写入数据库完成耗时<2s，模糊搜索响应耗时<20ms，完全不会出现界面卡顿问题，内存占用比直接存JSON的方案低80%以上。

内容的提问来源于stack exchange，提问作者Vikash Kumar