重学RecyclerView-Adapter封装的深度思考和实现

背景

一转眼，从一开始公布文章说带大家
封装Adapter
直到现在，过来半个月了吧，前后又仔细阅读了很多Adapter的框架源码，对Adapter的变幻无穷算是有了粗浅的意识，真的是温故而知新，借着这次机会，我也将学到的这些长处一一的列出来通知你，跟我一起重新认识Adapter

值得一看的Adapter开源我的项目

• mikepenz/FastAdapter
• DevAhamed/MultiViewAdapter
• davideas/FlexibleAdapter
• sockeqwe/AdapterDelegates
• liangjingkanji/BRV
• evant/binding-collection-adapter
• nitrico/LastAdapter
• 作者Adapter

这些开源我的项目都有哪些相同点？

• 这几个我的项目最大的共同点是都对DataBinding做了扩大，看来DataBinding大家都很认可
• 有6个我的项目都用到了Kotlin，最高达到了96%，看来咱们android小伙伴都爱学习，kotlin的普及率好高
• 还有一个点都对MultiItemType做了良好的扩大，阐明这的确是一个Adapter库的标配
• 有三个我的项目对Paging库做了扩大，置信大家用它的机会越来越多
• 头尾布局简直成了框架的标配
• Kotlin DSL或多或少的反对，写法上简洁而柔美
• 大多数都做了比拟好的分库解决，按需依赖，不快人快语

咱们如何做一个能够称之为全而好的Adapter框架呢？

我抽取几个关键词来通知你

• 适当分包，按需依赖，提供良好的扩展性
• kotlin反对 利用最近一个老铁的话：工欲善其事必先利其器，kotlin绝壁是一个好利器
• DSL扩大 简洁的写法，利于浏览
• DataBinding反对 不必质疑，有就对了
• Paging扩大 在我看来Paging用了很多新的设计，值得咱们去学习
• 头尾布局、空布局、上拉加载，拖动，动画 提供专门的包来扩大
• DiffUtil扩大 好的工具不要遗记应用，总会有适合的利用场景
• anko扩大 用了kotlin怎么能不必一下anko layout，300%的布局加载效率进步不香吗？

设计这么一个框架我的保持是什么？

你有没有陷入过一个误区？本人封装了一个货色，特地的全，什么都反对，一股脑的往里面塞货色，这个人说我想这样，你就改成这样，那个人想那样，你又开始改？难道咱们做个货色就是为了让他人指挥吗？答案必定是：不。那应该从哪几个方面思考呢？

• 扩展性 对的，你肯定要做到可扩大，要不然你就要面临东改改，西改改的窘境，如何做到可扩大呢？一条准则搞定：依赖倒转准则，尽量依赖于形象，而不是依赖于实现，做到这一点其实还不够
• 可靠性 能够了解为，你做的货色不要常常变，特地是形象的接口，在一开始咱们就要做到残缺，有的人说，我怎么肯能思考那么完满呢？那就要考虑一下，你是不是走到了一个误区，接口的形象在这样一个成熟的框架中，应该很好确定的，接口不要大而全，接口也要做到尽量的小，起码接口能够多继承啊，对吧。
• 里氏替换准则: 任何基类能够呈现的中央，子类肯定能够呈现，这个准则其实好多人都不太了解，其实说白一点，用事实的例子通知你，你继承了父亲的很多基因，那你能扭转父亲的基因吗？必定不能，可代码里是能够重写的（形象办法不算哦），但这个准则就是通知咱们防止重写，一旦重写，父类就没有了意义，其实在工作中，有很多人喜爱往父类里形象很多货色，还特地喜爱在不同的子类中笼罩后重写，这些都是不好的习惯，你不应该只是老三用到了一个货色，就要给所有的人加上这个货色，我感觉是个累赘，你感觉呢？咱们在设计框架的时候，肯定要遵循这些好的设计准则。
• 繁多职责 一个类应该有且仅有一个职责，你还好意思封装一个类，啥性能都有吗？除非它叫Manager，但也只能治理一类货色，职责的繁多处处可见，且要处处保持。

讲了这些废话，你是不是不耐烦了，上面来点干货吧，看看Adapter的一些细节是如何封装的

Adapter 如何做到ItemViewType主动适配？咱们是如何封装的？

看源码前，我想说的是，你要明确一个原理，其实ItemViewType它影响的就是ViewHolder的复用逻辑，只有是一样的ItemViewType，它就会触发复用，所以说ItemViewType封装的目标，其实是缓存ViewHolder而后复用，那咱们如何做到主动解决加缓存呢？

因为咱们要做到onCreateViewHolder的下移，而咱们形象了ViewModel层来负责组织View和Model，那么ViewHolder就成了咱们View的载体，形象一个ViewHolderFactory让ViewModel继承，达到onCreateViewHolder的调用下移

typealias GenericViewHolderFactory = ViewHolderFactory<out RecyclerView.ViewHolder>

interface ViewHolderFactory<VH : RecyclerView.ViewHolder> {
    fun getViewHolder(parent: ViewGroup, layoutInflater: LayoutInflater): VH
}

再看两处代码，这是咱们实现的两个函数，onCreateViewHolder回调的时候只给了viewType，那么咱们就只能想方法，用Map缓存一个起来下面的ViewHolderFactory，这样就能够依据viewType拿到对应的ViewHolderFactory，是不是就完满了？

override fun onCreateViewHolder(parent: ViewGroup, viewType: Int)

override fun getItemViewType(position: Int)

缓存ViewHolderFactory代码如下,第一步我先形象一个ViewHolderFactoryCache接口，保障当前的扩展性，并默认实现一个DefaultViewHolderFactoryCache，提供注册、获取、查看、清理的办法

interface ViewHolderFactoryCache<VHF : GenericViewHolderFactory> {
    fun register(type: Int, item: VHF): Boolean
    operator fun get(type: Int): VHF
    fun contains(type: Int): Boolean
    fun clear()
}

class DefaultViewHolderFactoryCache<VHF : GenericViewHolderFactory> : ViewHolderFactoryCache<VHF> {
    private val typeInstances = SparseArray<VHF>()
    override fun register(type: Int, item: VHF): Boolean {
        if (typeInstances.indexOfKey(type) < 0) {
            typeInstances.put(type, item)
            return true
        }
        return false
    }

    override fun get(type: Int): VHF {
        return typeInstances.get(type)
    }

    override fun contains(type: Int) = typeInstances.indexOfKey(type) >= 0
    override fun clear() {
        typeInstances.clear()
    }
}

而后再去Adapter里实现, 我抉择让ViewModel实现ViewHolderFactory，缓存起来后，在onCreateViewHolder中再取出来而后赋值。

    private val defaultViewHolderFactoryCache = DefaultViewHolderFactoryCache<ViewHolderFactory<VH>>()

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): VH {
        val defaultViewHolder = defaultViewHolderFactoryCache[viewType].getViewHolder(parent, sparseArray.get(0) ?: LayoutInflater.from(parent.context))
        defaultViewHolder.itemView.setTag(R.id.list_adapter, this)
        return defaultViewHolder
    }
    
    override fun getItemViewType(position: Int): Int {
        val item = getItem(position) ?: return 0
        val type = item.itemViewType
        if (!defaultViewHolderFactoryCache.contains(type)) {
            item as ViewHolderFactory<VH>
            defaultViewHolderFactoryCache.register(type, item)
        }
        return type
    }
    
    override fun onDetachedFromRecyclerView(recyclerView: RecyclerView) {
        defaultViewHolderFactoryCache.clear()
        sparseArray.clear()
    }

在onDetachedFromRecyclerView后清理掉缓存数据。有个细节这里没看到，来看下

interface ViewModel<M, VH : RecyclerView.ViewHolder, Adapter:IAdapter<*>> :
    ViewHolderFactory<VH> {
    var model: M?
    var adapter: Adapter?
    val itemViewType: Int
        get() = layoutRes

    @get:LayoutRes
    val layoutRes: Int
    fun bindVH(
        viewHolder: VH,
        model: M,
        payloads: List<Any>
    )

    fun unBindVH(viewHolder: VH)
}

这是ViewModel，它其实也是个接口，但在Kotlin里接口是能够有实现的（kotlin的劣势就在这），所以我让itemViewType默认就是layoutRes，我人为这种形象的实现，齐全正当，不同的layout布局就是不同的ViewHolder，而既然都是一样的layout，ViewHolder也齐全能够一样对吗？对的。

如何做一个通用的ViewModel，如何实现DSL呢？

通用的ViewHolder就不用说了，在之前的博客里曾经剖析了，想看的请转一个资深的Android是不是应该学会本人做一个超级的RecyclerView.Adapter,这外面的是初期封装实现的，底层我做了优化，暂且只看ViewHolder，那ViewModel应该如何做呢？咱们来看下下面的ViewModel接口，剖析一下它的职责，如下

• 继承ViewHolderFactory，负责getViewHolder
• bindVH 负责绑定数据
• unBindVH 解绑时触发
• layoutRes 负责布局的援用
• itemViewType 默认就是布局的利用id
• 持有Model数据，能够是任何类型
• 持有adapter 须要继承自IAdapter

其实对于使用者来说，最须要做的就是，将业务的Model绑定到ViewModel上，并承受bindVH回调来实现绑定，配置一个layoutRes就完事儿了，上面间接看下继承的实现

typealias  DefaultViewModelType <M, Adapter> = ViewModel<M, DefaultViewHolder, Adapter>

abstract class DefaultItemViewModel<M, A : IAdapter<*>> : DefaultViewModelType<M, A> {

    override var adapter: A? = null
    override var model: M? = null
    private var bindView: BindView? = null
    private var bindViewPayload: BindViewPayload? = null
    private var itemClick: ItemClick<M>? = null

    open fun onBindViewHolder(f: (DefaultViewHolder) -> Unit) {
        bindView = f
    }

    open fun onBindViewHolder(f: (DefaultViewHolder, Any) -> Unit) {
        bindViewPayload = f
    }

    open fun onItemClick(f: (viewModel: ArrayItemViewModel<M>, viewHolder: DefaultViewHolder) -> Unit) {
        itemClick = f
    }

    override fun getViewHolder(
        parent: ViewGroup,
        layoutInflater: LayoutInflater
    ): DefaultViewHolder {
        return DefaultViewHolder(layoutInflater.inflate(layoutRes, parent, false)).apply {
            itemView.setOnClickListener {
                itemClick?.invoke(
                    adapter?.getItem(adapterPosition) as @ParameterName(name = "viewModel") ArrayItemViewModel<M>,
                    this
                )
            }
        }
    }

    override fun bindVH(viewHolder: DefaultViewHolder, model: M, payloads: List<Any>) {
        if (payloads.isNotEmpty()) {
            this.model =  payloads[0] as M
            bindViewPayload?.invoke(viewHolder, payloads[0])
        }else{
            bindView?.invoke(viewHolder)
        }
    }

    override fun unBindVH(viewHolder: DefaultViewHolder) {}
}

typealias  ArrayViewModelType <M> = DefaultItemViewModel<M, ArrayListAdapter>

open class ArrayItemViewModel<M>(override val layoutRes: Int) : ArrayViewModelType<M>()

实现绑定有两个局部，一个是有payloads状况，咱们回调函数bindViewPayload，否则回调bindView函数，这样能够实现ItemView的部分刷新，业务层调用onBindViewHolder传入一个高级函数，这个高级函数最终赋值给bindView，而后接管回调就能够，这里用了通用的DefaultViewHolder，初始化后间接setOnClickListener，为什么这么做：就是为了避免业务端呈现屡次的setOnClickListener，一次设置一生收益，这里DefaultItemViewModel<M, A : IAdapter<*>>特意给Adapter留了扩大的入口，因为咱们的Adapter会有好几个，但都能够复用这块的逻辑，ArrayItemViewModel就是针对ArrayListAdapter的一个扩大，上面做一个DSL反对，请看代码

fun <M> arrayItemViewModelDsl(
    layoutRes: Int,
    init: ArrayItemViewModel<M>.() -> Unit
): ArrayItemViewModel<M> {
    return ArrayItemViewModel<M>(layoutRes).apply {
        init()
    }
}

fun arrayListAdapter(block: ArrayListAdapter.() -> Unit): ArrayListAdapter {
    return ArrayListAdapter().apply {
        block()
    }
}

fun ListAdapter<*, *>.into(
    recyclerView: RecyclerView,
    layoutManager: RecyclerView.LayoutManager? = null
) = apply {
    recyclerView.layoutManager = layoutManager ?: LinearLayoutManager(recyclerView.context)
    recyclerView.adapter = this
}

第一步扩大ArrayItemViewModel，第二步扩大ArrayListAdapter，第三扩大Adapter抽象类，绑定到RecyclerView，来看下应用的成果

    arrayListAdapter {
            //循环增加ItemViewModel
            (0..10).map {
                add(
                    // ItemViewModel 对象 函数中传入布局IdRes
                    arrayItemViewModelDsl<ModelTest>(if (it % 2 == 0) R.layout.item_test else R.layout.item_test_2) {
                        // Model 数据模型
                        model = ModelTest("title$it", "subTitle$it")
                        // 绑定数据
                        onBindViewHolder { viewHolder ->
                            viewHolder.getView<TextView>(R.id.tv_title)?.text = model?.title
                            viewHolder.getView<TextView>(R.id.tv_subTitle)?.text = model?.subTitle
                        }
                        // 点击解决
                        onItemClick { vm, vh ->
                            //这里须要留神，为什么间接从该对象获取的Model是不正确的？因为ViewHolder的复用
                            //导致click事件其实是在另外一个VM里触发的
                            Log.d("arrayItemViewModel", "不正确的model${model}")
                            Log.d("arrayItemViewModel", "正确的model${vm.model}")
                            Log.d("arrayItemViewModel", "adapter$adapter")
                            Log.d("arrayItemViewModel", "viewHolder${vh.adapterPosition}")
                            //批改Model数据
                            vm.model?.title = "测试更新"
                            //用Adapter更新数据
                            adapter?.set(vh.adapterPosition, vm)
                        }
                    }
                )
            }
            // 绑定 RecyclerView
            into(rv_list_dsl)
        }

看完例子，有没有感觉还行？我倒是感觉还Ok吧。

如何扩大成Anko Layout呢？

咱们都晓得Anko layout能够晋升UI的加载效率，缩小cpu的应用，这里援用一个大佬的总结，来看下

从xml 到 运行 再到 读取xml文件 最终到生成UI元素，最次要的就是经验了文件流的读取

而DSL间接编辑代码测量布局而后绘制，省了这么多的步骤，能不快吗？到底快多少呢？来看另一张图，一个大佬的测试

最低的手机型号都快了近359%，这是什么操作？流不流逼？咱们先不说DSL的写法极大的高了加载效率，它还有其余劣势，DSL写起来也比XML简洁易懂，来看个例子

class AnkoLayoutComponent(private val ankoListAdapter: ArrayListAdapter) : AnkoComponent<AnkoLayoutActivity> {

    override fun createView(ui: AnkoContext<AnkoLayoutActivity>) = with(ui) {

        verticalLayout {

            recyclerView {
                bindListAdapter(ankoListAdapter)
            }.lparams(matchParent) {
                weight = 1F
            }
            // Anko 兼容 xml布局的加载
            include<View>(R.layout.include_button_bottom)

        }

    }

}

这个例子，我想通知你的是，anko layout 不光是它的独有的写法，还齐全兼容XML，这也给那些想缓缓过渡的敌人，一个好的形式。那么主题来了，如何扩大Adapter 也用上这个呢？其实关键点就是View，来看下AnkoComponent接口

interface AnkoComponent<in T> {
    fun createView(ui: AnkoContext<T>): View
}

再看下ViewHolder构造函数，这不是正好吗？AnkoComponent生成的View，间接给ViewHolder不就能够间接跳过XML吗？

  public ViewHolder(@NonNull View itemView) {
            if (itemView == null) {
                throw new IllegalArgumentException("itemView may not be null");
            }
            this.itemView = itemView;
        }

实现代码如下，间接继承ArrayItemViewModel，而后实现getViewHolder函数，最终通过AnkoComponent的实例对象createView，就是这么简略。

public abstract class AnkoItemViewModel<M, AnkoView extends AnkoComponent<ViewGroup>>
        extends ArrayItemViewModel<M> {

    public AnkoItemViewModel() {
        super(0);
    }

    public abstract AnkoView onCreateView();

    @NotNull
    @Override
    public DefaultViewHolder getViewHolder(@NotNull ViewGroup parent, @NotNull LayoutInflater layoutInflater) {
        AnkoView ankoView = onCreateView();
        View view = ankoView.createView(AnkoContext.Companion.create(parent.getContext(), parent, false));
        view.setTag(R.id.list_adapter_anko_view, ankoView);
        return new DefaultViewHolder(view);
    }

    @Override
    public int getItemViewType() {
        return this.hashCode();
    }

    public AnkoView getAnkoView(RecyclerView.ViewHolder viewHolder) {
        return (AnkoView) viewHolder.itemView.getTag(R.id.list_adapter_anko_view);
    }

}

用法示例

class AnkoViewModelTest : AnkoItemViewModel<ModelTest, AnkoItemView>() {
    init {
        onBindViewHolder { viewHolder ->
            getAnkoView(viewHolder).tvTitle?.text = model?.title
            getAnkoView(viewHolder).tvSubTitle?.text = model?.subTitle
            getAnkoView(viewHolder).itemClick = {
                Log.d("AnkoViewModelTest", "正确的model${model}")
                Log.d("AnkoViewModelTest", "正确的model${model}")

                Log.d("AnkoViewModelTest", "adapter$adapter")
                Log.d("AnkoViewModelTest", "viewHolder${viewHolder.adapterPosition}")
                model?.title = "点击更新"
                adapter?.set(viewHolder.adapterPosition, this)
            }
        }
    }
    override fun onCreateView(): AnkoItemView {
        return AnkoItemView()
    }
}

class AnkoItemView : AnkoComponent<ViewGroup> {
    ...
}

继承AnkoItemViewModel，配置一下Model和AnkoView就行了，就是这么的简略，而后在Adapter里这么应用,增加一个对应的实例就行了

  listAdapter.add(AnkoViewModelTest().apply {
                    model = ModelTest("题目${++index}", "副标题")
                })

扩大了这么多，总体上是如何设计的？

interface IAdapter<VM> {
    fun getItem(position: Int): VM?
}

最上层IAdapter接口，只有一个函数通过positon 获取ViewModel，中间层 ListAdapter

abstract class ListAdapter<VM : ViewModel<*,*,*>, VH : RecyclerView.ViewHolder> : RecyclerView.Adapter<VH>(), IAdapter<VM> {

    private val defaultViewHolderFactoryCache = DefaultViewHolderFactoryCache<ViewHolderFactory<VH>>()
    private val sparseArray = SparseArray<LayoutInflater>(1)

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): VH {
        val defaultViewHolder = defaultViewHolderFactoryCache[viewType].getViewHolder(parent, sparseArray.get(0) ?: LayoutInflater.from(parent.context))
        defaultViewHolder.itemView.setTag(R.id.list_adapter, this)
        return defaultViewHolder
    }

    override fun onBindViewHolder(holder: VH, position: Int) {
        onBindViewHolder(holder, position, Collections.emptyList())
    }

    override fun onBindViewHolder(holder: VH, position: Int, payloads: MutableList<Any>) {
        if(position != RecyclerView.NO_POSITION){
            // Do your binding here
            holder.itemView.setTag(R.id.list_adapter, this)
            val item = getItem(position) as? ViewModel<Any, RecyclerView.ViewHolder, IAdapter<*>>
            item?.let {
                item.adapter = this
                item.model?.let { it1 -> item.bindVH(holder, it1, payloads) }
                holder.itemView.setTag(R.id.list_adapter_item, item)
            }
        }
    }
    override fun getItemViewType(position: Int): Int {
        val item = getItem(position) ?: return 0
        val type = item.itemViewType
        if (!defaultViewHolderFactoryCache.contains(type)) {
            item as ViewHolderFactory<VH>
            defaultViewHolderFactoryCache.register(type, item)
        }
        return type
    }

    override fun onViewRecycled(holder: VH) {
        (holder.itemView.getTag(R.id.list_adapter_item) as ViewModel<*, VH, *>).apply {
            unBindVH(holder)
        }
        holder.itemView.setTag(R.id.list_adapter_item, null)
        holder.itemView.setTag(R.id.list_adapter, null)
    }

    override fun onAttachedToRecyclerView(recyclerView: RecyclerView) {
        val context = recyclerView.context
        sparseArray.append(0, LayoutInflater.from(context))
    }

    override fun onDetachedFromRecyclerView(recyclerView: RecyclerView) {
        defaultViewHolderFactoryCache.clear()
        sparseArray.clear()
    }
}

为什么这么设计，我说几个理由

• 第一 在getItemViewType的时候，参数就是position，这样我就能够通过postion拿到ViewModel，通过ViewModel就能够实现ViewHolderFactory，而后通过DefaultViewHolderFactoryCache缓存ViewHolder就行了。
• 第二 ListAdapter只干了很简略的事件，缓存ViewHolder，并在onBindViewHolder的时候，触发ViewModel的bindVH。职责上尽量简略，才好复用。
• 第三 集成它当前只须要扩大对应的数据结构，如ArrayListAdapter的ObservableArrayList，SortedListAdapter的SortedList，还有PagingListAdapter的AsyncPagingDataDiffer，这样面临不同的数据接口，一直扩大就行。

这样设计好吗？是否能够将不同的数据结构形象成一种呢？不都是列表吗？还能咋地？答案是能够的，但我为什么没有这么做呢？第一个理由，分包解决，按需依赖，放弃架构的足够清晰简洁，易懂易保护，还有个理由这三个数据结构说白了都是对数据列表做了不同水平的封装，ObservableArrayList次要就是扩大了ArrayList实现数据更新回调，而后触发Adapter更新，SortedList就是个工具类，没有扩大List，它始终放弃着一个有序的列表，而且用到了二分查找算法来实现疾速的定位更新，AsyncPagingDataDiffer就更多了，线程、分页、状态、比拟等，更简单的性能封装。三个Adapter的代码就不贴了，能够去看源码哦？

通过封装PagingListAdapter，发现了新大陆，想晓得吗？

接下来就揭晓，为什么我不焦急封装空布局、头尾布局、上啦加载等罕用业务组件？

• 第一 看了Paging 3 版本的PagingDataAdapter后，我发现一个更好的头尾布局实现计划
• 第二 这些组件的封装，其实无形中加大了框架的复杂度，而更重要的起因是，不同的App，这些都是须要本人实现的，那么如何提供这样一个扩大入口才是最次要的，而不是实现这些性能

基于这些，我更想提供一些例子来让你更加容易实现想要的，而不是依照我的接口标准来，如果我的接口标准不好不残缺，你还不得不换其余的框架，这岂不是让你很难堪，你们有没有遇到一个我的项目援用好几个Adapter框架？必定有吧。

上面咱们看下Paging如何做到了优雅的封装呢？

 fun withLoadStateHeader(
        header: LoadStateAdapter<*>
    ): ConcatAdapter {
        addLoadStateListener { loadStates ->
            header.loadState = loadStates.prepend
        }
        return ConcatAdapter(header, this)
    }

    fun withLoadStateFooter(
        footer: LoadStateAdapter<*>
    ): ConcatAdapter {
        addLoadStateListener { loadStates ->
            footer.loadState = loadStates.append
        }
        return ConcatAdapter(this, footer)
    }

    fun withLoadStateHeaderAndFooter(
        header: LoadStateAdapter<*>,
        footer: LoadStateAdapter<*>
    ): ConcatAdapter {
        addLoadStateListener { loadStates ->
            header.loadState = loadStates.prepend
            footer.loadState = loadStates.append
        }
        return ConcatAdapter(header, this, footer)
    }

这是PagingDataAdapter 提供的三个类函数，发现了什么？ConcatAdapter，对的就这个货色。再往里看下

public final class ConcatAdapter extends Adapter<ViewHolder> 

就是对RecyclerView.Adapter 的一个扩大，官网解释ConcatAdapter容许咱们按程序显示多个适配器的内容，也就是将原先绑定一个Adapter，当初变成了能够按程序绑定多个，这样组合实现，是不是很新鲜，我之前接触过一个WrapperAdapter，也是相似的设计，但我那个是这样

这种计划也是大多数热门Adapter框架解耦的办法，利用WrapperAdapter能够实现头尾布局，空布局等等吧。可当我接触到ConcatAdapter后发现还有这种设计

这种形式更适宜做头尾布局的扩大，齐全的解耦，也不须要WrapperAdapter来实现办法的回调。最开心的是ConcatAdapter在RecyclerView库的1.2.0版本就有了，当前咱们能够基于这个做很多事件，包含上啦加载，下拉加载等，Paging的头尾状态如何管制的呢？

abstract class LoadStateAdapter<VH : RecyclerView.ViewHolder> : RecyclerView.Adapter<VH>() {
  
    var loadState: LoadState = LoadState.NotLoading(endOfPaginationReached = false)
        set(loadState) {
            if (field != loadState) {
                val oldItem = displayLoadStateAsItem(field)
                val newItem = displayLoadStateAsItem(loadState)

                if (oldItem && !newItem) {
                    notifyItemRemoved(0)
                } else if (newItem && !oldItem) {
                    notifyItemInserted(0)
                } else if (oldItem && newItem) {
                    notifyItemChanged(0)
                }
                field = loadState
            }
        }

    final override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): VH {
        return onCreateViewHolder(parent, loadState)
    }

    final override fun onBindViewHolder(holder: VH, position: Int) {
        onBindViewHolder(holder, loadState)
    }

    final override fun getItemViewType(position: Int): Int = getStateViewType(loadState)

    final override fun getItemCount(): Int = if (displayLoadStateAsItem(loadState)) 1 else 0

    abstract fun onCreateViewHolder(parent: ViewGroup, loadState: LoadState): VH

    abstract fun onBindViewHolder(holder: VH, loadState: LoadState)

    open fun displayLoadStateAsItem(loadState: LoadState): Boolean {
        return loadState is LoadState.Loading || loadState is LoadState.Error
    }
}

同样实现RV的Adapter，形象一个LoadState状态，而后依据它的状态，notifyItemRemoved(0)或者notifyItemInserted(0)或者notifyItemChanged(0)，那咱们将来是不是也能够这样做呢？齐全能够，而且我倡议这样做，组合实现，跟插件一样，随用随插。不节约感情。

讲了这么多源码在哪？

https://github.com/ibaozi-cn/&#8230;

如何援用呢？

allprojects {
    repositories {
        // 首先我的项目根目录的build.gradle文件中退出这一行 
        maven { url 'https://jitpack.io' }
    }
}

//外围库
implementation com.github.ibaozi-cn.RecyclerViewAdapter:adapter-core:V1.0.0

//上面都是可选项

//anko layout 扩大
implementation com.github.ibaozi-cn.RecyclerViewAdapter:adapter-anko:V1.0.0
//diffutil 扩大
implementation com.github.ibaozi-cn.RecyclerViewAdapter:adapter-diff:V1.0.0
//data binding扩大
implementation com.github.ibaozi-cn.RecyclerViewAdapter:adapter-binding:V1.0.0
// paging3 扩大
implementation com.github.ibaozi-cn.RecyclerViewAdapter:adapter-paging:V1.0.0
// sortedlist 扩大
implementation com.github.ibaozi-cn.RecyclerViewAdapter:adapter-sorted:V1.0.0
// flexbox 扩大
implementation com.github.ibaozi-cn.RecyclerViewAdapter:adapter-flex:V1.0.0

将来还有什么打算吗？

有，必定有，第一一直的欠缺设计和实现，第二一直的凝听你们的倡议或者批评，哪里设计的不好的请您大胆的通知我，正所谓知错能改善莫大焉，我不入天堂，谁入天堂？
好了这次就到这了，拜拜

喜欢 (0)赏

[搞代码]

分享 (0)