当前位置：首页 > article >正文

【Android】画面卡顿优化列表流畅度六（终篇）

article 2024/12/22 13:21:22

上一篇：
【Android】画面卡顿优化列表流畅度五之下拉刷新上拉加载更多组件RefreshLayout修改

场景回顾：

业务经过一年半左右的运行后，出现了明显的列表卡顿情况；于是开始着手进行列表卡顿优化。目前的情况是：

网络图片渲染耗时大
上下滑动反应慢，甚至画面不动
新增一页数据加载渲染时耗时比较大，上下滑动几乎没有反应，画面停止没有交互响应
交互体验基本摆烂了

计划的优化方向：

列表组件RecyclerView刷新机制由notifyDataSetChanged()优化为notifyItemRangeInserted（），后期有必要也会使用notifyItemRangeRemoved、notifyItemRangeChanged、notifyItemMoved等等方式更新刷新数据
Glide图片加载库优化参数设置：缩略图thumbnail（0~1.0f）、RequestOptions里sizeMultiplier、override、dontAnimate、noTransformation()等
内存优化设置clearMemory() 磁盘清理设置clearDiskCache()
RefreshLayout下拉刷新上拉加载更多组件；因为布局嵌套等原因这个组件和NestedScrollView不兼容；另外这个组件里的上拉加载更多的逻辑居然是有bug的，而且是对画面顿感很致命的逻辑漏洞。查了好久才发现的。吐血一升表示无语中
分页加载由于历史原因并不能统一返回10条，而是有可能大于20条这样的情况存在，再吐一升；非常无语，本来图片就够重了，现在发现某些页数据数量也很重。

最终的优化方案如下：

RecyclerView刷新机制notifyItemRangeInserted已做说明这里不累赘了

https://lichong951.blog.csdn.net/article/details/134331699

Glide加载图片参数值设置也已说明

https://lichong951.blog.csdn.net/article/details/134378026

RefreshLayout下拉刷新上拉加载更多组件二次优化开发–也已说明

https://lichong951.blog.csdn.net/article/details/134398047

上面这几点是程序上的优化点，还有内存方面的优化项比较少，就不重复写了，本应该写完这三点之后应该就完结了，但列表加载网络图片的卡顿情况不只是程序上的问题，这是一整套系统工程，因此补充这一章说明整套优化项和优化方案策略

图片的大小和尺寸设定

由于每项业务场景使用的图片都是从后台管理上传的，但由于之前都是同一组的开发同事进行图片处理上传，知晓UI设计图片的大小和尺寸要求，因此在长达一年使用过程中都没有问题，但后面其他业务开发组的数据图片接入之后就导致了问题所在，所以回顾之前UI设计效果图片尺寸如下162x188：
在这里插入图片描述
因此给出的后台上传图片要求为
1、分辨率：162 x 188 也不是必须是这个尺寸，可以作为参考尺寸使用。像之前的那种1108 x 1282是肯定不可以的了
2、大小：参考值是5kb以下；1kb最佳。但考虑到不同业务组的实际情况，可以放开到20kb以下即可。这样的大小基本不影响渲染效果和耗时，当然如果业务上进行极限操作也可以设置到1kb以下
3、图片格式作为android当然更倾向使用webp格式的图片，但有可能IOS那边不兼容，所以使用png格式是最优解了
以上是对网络图片的参考要求了

分页数据条数设定

这个对于一般的项目上应该不是问题，基本都能做到按分页要求每页10条拉取数据；
但笔者的项目就奇葩了一些需要规范一下，原本也是每页10条数据。
但后期版本迭代的时候，其他项目组的业务数据接入的时候发生了扭曲了。不能按原本的那种方式拉取每页10条数据，而是按日期拉取数据条数。这也是为什么有时候新增的页会有超过20条数据的情况发生，虽然不多，但叠加网络图片和glide的使用不当于是就体现在用户体验上卡顿情况明显了。
于是就针对性提出了后台的每天的数据条数要在10条以下，如果超过就放到后面的设定日期里，如果后面的日期里超过10条，则同理放到更后面的日期里即可。

另外就是列表布局的嵌套问题了

/**
* 布局嵌套为
* NestedScrollView
* BGARefreshLayout
* RecyclerView
* */

这样的xml布局结构笔者后来想了想应该是所有的一般的下拉刷新上拉加载更多组件都不会兼容了，也只有实际使用场景才会出现，这个就要考验开发者对开源组件和实际布局之间的落差而进行二次开发补充了。
笔者当前的博客也不过是补充了其中一种情况而已，实际的场景和UI交互设计等可能还有多种布局嵌套情况，比如横向列表嵌套到纵向列表等等，还有viewpage多重嵌套等等。
但都不用太过担心，android这些年的技术博客都足以解决这些问题。
到此整个优化过程基本完成。其实原本可以只写几个优化点就可以了，后来想了想还是做成一个完整系列把列表卡顿的优化彻底从头到尾的搞定。
参考本系列基本都能开发出接近京东或者其他大厂首页的丝滑的交互体验效果！

======END

下面是一个推荐，笔者业余开发的一个提高开发效率的工具，有兴趣或者有疑问欢迎使用留言蛤！