尝试修改的过程中，发现了很多问题，例如 BaseSingleItemAdapter 这种类型的，items 是一个空数组，onBindViewHolder 中获取 item 必定为 null

在BaseQuickAdapter里声明的items我看是emptyList()，问题多应该是从开始设计的时候就把它设计成可空，而用到的地方又太多到导致的吧。
这是我提的建议，因为在使用的时候可空一点儿也不方便，写demo的时候也总是有警告，要不就加if (item == null) return，实际使用的时候，我都还从没遇到过显示出来的item有是null的时候。
能修改的话尽量修改一下呀

我在修改为非空的时候，发现先改BaseQuickAdapter类之后，再改 BaseSingleItemAdapter就容易很多

定义成非空，会丧失灵活性，还是用 BaseSingleItemAdapter 举例，对于此Adapter就是一个空数组，但是有 item 数量。这种情况下 BaseQuickAdapter 如果直接 items[position] 会造成问题。

除非 items 中的数据和 item 数量是对应的，也就是说 items 必须是有意义的。但是对于某些自定义 Adapter， items 就是无意义的，你可能有不同的内容要手动实现

这个不是修改困不困难的问题，而是考虑到更多场景的通用问题

实际使用过程中，RecyclerView的item也不会为null的吧，为null直接崩溃这也无所谓吧。

item为null的情况毕竟太少了或者说没有，为了这么点儿需求其他人都要写一堆多余代码不方便吧

设置数据之前，开发可以自己将null处理成实体类对象。自己可以实现null的UI表现，而不是靠item为null。

你还是没有理解我的意思啊，是自定义 Adapter 的时候，有的时候 items 就是没有意义的，根本不需要从里面取数据。
比如 position = 0 的时候是一个 header，header之下的才是 items。这个时候 position == 0 的就不需要从数组拿出有意义的数据

也就是说这个null的数据其实不是开发用的，是你用的 ？

暂时理解不了，能把onBindViewHolder回调的数据非空最好，我和大多数人没有可空的需求。

也就是说这个null的数据其实不是开发用的，是你用的 ？

不是我用，基类里 onBindViewHolder 获取 item 要么是可空，要么不可空。如果不可空， Adapter 的自定义就会问题，就像我上面说的，position == 0 的 header，你取出来是啥？是不是 null？

BaseSingleItemAdapter 就是一个最简单的例子。

这涉及到理解误差了吧，position == 0我希望获取到的肯定是我传的list的第一个数据，而不是那个header，我获取header干啥

这涉及到理解误差了吧，position == 0我希望获取到的肯定是我传的list的第一个数据，而不是那个header，我获取header干啥

在Base里，我只管去数据，至于数据是啥，我也不清楚，那是业务上的。在讨论的例子中，header 不在 items 里，那作为基类咋知道呢。那这段代码该怎么改？请赐教

    final override fun onBindViewHolder(holder: RecyclerView.ViewHolder, position: Int) {
        if (holder is EmptyLayoutVH) {
            holder.changeEmptyView(emptyView)
            return
        }

        onBindViewHolder(holder as VH, position, getItem(position))
    }

还有个例子，Adapter 显示空布局的时候，这里也会拿到 null

我可算大概了解你说的什么了，这是设计问题吧，添加的头布局脚布局空布局怎么还能跑到这个回调里去了，这个回调是给adapter显示数据用的啊。
对，你说用ConcatAdapter重构了，但是其实在使用上我们不关心。
头Adapter回调它的onBindViewHolder和内容Adapter回调它的onBindViewHolder都是非空的，头Adapter和内容Adapter他们可以定义一个自己的类型叫AbcEntity，它们都是非空的。
头内容和尾以及空布局，它们用一个类型，而不是和内容Adapter混一起吧。

这个代码也不需要改呀，它本身就是非空的，可空的也没回调呀。这里的getItem(posttion)又不会是null

哎～你还是没明白，算了。BaseSingleItemAdapter 就是一个例子，这就是一个自定义数据的情况，使用 Base 里的 items。你琢磨琢磨吧。
这种情况下， items 里面是空的啊，取出来肯定是 null 啊，如果在 Base 里就把 null 排除掉，那子类的 onBindViewHolder 走都不会走啊。

再一个，这个本身没啥问题，使用方写一个 if (item == null) return 并不是什么不优雅的问题。空判断本身就是一个常规操作，只是 kotlin 把空指针问题放到台面上了，强制让你注意。防御性代码本身没错。

肯定不优雅啊，谁喜欢加这种本来不需要的代码，哪有人会把rv的item搞成null的，你也先别急着拒绝，之后总有办法改。

有没有明白取决于我们想不想明白，我们只是不明白你为什么把绘制item回调搞成可空。

我们不在乎你框架的限制，限制的可空那是你框架的问题，我们只想回调的时候不可空。

如果说回库的设计。如果要做到完美，那就只能用系统的 api 了

fun onBindViewHolder(holder: ViewHolder, position: Int)

只给出 position，怎么处理数据他不管，绝对的灵活性。

此项目为了方便，提供了 list ，做了一层包装，去取出了 list 多给到了一个 item：

fun onBindViewHolder(holder: ViewHolder, position: Int, item: T?)

这种带来了某种便利，但是本身也会丧失一定灵活性。如果处理的数据不来自 list 里，那这里的封装就是多余的，提供的 item 也是无意义的，必定是 null 的

肯定不优雅啊，谁喜欢加这种本来不需要的代码，哪有人会把rv的item搞成null的，你也先别急着拒绝，之后总有办法改。

有没有明白取决于我们想不想明白，我们只是不明白你为什么把绘制item回调搞成可空。

我们不在乎你框架的限制，限制的可空那是你框架的问题，我们只想回调的时候不可空。

那你大可不必纠结，直接用系统的 fun onBindViewHolder(holder: ViewHolder, position: Int) , 想怎么取数据就怎么取

灵活性建立在方便性之上的，它本身如果不方便的话，何谈灵活性啊。
现在这种设计就不方便，现在讨论的是你库的设计吧，推荐我们用系统的我们还用库干嘛。
先冷静冷静，你可能是陷入到自己设计的误区，觉得这样实现就必须要可空，实际我们大家都觉得没必要，我在群里问过很多人，我们都没有item可空的需求。
你也统计统计，谁的item有可空的需求，大概多少，然后我们再来确认要不要可空。毕竟实现一个库一方面是兴趣，一方面是方便，一方面希望更多人认同。最后还是看作者的实现

灵活性建立在方便性之上的，它本身如果不方便的话，何谈灵活性啊。 现在这种设计就不方便，现在讨论的是你库的设计吧，推荐我们用系统的我们还用库干嘛。 先冷静冷静，你可能是陷入到自己设计的误区，觉得这样实现就必须要可空，实际我们大家都觉得没必要，我在群里问过很多人，我们都没有item可空的需求。 你也统计统计，谁的item有可空的需求，大概多少，然后我们再来确认要不要可空。毕竟实现一个库一方面是兴趣，一方面是方便，一方面希望更多人认同。最后还是看作者的实现

兄弟 群可以拉我一下吗 新手想跟大佬们学习 我v：anihczs

提供一个还算优雅的方案，单独处理需要null的情况，同时为头内容和尾以及空布局等case提供默认item为空的 SimpleSingleItemAdapter
@Reginer @limuyang2