版本：2.8.5
更多內容請看：http://cherylgood.cn
今天，我們來一起分析BaseRecyclerViewAdapterHelper中有關BaseQuickAdapter的源碼，今天的分析思路是根據BaseQuickAdapter的實例化過程來進行分析。分析前我先分享一個RecyclerView.Adapter的生命周期方法圖：
BaseQuickAdapter實例化第一步當然是調用我們的構造方法：
public BaseQuickAdapter(int layoutResId, List data) {
Log.d(TAG,"#test BaseQuickAdapter");
this.mData = data == null ? new ArrayList() : data;
if (layoutResId != 0) {
this.mLayoutResId = layoutResId;
}
}
public BaseQuickAdapter(List data) {
this(0, data);
}
public BaseQuickAdapter(int layoutResId) {
this(layoutResId, null);
}
從源碼可以看到，我們的BaseQuickAdapter 有三個構造函數，但最終都會調用
public BaseQuickAdapter(int layoutResId, List data) {
Log.d(TAG,"#test BaseQuickAdapter");
this.mData = data == null ? new ArrayList() : data;
if (layoutResId != 0) {
this.mLayoutResId = layoutResId;
}
}
可以看到，加入你不傳入data，內部會先為我們創建一個空的list，
然后在構造時記錄我們的布局資源id。
那么，布局資源id會在什么時候用呢，當然是在onCreateViewHolder 方法中創建viewholder的時候，那么我沒繼續看onCreateViewHolder 方法的代碼。而調用onCreteViewHolder前會先調用getItemViewType方法。
@Override
public int getItemViewType(int position) {
Log.d(TAG,"#test getItemViewType");
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) {
Log.d(TAG,"#test onCreateViewHolder");
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);
}
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
可以先看到下哦啊，getItemView是返回一個什么view
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的子類時，基本調用的是
new BaseViewHolder(view);
在我們上一篇分析BaseViewHolder中有一個
convertView字段的值及來自這里。
那么好，當viewholder被創建后，接下來就是數據綁定了，我們看一下源代碼：
public void onBindViewHolder(K holder, int positions) {
Log.d(TAG,"#test onBindViewHolder");
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是我們正常要顯示的數據呢，
@Override
public K onCreateViewHolder(ViewGroup parent, int viewType) {
....
switch (viewType) {
...
default:
baseViewHolder = onCreateDefViewHolder(parent, viewType);
}
return baseViewHolder;
從onCreateViewHolder中可以看到在default情況下就是viewType=0，該值來自adapter的
getItemViewType方法，
@Override
public int getItemViewType(int position) {
Log.d(TAG,"#test getItemViewType");
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;
}
}
}
}
當既不是頭部視圖，也不是尾部視圖，空視圖時，他就會調用
getDefItemViewType(adjPosition);
protected int getDefItemViewType(int position) {
return super.getItemViewType(position);
}
里面調用adapter的父類的方法，進入該方法
/**
* Return the view type of the item at position for the purposes
* of view recycling.
*
*
The default implementation of this method returns 0, making the assumption of * a single view type for the adapter. Unlike ListView adapters, types need not * be contiguous. Consider using id resources to uniquely identify item view types. * * @param position position to query * @return integer value identifying the type of the view needed to represent the item at * position. Type codes need not be contiguous. */ public int getItemViewType(int position) { return 0; }
可以看到，他返回的就是0，所以viewType等于0就是正常加載數據的viewHolder，然后我們將holder和經過計算
mData.get(holder.getLayoutPosition() - getHeaderLayoutCount())
后得到的該positions下的data傳入convert函數，我們就可以拿著holder和data進行數據的綁定操作了，
@Override
public void onBindViewHolder(K holder, int positions) {
Log.d(TAG,"#test onBindViewHolder");
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;
}
}
從創建adapter到根據不同的情況創建不同的viewholder到綁定數據的流程，希望對大家有幫助，后面會繼續分享有關BaseRecyclerViewAdapterHelper的源碼的內容。
