门户网站前期网络采集商家信息免费发布,珠海做企业网站,重庆百度推广seo,智能家居网站建设方案上一篇#xff1a; 【Android】画面卡顿优化列表流畅度五之下拉刷新上拉加载更多组件RefreshLayout修改
场景回顾#xff1a;
业务经过一年半左右的运行后#xff0c;出现了明显的列表卡顿情况#xff1b;于是开始着手进行列表卡顿优化。目前的情况是#xff1a;
网络图…上一篇 【Android】画面卡顿优化列表流畅度五之下拉刷新上拉加载更多组件RefreshLayout修改
场景回顾
业务经过一年半左右的运行后出现了明显的列表卡顿情况于是开始着手进行列表卡顿优化。目前的情况是
网络图片渲染耗时大上下滑动反应慢甚至画面不动新增一页数据加载渲染时耗时比较大上下滑动几乎没有反应画面停止没有交互响应 交互体验基本摆烂了
计划的优化方向
列表组件RecyclerView刷新机制由notifyDataSetChanged()优化为notifyItemRangeInserted后期有必要也会使用notifyItemRangeRemoved、notifyItemRangeChanged、notifyItemMoved等等方式更新刷新数据Glide图片加载库优化参数设置缩略图thumbnail0~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
下面是一个推荐笔者业余开发的一个提高开发效率的工具有兴趣或者有疑问欢迎使用留言蛤
smartApi接口开发工具推荐
推荐理由
postman在国内使用已经越来越困难 1、登录问题严重 2、Mock功能服务基本没法使用 3、版本更新功能已很匮乏 4、某些外力因素导致postman以后能否使用风险较大 出于以上考虑因此笔者自己开发了一款api调试开发工具SmartApi满足基本日常开发调试api需求
简介
历时一年半多开发终于smartApi-v1.0.0版本在2023-09-15晚十点正式上线 smartApi是一款对标国外的postman的api调试开发工具由于开发人力就作者一个所以人力有限因此v1.0.0版本功能进行精简大功能项有
api参数填写api请求响应数据展示PDF形式的分享文档Mock本地化解决方案api列表数据本地化处理再加上UI方面的打磨
下面是一段smartApi使用介绍
下载地址
https://pan.baidu.com/s/1kFAGbsFIk3dDR64NwM5y2A?pwdcsdn
