RecyclerView 性能优化-区域预布局

一、背景

RecyclerView的优化有很多机制，一般来说主要分为：

（1）ViewHolder 缓存预加载

这类主要提前填充ViewHolder缓存或者共享ViewHolder来实现

（2）图片预加载

利用ScrollListener机制，预测滑动方向，但是存在明显的鸡肋就是ImageView或者ImageView所在的Item尽可能的相似，如果RecylerView的复用时算法复杂度越高，性能增益也会越低，主要取决于viewType数量和各种View的交替复杂度。

（3）局部更新

一般很难去使用单个的notifyItemXXX方法，但是Android提供了一个比较好的工具，DiffUtil来优化，但是缺点是大部分场景必须复写equals和hashcode，不过收益也不错。

（4）动画

动画在低配设备上差异很明显，特别是帧动画，alpha动画 （alpha动画是离屏渲染2次，且缓存会被回收），如果能避免动画尽可能避免，特别是低端机型。

(5) 对象、资源共享

不需要为每个ItemView去new 一个监听器

Drawable可以ConstantState.newDrawable或者mutate复用

（6）减少RequestLayout

这里特别说一下TextView，看似简单，实际上性能损耗不少

（9）不使用inflater

inflater确实又些性能损耗

（10）

不给ImageView设置图片或者背景

二、可是区域优化-预布局

getExtraLayoutSpace

返回 LayoutManager 应布置的额外空间量。

默认情况下，LinearLayoutManager 在平滑滚动时额外放置 1 页项目，否则为 0。您可以覆盖此方法以实现您的自定义布局预缓存逻辑。
注意：布置不可见元素通常会带来显着的性能成本。它通常只适用于平滑滚动到未知位置等地方，其中 1) 额外的内容有助于 LinearLayoutManager 提前知道其目标何时接近，因此它可以尽早平滑地减速，以及 2) 当运动是连续的。
如果在用户可能改变滚动方向的情况下扩展额外的布局空间，代价尤其昂贵。改变方向将导致额外的布局空间交换到视口的另一侧，导致许多重新绑定/回收，除非缓存足够大以处理它。
返回值：应布置的额外空间（以像素为单位）。

此方法是一把双刃剑，对于ViewType较少的情况，实际上增益并不大，反而有损内存空间，但是对于ViewType交错排列的情况，反而是一种改善方式，但是最好不要超过1屏的高度。另外也可以很好的结局TV上焦点移动时，新View未加载，focus Down 时焦点乱飞的问题。