MergeAdapter
前幾天更新的 recyclerview-1.2.0-alpha02 中增加了一個(gè)新的類 MergeAdapter殿怜，這個(gè)類可以按照順序把幾個(gè) adapter 合成一個(gè)新的 adapter箱锐。
一個(gè)常見的場景就是 RecycleView 加載更多的實(shí)現(xiàn)秦叛。
相信很多小伙伴都實(shí)現(xiàn)過類似的效果抒倚，我們通常會(huì)定義多個(gè) ViewType, 在 getItemCount 中返回 item 數(shù)據(jù)的 size 再加上 2 (header 和 footer)览露。我們的 adapter 不僅要處理數(shù)據(jù)相關(guān)的邏輯醋寝，還要處理 header 和 footer 的邏輯口糕，這樣會(huì)導(dǎo)致 adapter 的邏輯變得復(fù)雜缅阳。
有了 MergeAdapter 之后我們可以把原來的 adapter 分成 HeaderAdapter ItemAdapter 和 FooterAdapter, 使用 MergeAdapter 合成一個(gè)之后再給 RecyclerView，這樣每個(gè) Adapter 的分工就比較明確景描，代碼邏輯更加清晰十办。
我們看一下具體的實(shí)現(xiàn)。
headerAdapter = HeaderAdapter(this)
itemAdapter = ItemAdapter(this)
footerAdapter = FooterAdapter(this)
mergeAdapter = MergeAdapter(headerAdapter, itemAdapter, footerAdapter)
val layoutManager = LinearLayoutManager(this)
binding.recyclerView.layoutManager = layoutManager
binding.recyclerView.adapter = mergeAdapter
我們可以看到使用上跟以前沒有太大差別伏伯，無非就是把原來的 adapter 換成 mergeAdapter, mergeAdapter 由多個(gè) adapter 按順序合成橘洞。
更新數(shù)據(jù)的時(shí)候我們只需要更新相應(yīng)的 adapter,比如加載數(shù)據(jù)之后我們需要更新 ItemAdapter, 如果沒有數(shù)據(jù)了我們更新 FooterAdapter。
我們在 viewModel 中更新數(shù)據(jù)说搅，在 activity 中觀察相應(yīng)數(shù)據(jù)變化通知對(duì)應(yīng)的 adapter炸枣。
MainActivity.kt
viewModel.data.observe(this, Observer {
itemAdapter.addItem(it)
})
viewModel.hasMoreState.observe(this, Observer {
footerAdapter.updateFooterState(it)
})
MainViewModel.kt
fun loadMore() {
viewModelScope.launch {
var newData = listOf<Int>()
var newHasMoreState = FooterAdapter.STATE_LOADING
// 模擬網(wǎng)絡(luò)延遲
withContext(Dispatchers.Default) {
delay(2000)
newData = arrayListOf(0, 1, 2, 3, 4, 5, 6, 7, 8, 9)
if (page >= 1) {
newHasMoreState = FooterAdapter.STATE_COMPLETE
}
}
hasMoreState.value = newHasMoreState
data.value = newData
page++
}
}
這樣整個(gè)數(shù)據(jù)的更新邏輯就比較清晰，每個(gè) adapter 的職責(zé)相對(duì)明確弄唧，不同 adapter 之間互不影響适肠，假如某次改版之后我們不需要header了，只需要去掉 HeaderAdapter 即可候引，對(duì) ItemAdapter 和 FooterAdapter 完全沒有影響侯养。
原理
那么問題來了，為什么我們更新了 ItemAdapter 列表就會(huì)更新呢澄干？
我們知道 recyclerView 真正的 adapter 是 mergeAdapter逛揩，只有 mergeAdapter 的更新才會(huì)讓 recycleView 更新，MergeAdapter 是如何實(shí)現(xiàn)這些功能的呢麸俘？我們來看一下 MergeAdapter 的實(shí)現(xiàn)辩稽。
public final class MergeAdapter extends Adapter<ViewHolder> {
static final String TAG = "MergeAdapter";
/**
* Bulk of the logic is in the controller to keep this class isolated to the public API.
*/
private final MergeAdapterController mController;
// other code
}
我們看到 MergeAdapter 跟別的 Adapter 沒什么不同，也是繼承者 Adapter从媚，但是里面有 MergerAdapterController逞泄，所有的魔法都在 mController 里面。
我們以 getItemCount 為例看一下 mController 有什么作用拜效。
@Override
public int getItemCount() {
return mController.getTotalCount();
}
mergeAdapter 的 getItemCount 實(shí)際上調(diào)用的是 mController的 getTotalCount喷众，我們再進(jìn)到 getTotalCount 方法里面看看
public int getTotalCount() {
// should we cache this as well ?
int total = 0;
for (NestedAdapterWrapper wrapper : mWrappers) {
total += wrapper.getCachedItemCount();
}
return total;
}
getTotalCount 方法遍歷 wrapper 把 cachedItemCount 加起來。每個(gè) wrapper 持有 adapter紧憾，cachedItemCount 就是 adapter.getItemCount()到千，所以實(shí)際上 getTotalCount 方法就是把所有的 adapter 的 itemCount 加起來。
那么回到上一個(gè)問題稻励，為什么 ItemAdapter 的更新會(huì)導(dǎo)致 MergeAdapter 的更新父阻。
NestedAdapterWrapper(
Adapter<ViewHolder> adapter,
final Callback callback,
ViewTypeStorage viewTypeStorage,
StableIdStorage.StableIdLookup stableIdLookup) {
this.adapter = adapter;
mCallback = callback;
mViewTypeLookup = viewTypeStorage.createViewTypeWrapper(this);
mStableIdLookup = stableIdLookup;
mCachedItemCount = this.adapter.getItemCount();
this.adapter.registerAdapterDataObserver(mAdapterObserver);
}
我們看到 NestedAdapterWrapper 的構(gòu)造方法中會(huì)為 adapter 注冊 observer
private RecyclerView.AdapterDataObserver mAdapterObserver =
new RecyclerView.AdapterDataObserver() {
@Override
public void onChanged() {
mCachedItemCount = adapter.getItemCount();
mCallback.onChanged(NestedAdapterWrapper.this);
}
@Override
public void onItemRangeChanged(int positionStart, int itemCount) {
mCallback.onItemRangeChanged(
NestedAdapterWrapper.this,
positionStart,
itemCount,
null
);
}
// 刪掉類似的代碼
};
我們看到 observer 的相關(guān)方法中會(huì)調(diào)用 mCallback 的方法愈涩，mCallback 就是我們在構(gòu)造方法中傳的 callback 參數(shù)望抽。
我們再看一下 MergeAdapterController 中怎么創(chuàng)建 NestedAdapterWrapper加矛。
NestedAdapterWrapper wrapper = new NestedAdapterWrapper(adapter, this,
mViewTypeStorage, mStableIdStorage.createStableIdLookup());
MergeAdapter 實(shí)現(xiàn)方法
@Override
public void onItemRangeChanged(@NonNullNestedAdapterWrapper nestedAdapterWrapper,
int positionStart, int itemCount, @Nullable Object payload) {
final int offset = countItemsBefore(nestedAdapterWrapper);
mMergeAdapter.notifyItemRangeChanged(
positionStart + offset,
itemCount,
payload
);
}
所以我們可以看到最后會(huì)調(diào)用 mergeAdapter 的相應(yīng)方法實(shí)現(xiàn)更新。
總結(jié)
MergeAdapter 實(shí)際上也是個(gè)普通的 Adapter煤篙，主要起作用的是 MergeAdapterController斟览。 MergeAdapterController 幫我們實(shí)現(xiàn)了不同 adapter 組合之后帶來的繁瑣的計(jì)算，讓我們更專注于代碼邏輯辑奈。
參考
Merge adapters sequentially with MergeAdapter
