Android应用开发那些事

重走安卓进阶路——页面优化、组件优化

2020-08-06  本文已影响0人  小呀么小黄鸡

RecyclerView的优化
看完感觉我RecyclerView白学了!

一类是RecyclerView自带的系统优化,另一类就是我们通过代码实现的手动优化

自带的系统优化

  1. 自android25版本之后就有的预取技术(Prefetch),针对ViewHolder
  2. recyclerView的四级缓存:scrap、cache、extension和pool
    scrap——有两个成员mChangedScrap和mAttachedScrap,scrap是用来保存被rv移除掉但最近又马上要使用的缓存,比如说rv中自带item的动画效果
    cached——就linearlayoutmanager来说cached缓存默认大小为2,它的容量非常小,所起到的作用就是rv滑动时刚被移出屏幕的viewholer的收容所。
    extension——是一个自定义的缓存,一般都没有见过具体的使用场景
    pool——保存的对象就是那些无效的viewholer,复用它的rootview

我们可以进行的优化

  1. 降低item的布局层次(页面优化通用)

关于如何降低布局层次还是要推荐下google的强大控件ConstraintLayout,具体使用就自行百度吧。

  1. 去除冗余的setitemclick事件

RecyclerView 性能优化

数据处理和视图加载分离

我们知道,从远端拉取数据肯定是要放在异步的,在我们拉取下来数据之后可能就匆匆把数据丢给了 VH 处理,其实,数据的处理逻辑我们也应该放在异步处理,这样 Adapter 在 notify change 后,ViewHolder 就可以简单无压力地做数据与视图的绑定逻辑,比如:

mTextView.setText(Html.fromHtml(data).toString());

这里的 Html.fromHtml(data) 方法可能就是比较耗时的,存在多个 TextView 的话耗时会更为严重,这样便会引发掉帧、卡顿,而如果把这一步与网络异步线程放在一起,站在用户角度,最多就是网络刷新时间稍长一点。

数据优化

分页拉取远端数据,对拉取下来的远端数据进行缓存,提升二次加载速度;对于新增或者删除数据通过 DiffUtil 来进行局部刷新数据,而不是一味全局地刷新数据。

布局优化

减少过渡绘制

减少布局层级,可以考虑使用自定义 View 来减少层级,或者更合理地设置布局来减少层级,不推荐在 RecyclerView 中使用 ConstraintLayout,有很多开发者已经反映了使用它效果更差,相关链接有:Is ConstraintLayout that slow?constraintlayout 1.1.1 not work well in listview

减少 xml 文件 inflate 时间

这里的 xml 文件不仅包括 layout 的 xml,还包括 drawable 的 xml,xml 文件 inflate 出 ItemView 是通过耗时的 IO 操作,尤其当 Item 的复用几率很低的情况下,随着 Type 的增多,这种 inflate 带来的损耗是相当大的,此时我们可以用代码去生成布局,即 new View() 的方式,只要搞清楚 xml 中每个节点的属性对应的 API 即可。

减少 View 对象的创建

一个稍微复杂的 Item 会包含大量的 View,而大量的 View 的创建也会消耗大量时间,所以要尽可能简化 ItemView;设计 ItemType 时,对多 ViewType 能够共用的部分尽量设计成自定义 View,减少 View 的构造和嵌套。

其他

其他并不代表不重要,而是我不能把他们进行分类哈,其中可能某些操作会对你的 RecyclerView 有很大的优化。

上一篇下一篇

猜你喜欢

热点阅读