记一次列表加载超一万条数据优化

本文分享了一次Android应用中遇到的大量数据加载优化问题。使用RecycleView + BaseMultiItemQuickAdapter展示10000~20000条数据时,通过分页加载、数据库索引优化、本地存储、线程控制、序列化选择、预加载策略以及RecyclerView布局优化等方式提升用户体验。重点讨论了避免主线程阻塞、减少UI绘制和提高数据处理效率的措施。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Android中列表是每个应用都会有的UI效果,而与用户的交互无非就是用户上下滑动、左右滑动、点击item 等等,本文就从小编遇到一次加载大量数据而影响体验优化之旅。

项目的列表采用RecycleView + BaseMultiItemQuickAdapter 分组效果,数据量10000~20000以上

数据拉取、缓存

首先是数据的获取方式,分页?还是全部获取? 这得考虑到后端的查询效率,数据库可以采用建立索引,提高效率,前端可以采用分页获取,并且为了提高体验,当然是存储在本地数据库了(NoSql),这里就有一个问题分页获取分页 再存储,数据库存储会导致阻塞线程,

果然出现了:Message Blocked in Main Thread XXXX ms,这是anr日志,说明,执行了耗时任务,UI 无响应。。。。。。。。。。 所以就想到了 这里采用了线程控制存储(建议采用线程池的方式来实现,不然物极必反,过多创建线程,浪费了资源。。。)

public CustomerReposity(){
      mThreadPool = new ThreadPoolExecutor(3, 5,
              10, TimeUnit.SECONDS, new LinkedBlockingDeque<Runnable>(128));
  }
复制代码
 mThreadPool.execute(new Runnable() {
                          @Override
                          public void run() {
                              Log.d("customer","thread save to db ::"+data.list.size());
                              saveCustomerToLocalDB(data.list, pageNumer == 1);
                          }
                      });

复制代码

从后端拉取到解析-再到数据库的时间

这边其实考虑到序列化,序列化有两种 Serializable\Parcelable,Serializable 采用反射机制,会导致大量对象产生,所以,考虑到性能的话,采用Parcelable

  @Override
  public void <
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值