本文源自 Yiğit Boyar 在 360|AnDev 的演讲，建议有空看下，绝对会有收获：Yotube | Article | Slide，这里 Boyar 从整体架构讲述了 RecyclerView : 它是如何工作，有哪些优先注意事项，以及你该如何充分利用它们。
Introduction
RecylerView 有三种主要组件：
- LayoutManager 负责定位 views
- Item Animator 负责管理动画
- Adapter 负责处理 views
在后续优化 RecyclerView 的过程中，我们并没有添加新的 API，而是加入新的组件，比如控制 Item drag，drop 和 swipe 动作的 ItemTouchHelper；以及控制 snap 动作的 SnapHelper。
I. 视图更新 View Updates
首先要讨论 View::requestLayout。这与 RecyclerView 无关，它是 Android 视图系统的一部分。
当你对某个 view 做了一些修改，这个 view 会向上层的 viewGroup 说：“我现在需要 request layout，因为我发生了变化。”然后这句话会向上冒泡直到 根布局( root layout ) 回复：“👌 ，我在下个 布局帧( layout frame) 的时候通知你。”
下个帧开始时，根布局会通知所有的子 view：“重新 measure 自己，这是你们重新获得 layout 的时刻。”每个子 view 将会递归地 measure 它们自身。现在，假如没有 view 请求布局，所有的这些 measure 的尺寸将会被缓存。
现在所有的 view 的层次结构趋于稳定，这对于 RecyclerView 来说意味什么呢。
假如 Adapter::onBindViewHolder 有如下的逻辑:
onBindViewHolder(ViewHolder holder, int position) {
...
imageLoader.loadImage(holder.imageView, ImgUrl, R.drawable.placeHolder);
}
ImageLoader 异步地从网络上下载图片资源，将其转化为 bitmap，然后调用 ImageView，设置 image bitmap。
上述步骤发生时，ImageView 会说：“我原来的数据已经无效了，让我请求一次布局吧”。消息被传递到 imageView 的父布局 itemView，itemView 会说：“👌 ，看来我的子 view 已经无效了，我来请求布局吧”。最终消息被传递到 RecyclerView，RecyclerView 会复位所有的子 view ，这是一个很 expensive 的操作。
还记得 RecyclerView::setHasFixedSize 吗，可以在这里使用。如果 RecyclerView 拥有固定的尺寸，它知道不需要复位子 view，也就不会请求布局。
然而 RecyclerView::setHasFixedSize 仅会使 RecyclerView 不会调用 requestLayout()；对于其子 view ，还是会经历完整的 requestLayout() 过程，这同样是个 expensive 的操作。
好消息是从 2011 年开始，ImageView 的绘制逻辑做了一些优化：
// ImageView.java Since 2011
void setImageDrawable(Drawable drawable) {
if (mDrawable != drawable) {
int oldWidth = mDrawableWidth;
int oldHeight = mDrawableHeight;
updateDrawable(drawable);
// 只有在 Drawable 尺寸变化时才请求布局
if (oldWidth != mDrawableWidth || oldHeight != mDrawableHeight) {
requestLayout();
}
invalidate();
}
}
更新 Drawable 时，它会检查 Drawable 大小是否有变化，如果不变，则不会调用 requestLayout()，只调用 invalidate()，invalidate 会在原位置上重新绘制视图，这是一个 cheap 的操作。
对于 TextView 则不是这样，即使你两次设置相同的字符串，TextView 依然会调用 requestLayout()。
我们加载一些图片，假如其中某张图片不在内存中会发生什么？在图片加载完成之前，你添加了 placeholder。布局看起来很稳健，但实际上并不是这样。
理想状态下 The Tall Bird 未加载完，placeholder 空白展示，The Watch 始终位于左侧，但实际上 StaggeredGridLayoutManager 会将 The Watch 置于右侧，因为 item 检测到其 ImageView 的 height 为 0，其余的 item 都会依据上层的 item 安置自己 ImageView 。
解决这种问题可以通过自定义 ImageView：
// AspectRatioImageView.java
private float mAspectRatio;
@Override
protected void onMeasure(int wSpec, int hSpec) {
int width = MeasureSpec.getSize(wSpec);
int height = (int) (width * mAspectRatio);
setMeasureDimension(width, height);
}
自定义的 AspectRatioImageView 可以根据已知的 宽高比(aspect ratio) 调整自己的 size，然后复写 onMeasure 方法，设置 measure 后的尺寸。依据之前提到的 setImageDrawable 机制，当我们获取到实际的图片后，它并不会调用 requestLayout，而是直接更新 placeholder。
那么问题来了，如何设置宽高比呢？假设后端的 API 是这样：
{
"user" : {
"name" : "Michael",
"photoUrl" : "https://..."
}
}
这无法解决我们的问题，如果 API 能提供图片的 metadata 这样会不会更好：
{
"user" : {
"name" : "Michael",
"photoUrl" : {
"width" : 300,
"height" : 500,
"url" : "https://...",
"palette" : {}
}
}
API 提供了宽和高，这样我们方便计算宽高比，同时我们可以在下载实际图片之前根据宽高比及 palette 设置好合适的 placeholder。
II. 数据更新 Data Updates
假设我们从服务端获取到一组新的新闻数据，然后刷新列表：
直接使用 Adapter::notifyDataSetChanged 会存在如下问题：
- RecyclerView 更新数据集时并不知道到底数据集的哪里发生了改变，于是只能非常低效地从位置 0 开始，重新绑定一遍数据。
解决这种问题的方法也比较简单，使用 Adapter::getItemId:
long getItemId(int position) {
news.get(position).getId();
}
现在 RecyclerView 知道每个位置对应的 ID，可以根据 ID 判断哪个位置该去绑定数据，然而当你使用 Adapter::notifyDataSetChanged 时，它同样需要对其他的 item 进行多余的 measure 和 layout。针对这种场景，我们提供了 SortedList。
SortedList
通过简单的几个方法实现了所有元素的排序，并且有内置的逻辑提供 RecyclerView 的数据更新。
SortedList<Item> mSortedList = new SortedList<>(Item.class, new SortedListAdapterCallback<Item>(mAdapter)) {
@Override
public int compare(Item oldItem, Item newItem) {
return oldItem.id - newItem.id;
}
@Override
public boolean areItemsTheSame(Item oldItem, Item newItem) {
return oldItem.id == newItem.id;
}
@Override
public boolean areContentsTheSame(Item oldItem, Item newItem) {
return oldItem.text.equals(newItem.text);
}
});
通过使用 SortedList，我们可以将服务端获取新的数据直接添加到 SortedList 上，它会为我们通知 adapter 数据更新：
void onFetched(List<News> newsList) {
mSortedList.addAll(newsList);
}
SortedList 为我们添加 Item 提供了便捷的方法，但是假如我们获取的新的 Item 数据，是旧的 Item 的某项数值发生了变化，比如(add("To Rx or Not To Rx", 9))：
我们修改 compare 方法，根据 votes 数值大小排列数据:
SortedList<Item> mSortedList = new SortedList<>(Item.class, new SortedListAdapterCallback<Item>(mAdapter)) {
@Override
public int compare(Item oldItem, Item newItem) {
return newItem.votes - oldItem.votes;
}
...
});
得到的排序是这样的：
当你插入某项数据到 SortedList 中时，它会简单的做二分查找。从中间的 item 开始，判断是向上还是向下比较，因此无法判断原先的 item 是否已经存在【数据集】中。
如何解决这种问题呢？SortedList 提供了 SortedList::updateItemAt 方法：
Map<Integer, Item> items;
void inset(Item) {
Item existing = items.put(item.id, item);
if (existing == null) {
mSortedList.add(item);
} else {
int index = mSortedList.indexOf(existing);
mSortedList.updateItemAt(index, item);
}
}
SortedList 会对插入的 Item 进行判断，假如存在数据集中，进行更新；假如不存在，直接添加。这个效果不错，不过我们提供了更便捷的工具: DiffUtil。
DiffUtil
先看看使用的 API:
DiffResult result = DiffUtil.calculateDiff(new MyDiffCallback(oldList, newList));
mAdapter.setItems(newList);
result.dispatchUpdateTo(mAdapter);
DiffUtil::calculateDiff 接收 DiffUtil.Callback 回调方法，返回 DiffResult，设置新的数据集，然后调用DiffResult::dispatchUpdateTo 方法更新数据。
DiffUtil.Callback 与 SortedListAdapterCallback 实现的方法比较类似：
class MyCallback extends DiffUtil.Callback {
@Override
public int getOldListSize() {
return mOld.size();
}
@Override
public int getNewListSize() {
return mNew.size();
}
// 判断两个数据集是否相同
@Override
public boolean areItemsTheSame(int oldItemPosition, int newItemPosition) {
return mOld.get(oldItemPosition).id == mNew.get(newItemPosition).id;
}
// 判断两个数据集中的元素是否相同
@Override
public boolean areContentsTheSame(int oldItemPosition, int newItemPosition) {
return mOld.get(oldItemPosition).equals(mNew.get(newItemPosition));
}
}
III. 资源管理 Resource management
RecyclerView 的生命周期：
ViewHolder 通过 onCreate 方法创建，然后绑定到某个位置，绑定后可以认为 ViewHolder 快速 attach 到视图中，接收到 onViewAttachedToWindow 回调后，ViewHolder 出现在屏幕中，对用户可见。
当用户滑动或其他操作时，item 也许被 detach，比如当你把某个 item 滑动到屏幕之外时，Layout Manager 决定移除这个条目，这个时候会收到 onViewDetachedFromWindow 回调。
例如我们有一个视频订阅列表，滑动列表，当视频滑出屏幕时停止播放，滑入屏幕时开始播放，这是一个很好的方式去改善视频隐藏和出现时的用户体验。
RecyclerView 是异步的
RecyclerView 是异步的是什么意思？
这里并不是表示 RecyclerView 是多线程的，这里表示的是它处理事务是异步的。
当新帧出现时，RecyclerView 会向 View 应用所有待处理的修改并进行视图更新。
例如你调用 scrollToPosition(15)。当下个帧出现时，RecyclerView 会应用这些修改:
recyclerView.scrollToPosition(15);
int x = layoutManager.getFirstVisibleItemPosition();
然后你通过 LayoutManager 获取第一个可见的位置，它会返回15吗？实际上不会，RecyclerView 并不会立即执行滑动，而是等待下一帧开始才去执行。
void onCreate(SavedInstanceState state) {
...
// 两个都是在下一帧执行，所以它们看上去像是同步的。
mRecyclerView.scrollToPosition(selectedPosition);
mRecyclerView.setAdapter(mAdapter);
}
下面的方法也会执行：
void onCreate(SavedInstanceState state) {
...
mRecyclerView.scrollToPosition(selectedPosition);
model.loadItems(items ->
mRecyclerView.setAdapter(
new ItemAdapter(items));
);
}
为什么在下一帧开始时，我们还没有 adapter，设置的滑动还能奏效呢？
原因其实很简单，当你有一个 RecyclerView，在没设置 adapter 和 Layout Manager 之前，它将忽略所有的 layout 调用。
ViewHolder艹
填充数据的最佳实践：
class ViewHolder {
...
// ViewHolder 代表一个 item，更加抽象，便于移植到 Presenter 等位置。
public bindTo(Item item, ImageLoader loader) {
titleView.setText(item.getTitle());
bodyView.setText(item.getBody());
loader.loadImage(iconView, item.getIconUrl());
}
}
void onBindViewHolder(ViewHolder holder, int position) {
holder.bindTo(items.get(position), mImageLoader);
}
ViewType 的最佳实践：
在 RecyclerView::getItemViewType 方法直接返回 layout:
@Override
public int getItemViewType(int position) {
User user = mItems.get(position);
if (user.isPremium()) {
return R.layout.premium;
}
return R.layout.basic;
}
生成 RecyclerView::ViewHolder:
public RecyclerView.ViewHoder onCreateViewHolder(ViewGroup parent, int viewType) {
View view = mLayoutInflater.inflate(viewType, parent, false);
return new ViewHolder(view);
}
Item Click Listener 的最佳实践：
class MyAdapter {
interface ItemClickListener {
void onClick(Item item);
}
ItemClickListener itemClickListener;
void setItemClickListener(ItemClickListener itemClickListener) {
this.itemClickListener = itemClickListener;
}
public onCreateViewHolder(...) {
final ViewHolder holder = ...;
holder.itemView.setOnClickListener({
// 获取 view holder 在 adapter 中的位置
int position = holder.getAdapterPosition();
if (position != NO_POSITION) {
itemClickListener.onClick(items[position]);
}
});
}
}
