BaseViewHolder 源码学习
接下来假设一个场景来分析,假设我们要给一个 TextView 控件设置一段文字进行显示,一般我们会使用该方法:
holder.setText(R.id.xxx,"hello world");
```java
源码:
```java
public BaseViewHolder setText(int viewId, CharSequence value) {
TextView view = getView(viewId);
view.setText(value);
return this;}
可以看到,源码里第一步会调用 getView(viewId)方法,我们来看下该方法的代码
@SuppressWarnings("unchecked")
public <T extends View> T getView(int viewId) {
View view = views.get(viewId);
if (view == null) {
view = convertView.findViewById(viewId);
views.put(viewId, view);
}
return (T) view;
}
代码中,他会先到 views 中根据 view 的 id 进行查找,看是否前面已经实时化该 view,如果实例化来,就直接拿来用就好。
如果 view==null 我们会通过 convertView 去调用我们再熟悉不过的 findViewById 进行创建,然后把创建的 view 实例缓存到 views 中方便下次使用,上面我们说到 convertView 是 viewholder 的 ItemView,也就是每个 item 的总布局。其实是在初始化 BaseViewHolder 的时候传进来的,源码所示:
public BaseViewHolder(final View view) {
super(view);
this.views = new SparseArray();
this.childClickViewIds = new LinkedHashSet<>();
this.itemChildLongClickViewIds = new LinkedHashSet<>();
this.nestViews = new HashSet<>();
convertView = view;
}
而 BseVIewHolder 的创建又是从我们的 BaseQuickAdapter 里面执行的,下一篇会分析 BaseQuickAdapter 的代码。
剩下的事情就相当简单了,如果从 views 缓存队列中找到了我们需要的 view,直接调用 setText 设置文字,没找到就先创建,然后压入缓存,然后再调用。其余的 api 调用方法执行的逻辑基本一样。
BaseViewHolder 里还有三个比较重要的成员
- HashSet nestViews;
- LinkedHashSet childClickViewIds;
- LinkedHashSet itemChildLongClickViewIds;
这是跟点击事件相关的,后面会单独出一篇来进行学习。
BaseQuickAdapter 之生命周期分析
BaseQuickAdapter 实例化第一步当然是调用我们的构造方法:
public BaseQuickAdapter(int layoutResId, List<T> data) {
this.mData = data == null ? new ArrayList<T>() : data;
if (layoutResId != 0) {
this.mLayoutResId = layoutResId;
}
}
public BaseQuickAdapter(List<T> data) {
this(0, data);
}
public BaseQuickAdapter(int layoutResId) {
this(layoutResId, null);
}
可以看到,加入你不传入 data,内部会先为我们创建一个空的 list,
然后在构造时记录我们的布局资源 id。
那么,布局资源 id 会在什么时候用呢,当然是在 onCreateViewHolder 方法中创建 viewholder 的时候,那么我没继续看 onCreateViewHolder 方法的代码。而调用 onCreteViewHolder 前会先调用 getItemViewType 方法。
@Override
public int getItemViewType(int position) {
if (getEmptyViewCount() == 1) {
boolean header = mHeadAndEmptyEnable && getHeaderLayoutCount() != 0;
switch (position) {
case 0:
if (header) {
return HEADER_VIEW;
} else {
return EMPTY_VIEW;
}
case 1:
if (header) {
return EMPTY_VIEW;
} else {
return FOOTER_VIEW;
}
case 2:
return FOOTER_VIEW;
default:
return EMPTY_VIEW;
}
}
autoLoadMore(position);
int numHeaders = getHeaderLayoutCount();
if (position < numHeaders) {
return HEADER_VIEW;
} else {
int adjPosition = position - numHeaders;
int adapterCount = mData.size();
if (adjPosition < adapterCount) {
return getDefItemViewType(adjPosition);
} else {
adjPosition = adjPosition - adapterCount;
int numFooters = getFooterLayoutCount();
if (adjPosition < numFooters) {
return FOOTER_VIEW;
} else {
return LOADING_VIEW;
}
}
}
}
从代码可以看到,他是根据我们 data 的 index 值以及我们是否开启空视图之类的数据来决定在 onCreateViewHolder 中应该返回什么类型的 viewHolder。
我们继续看 onCreateViewHolder 的代码:
@Override
public K onCreateViewHolder(ViewGroup parent, int viewType) {
K baseViewHolder = null;
this.mContext = parent.getContext();
this.mLayoutInflater = LayoutInflater.from(mContext);
switch (viewType) {
case LOADING_VIEW:
baseViewHolder = getLoadingView(parent);
break; case HEADER_VIEW:
baseViewHolder = createBaseViewHolder(mHeaderLayout);
break; case EMPTY_VIEW:
baseViewHolder = createBaseViewHolder(mEmptyLayout);
break; case FOOTER_VIEW:
baseViewHolder = createBaseViewHolder(mFooterLayout);
break; default:
baseViewHolder = onCreateDefViewHolder(parent, viewType);
bindViewClickListener(baseViewHolder);
}
baseViewHolder.setAdapter(this);
return baseViewHolder;
}
但是,在上面的代码中我们并没有看到有使用我们的 mLayoutResId 资源 id 的代码。我们可以看到,switch 里面前几个都是创建空视图啊,头部视图,底部视图之类的。default 这个 onCreateDefViewHolder 估计是我们需要找的代码,我们来看下这个方法:
protected K onCreateDefViewHolder(ViewGroup parent, int viewType) {
return createBaseViewHolder(parent, mLayoutResId);
}
里面调用来 createBaseViewHolder 方法,我们继续看:
protected K createBaseViewHolder(ViewGroup parent, int layoutResId) {
return createBaseViewHolder(getItemView(layoutResId, parent));
}
这里面先调用 getItemView
protected View getItemView(int layoutResId, ViewGroup parent) {
return mLayoutInflater.inflate(layoutResId, parent, false);
}
里面代码相当简单,就是根据布局资源 id 渲染我们的 view 然后返回。
然后才继续调用 createBaseViewHolder
protected K createBaseViewHolder(View view) {
Class temp = getClass();
Class z = null;
while (z == null && null != temp) {
z = getInstancedGenericKClass(temp);
temp = temp.getSuperclass();
}
K k = createGenericKInstance(z, view);
return null != k ? k : (K) new BaseViewHolder(view);
}
里面的代码主要是判断你是否在 adapter 中使用的 BaseViewHolder 的子类,大概意思是这样的,
temp=getClass()会返回我们当前的 adapter 的类型,然后其传入 temp 调用 getInstancedGenericKClass
private Class getInstancedGenericKClass(Class z) {
Type type = z.getGenericSuperclass();
if (type instanceof ParameterizedType) {
Type[] types = ((ParameterizedType) type).getActualTypeArguments();
for (Type temp : types) {
if (temp instanceof Class) {
Class tempClass = (Class) temp;
//判断tempClass是否是BaseViewHolder类型或者其子类型或者接口
if (BaseViewHolder.class.isAssignableFrom(tempClass)) {
return tempClass;
}
}
}
}
return null;
}
该方法最终会判断当前的类是否是 BaseViewHolder 的子类或者接口,如果是返回,不是返回 null。经过下面的三目运算
return null != k ? k : (K) new BaseViewHolder(view);
如果你不实用集成自 BaseViewHolder 的子类时,基本调用的是
(K) new BaseViewHolder(view)
在我们上一篇分析 BaseViewHolder 中有一个 convertView 字段的值及来自这里。
那么好,当 viewholder 被创建后,接下来就是数据绑定了,我们看一下源代码:
@Override
public void onBindViewHolder(K holder, int positions) {
int viewType = holder.getItemViewType();
switch (viewType) {
case 0:
convert(holder, mData.get(holder.getLayoutPosition() - getHeaderLayoutCount()));
break; case LOADING_VIEW:
mLoadMoreView.convert(holder);
break; case HEADER_VIEW:
break;
case EMPTY_VIEW:
break;
case FOOTER_VIEW:
break;
default:
convert(holder, mData.get(holder.getLayoutPosition() - getHeaderLayoutCount()));
break; }
}
大家从上面会看到很熟悉的一个函数
convert(holder, mData.get(holder.getLayoutPosition() - getHeaderLayoutCount()));
为什么 0 是我们正常要显示的数据呢?
default:
baseViewHolder = onCreateDefViewHolder(parent, viewType);
bindViewClickListener(baseViewHolder);
从 onCreateViewHolder 中可以看到在 default 情况下就是 viewType=0,该值来自 adapter 的 getItemViewType 方法
public int getItemViewType(int position) {
```
}
当既不是头部视图,也不是尾部视图,空视图时,他就会调用
getDefItemViewType(adjPosition);
protected int getDefItemViewType(int position) {
return super.getItemViewType(position);
}
可以看到,他返回的就是 0,所以 viewType 等于 0 就是正常加载数据的 viewHolder,然后我们将 holder 和经过计算
mData.get(holder.getLayoutPosition() - getHeaderLayoutCount())
后得到的该 positions 下的 data 传入 convert 函数,我们就可以拿着 holder 和 data 进行数据的绑定操作了
@Override
public void onBindViewHolder(K holder, int positions) {
```
}
从创建 adapter 到根据不同的情况创建不同的 viewholder 到绑定数据的流程。
BaseQuickAdapter 之预加载实现
autoLoadMore(int position) 见名知意,是与自动加载更多相关的。我们先看下该函数的代码实现
private void autoLoadMore(int position) {
if (getLoadMoreViewCount() == 0) {
return;
}
if (position < getItemCount() - mAutoLoadMoreSize) {
return;
}
if (mLoadMoreView.getLoadMoreStatus() != LoadMoreView.STATUS_DEFAULT) {
return;
}
mLoadMoreView.setLoadMoreStatus(LoadMoreView.STATUS_LOADING);
if (!mLoading) {
mLoading = true;
if (getRecyclerView() != null) {
getRecyclerView().post(new Runnable() {
@Override
public void run() {
mRequestLoadMoreListener.onLoadMoreRequested();
}
});
} else {
mRequestLoadMoreListener.onLoadMoreRequested();
}
}
}
第一句先判断 getLoadMoreViewCount 判断是否==0.其实他并不是简单的判断是是否有加载更多视图的数量。进入方法里:
public int getLoadMoreViewCount() {
if (mRequestLoadMoreListener == null || !mLoadMoreEnable) {
return 0;
}
if (!mNextLoadEnable && mLoadMoreView.isLoadEndMoreGone()) {
return 0;
}
if (mData.size() == 0) {
return 0;
}
return 1;
}
我们可以看到,他的返回结果跟很多因素有关,从代码很容易看出:
return 0 的情况:
1、你没有设置 mRequestLoadMoreListener 或者没有开启 mLoadMoreEnable 开关;
2、mNextLoadEnable = false ,mNextLoadEnable 在加载更多结束时,你调用
loadMoreEnd(boolean gone) 时会置为 false。且 mLoadMoreView 是处于 gone 状态的。
3、当数据源大小为 0 时接下来 autoLoadMore 方法中的第二句代码很重要
if (position < getItemCount() - mAutoLoadMoreSize) {
return;
}
理解起来大概是这样的,mAutoLoadMoreSize 是标识开启自动加载更多的一个数量阀值。这个返回很巧妙。
假设你的 data.size =20 ,mAutoLoadMoreSize =10,当前 position=9, 按照理解,这个 pisition=9 是个临界值,因为我们设置了剩余数量 <10 个时自动加载更多,此时计算 9<20-10,position 等于 9,说明后面还有 10 个数据没渲染,当 position=10 时(未加载数据还剩 9 个,此时应该预加载更多),10<20-10,不成立,代码继续往下走,执行
if (mLoadMoreView.getLoadMoreStatus() != LoadMoreView.STATUS_DEFAULT) {
return;
}
我们为什么还要做这个判断的。假如不做这个判断。直接执行下面的代码。
mLoadMoreView.setLoadMoreStatus(LoadMoreView.STATUS_LOADING);
if (!mLoading) {
mLoading = true;
if (getRecyclerView() != null) {
getRecyclerView().post(new Runnable() {
@Override
public void run() {
mRequestLoadMoreListener.onLoadMoreRequested();
}
});
} else {
mRequestLoadMoreListener.onLoadMoreRequested();
}
}
那么会出现很好玩的 现象,当你快速上滑时,由于 position>=10 后满足条件,执行加载更多的回调,position=11 时也会执行,以此类推,那么你将收到多次加载更多的回调。所以我们需要判断此时是否当前的加载更能多回调已完成,保证每次到达阀值后只调用一次加载更多回调方法。
理解了这个方法之后,我们接下来看下该方法在哪里被调用呢?
@Override
public int getItemViewType(int position) {
if (getEmptyViewCount() == 1) {
boolean header = mHeadAndEmptyEnable && getHeaderLayoutCount() != 0;
switch (position) {
case 0:
if (header) {
return HEADER_VIEW;
} else {
return EMPTY_VIEW;
}
case 1:
if (header) {
return EMPTY_VIEW;
} else {
return FOOTER_VIEW;
}
case 2:
return FOOTER_VIEW;
default:
return EMPTY_VIEW;
}
}
autoLoadMore(position);
int numHeaders = getHeaderLayoutCount();
if (position < numHeaders) {
return HEADER_VIEW;
} else {
int adjPosition = position - numHeaders;
int adapterCount = mData.size();
if (adjPosition < adapterCount) {
return getDefItemViewType(adjPosition);
} else {
adjPosition = adjPosition - adapterCount;
int numFooters = getFooterLayoutCount();
if (adjPosition < numFooters) {
return FOOTER_VIEW;
} else {
return LOADING_VIEW;
}
}
}
}
在 getItemViewType 方法中,为什么在这个方法里面呢,因为根据 recyclerView.Adapter 的执行逻辑,在渲染一个新的 itemview 时,会先调用 getItemViewType 询问我需要加载什么类型的 ViewHolder。在这里调用能更早的调用我们的加载更多的方法,当前,你在 onBindViewHolder 数据绑定方法中调用也可以实现这个功能。接下来就很好理解了,当 RecyclerView 在渲染一个新的 itemView 时,就会调用下
autoLoadMore(position);判断是不是需要调用加载更多回调,需要就调用,有关预加载的分析就 OK 啦
BaseQuickAdapter 上拉加载实现
首先我们先了解几个有关加载更多功能的方法
第一步:打开上拉加载的开关
public void setEnableLoadMore(boolean enable) {
int oldLoadMoreCount = getLoadMoreViewCount();
mLoadMoreEnable = enable;
int newLoadMoreCount = getLoadMoreViewCount();
if (oldLoadMoreCount == 1) {
if (newLoadMoreCount == 0) {
notifyItemRemoved(getHeaderLayoutCount() + mData.size() + getFooterLayoutCount());
}
} else {
if (newLoadMoreCount == 1) {
mLoadMoreView.setLoadMoreStatus(LoadMoreView.STATUS_DEFAULT);
notifyItemInserted(getHeaderLayoutCount() + mData.size() + getFooterLayoutCount());
}
}
}
通过上面方法打开我们的上拉加载的开关。首先我们先看下以下两个变量的意思。
1、oldLoadMoreCount 代表在改变这个开关时我们是否处于显示上拉加载的 view 的状态,1 表示处于该状态。
2、newLoadMoreCount 代表我们当前是否可以开启上拉加载功能,同样,1 表示可以。
这段代码很有意思
if (oldLoadMoreCount == 1) {
if (newLoadMoreCount == 0) {
notifyItemRemoved(getHeaderLayoutCount() + mData.size() + getFooterLayoutCount());
}
}
我们为什么要做插入这段代码呢,他的作用其实是这样的:加入当前处于显示加载更多 view 的状态,此时你想关闭该开关,那我们第一件事要做什么呢,当然是移除加载更多 view 了,这段代码的作用就是这个。
反过来,我们现在要开启上拉加载。走的是这段代码
else {
if (newLoadMoreCount == 1) {
mLoadMoreView.setLoadMoreStatus(LoadMoreView.STATUS_DEFAULT);
notifyItemInserted(getHeaderLayoutCount() + mData.size() + getFooterLayoutCount());
}
}
因为们的的 loadMoreView 一直是处于最底部的一个 view,所以我们通过调用
notifyItemInserted(getHeaderLayoutCount() + mData.size() + getFooterLayoutCount());
告诉 recycerlView 将 loadViewMore 显示出来。
当我们同过上拉加载加载新的数据完成后,我们需要告诉 BaseQuickAdapter 你可以恢复正常状态了,此时我们将用到以下方法:
@Override
public void onLoadMoreRequested() {
mSwipeRefreshLayout.setEnabled(false);
if (pullToRefreshAdapter.getData().size() < PAGE_SIZE) {
pullToRefreshAdapter.loadMoreEnd(true);
} else {
if (mCurrentCounter >= TOTAL_COUNTER) {
// pullToRefreshAdapter.loadMoreEnd();//default visible
pullToRefreshAdapter.loadMoreEnd(mLoadMoreEndGone);//true is gone,false is visible
} else {
if (isErr) {
pullToRefreshAdapter.addData(DataServer.getSampleData(PAGE_SIZE));
mCurrentCounter = pullToRefreshAdapter.getData().size();
pullToRefreshAdapter.loadMoreComplete();
} else {
isErr = true;
Toast.makeText(PullToRefreshUseActivity.this, R.string.network_err, Toast.LENGTH_LONG).show();
pullToRefreshAdapter.loadMoreFail();
}
}
mSwipeRefreshLayout.setEnabled(true);
}
}
//加载完成第一个 if 是防止我们错误的调用该方法。可以看到,方法内部帮我们调用了更新数据源的方法。而且是局部更新。
public void loadMoreComplete() {
if (getLoadMoreViewCount() == 0) {
return;
}
mLoading = false;
mLoadMoreView.setLoadMoreStatus(LoadMoreView.STATUS_DEFAULT);
notifyItemChanged(getHeaderLayoutCount() + mData.size() + getFooterLayoutCount());
}
我们看到这么一句恢复我们的 loadMoreView 为默认值,我们可以跟进去看下一下
mLoadMoreView.setLoadMoreStatus(LoadMoreView.STATUS_DEFAULT);
他内部是重置了 loadMoreStatus 这个字段
public void setLoadMoreStatus(int loadMoreStatus) {
this.mLoadMoreStatus = loadMoreStatus;
}
而这个字段是在什么时候用到呢,LoadMoreView 的代码很少,可以看到
public void convert(BaseViewHolder holder) {
switch (mLoadMoreStatus) {
case STATUS_LOADING:
visibleLoading(holder, true);
visibleLoadFail(holder, false);
visibleLoadEnd(holder, false);
break; case STATUS_FAIL:
visibleLoading(holder, false);
visibleLoadFail(holder, true);
visibleLoadEnd(holder, false);
break; case STATUS_END:
visibleLoading(holder, false);
visibleLoadFail(holder, false);
visibleLoadEnd(holder, true);
break; case STATUS_DEFAULT:
visibleLoading(holder, false);
visibleLoadFail(holder, false);
visibleLoadEnd(holder, false);
break; }
}
他是在一个 convert 方法中根据 mLoadMoreStatus 来改变 loadMoreView 的显示和隐藏,convert 方法大家应该很熟悉,参数 holder 其实就是我们的 loadMoreView 本身,那么 loadMoreView.convert 在哪被调用呢。
其实是在我们绑定数据时,如果判断当前 viewholder 时 loadMore 类型,就会调用。
@Override
public void onBindViewHolder(K holder, int positions) {
int viewType = holder.getItemViewType();
switch (viewType) {
case 0:
convert(holder, mData.get(holder.getLayoutPosition() - getHeaderLayoutCount()));
break; case LOADING_VIEW:
mLoadMoreView.convert(holder);
break; case HEADER_VIEW:
break;
case EMPTY_VIEW:
break;
case FOOTER_VIEW:
break;
default:
convert(holder, mData.get(holder.getLayoutPosition() - getHeaderLayoutCount()));
break; }
}
很好理解,我们的 loadMoreView 是一直存在的。作为我们 recyclerView 的最后一个 item,当加载到最后一个 item 的时候,他就调用 loadView 的 convert 方法,方法内部根据我们当前是否应该显示 loadView 来做相应的操作。这样我们就理解了 loadMore 的隐藏和显示的逻辑了。后面还有两个方法也很好理解,请看。
加载失败调用,可能你有需求在加载失败后要显示一个加载失败的 view 提示用户,而不是直接关闭 loadMoreView。此时你可以调用该方法。
loadMoreFail
/**
* Refresh failed */public void loadMoreFail() {
if (getLoadMoreViewCount() == 0) {
return;
}
mLoading = false;
mLoadMoreView.setLoadMoreStatus(LoadMoreView.STATUS_FAIL);
notifyItemChanged(getHeaderLayoutCount() + mData.size() + getFooterLayoutCount());
}
loadMoreEnd
/**
* Refresh end, no more data * * @param gone if true gone the load more view
*/public void loadMoreEnd(boolean gone) {
if (getLoadMoreViewCount() == 0) {
return;
}
mLoading = false;
mNextLoadEnable = false;
mLoadMoreView.setLoadMoreEndGone(gone);
if (gone) {
notifyItemRemoved(getHeaderLayoutCount() + mData.size() + getFooterLayoutCount());
} else {
mLoadMoreView.setLoadMoreStatus(LoadMoreView.STATUS_END);
notifyItemChanged(getHeaderLayoutCount() + mData.size() + getFooterLayoutCount());
}
}
之后就到我们关心的回调部分了。首先我们需要设置我们的回调监听器
public void setOnLoadMoreListener(RequestLoadMoreListener requestLoadMoreListener, RecyclerView recyclerView) {
openLoadMore(requestLoadMoreListener);
if (getRecyclerView() == null) {
setRecyclerView(recyclerView);
}
}
在设置监听器的时候,代码也帮我们做了一个字段的赋值操作。默认开启上拉加载,mLoading 是表示当前是否处于上拉加载中。
接下来你可能要问,那这个 morequestLoadMoreListener 在什么时候被调用呢,其实这个也设计的比较好,上一章我们分析了预加载功能,其实就在上次介绍的代码中。
private void autoLoadMore(int position) {
if (getLoadMoreViewCount() == 0) {
return;
}
if (position < getItemCount() - mAutoLoadMoreSize) {
return;
}
if (mLoadMoreView.getLoadMoreStatus() != LoadMoreView.STATUS_DEFAULT) {
return;
}
mLoadMoreView.setLoadMoreStatus(LoadMoreView.STATUS_LOADING);
if (!mLoading) {
mLoading = true;
if (getRecyclerView() != null) {
getRecyclerView().post(new Runnable() {
@Override
public void run() {
mRequestLoadMoreListener.onLoadMoreRequested();
}
});
} else {
mRequestLoadMoreListener.onLoadMoreRequested();
}
}
}
如果你想关闭预加载,当时是 mAutoLoadMoreSize =0 ,此时要调用最后一句代码,条件就变成了
position
思路大概是这样的:
在关闭预加载功能时:如果加载到最后一个 item,首先会调用 getItemViewType 询问即将加载的 viewholder 是什么类型。我们前面说过了,loadMoreView 是一直作为最后一个 viewHolder 存在的。此时如果符合显示 loadMoreView 条件,那么就设置 loadMoreView 的状态,调用我们的函数。在执行到 onBindViewHolder 生命周期方法时,会根据我们设置的值显示或者隐藏 loadMoreView 视图,也就是说,onLoadMoreRequested 方法的回调在显示 loadMoreView 之前就被调用了。时间是很短的,用户基本察觉不出来。
本次分析就到这里,接下来会继续分析其余的代码。如果有需要想一起分析哪部份代码,也可以直接留言,我会调整顺序。
欢迎来到这里!
我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。
注册 关于