背景
项目需求中需要隐藏一些特殊的ViewHolder，然后有一些需要显示。
当我隐藏之后，我发现滚动区域计算似乎出现了问题，导致RefreshLayout一直认为我的RecyclerView没有到顶部，于是一直无法触发Header的LoadMore数据

隐藏ViewHolder
方法1.网上一般都说直接在ViewHolder的onBindView中把itemView设置成GONE即可隐藏，但是真实去测试的话，会发现这样的话隐藏起来view后，还能看到一个空白区域。
（怀疑是因为复用的缘故，但未去深究，有清楚原因的可以给我留言）

方法2.使用了view是height=0dp的ViewHolder来渲染这种特殊的ViewHolder。
（我采用的是这样的方式）

正题（Bug）
因为RecyclerView需要一个LayoutManager，来做一些测量、布局之类的工作，而我发现，当比如隐藏了200个viewholder的时候，发现滚动区域range打出来，特别的大。（高达30000，而我真实的有显示的内容才2000，那也就意味着即便我滑动到顶部（2000的位置而已），Rv也不会认为我到顶部了）

RecyclerView.computeVerticalScrollRange() //可以打出当前Rv的滚动区域

那居然知道它是这样计算的，我们进到代码内看，会发现这个数值的计算方式是根据LayoutManager内部的计算来的（这边我以LinearLayoutManager为例）对应的函数是：
androidx.recyclerview.widget.LinearLayoutManager#computeScrollRange

static int computeScrollRange(RecyclerView.State state, OrientationHelper orientation,
            View startChild, View endChild, RecyclerView.LayoutManager lm,
            boolean smoothScrollbarEnabled) {
        if (lm.getChildCount() == 0 || state.getItemCount() == 0 || startChild == null
                || endChild == null) {
            return 0;
        }
        if (!smoothScrollbarEnabled) {
            return state.getItemCount();
        }
        // smooth scrollbar enabled. try to estimate better.
        final int laidOutArea = orientation.getDecoratedEnd(endChild)
                - orientation.getDecoratedStart(startChild);
        final int laidOutRange = Math.abs(lm.getPosition(startChild)
                - lm.getPosition(endChild))
                + 1;
        // estimate a size for full list.
        return (int) ((float) laidOutArea / laidOutRange * state.getItemCount());
    }

而这里几个参数我们可以看下，laidOutArea意味着显示的区域，而laidOutRange意味着显示出来的ViewHolder count数量，算出每个item的平均高度后，又*getItemCount()，来估算我们的滚动条高度。
这样问题就很明确了，无论平均高度正确与否，但是一旦和getItemCount()相乘，那么它的高度肯定是错的，因为getItemCount()中我们隐藏了很多的特殊的ViewHolder，它们的高度应该是0才对。

解决方案：
1.居然问题出在这边，我们可以复写LayoutManager内部的computeVerticalScrollRange和computeVerticalScrollOffset方法，来自己计算我们的滚动条的高度和偏移。
2.使用addItemDecoration的方式在最顶部的position==0的ViewHolder上加一个分割线，因为一旦它有了Decoration，从上面的代码中可以看到它就会被纳入到laidOutRange的计算，从而得到一个count=隐藏的viewcount + 显示的viewcount，
这样对应出来的平均数就会比较小，然后再去和getItemCount()相乘，得到一个较为准确的值。当然它也有弊端，如果你用这种方式，你的滚动条会忽大忽小
3.当然，最正确的方式是从数据源上下手，就是getItemCount应该返回真实可显示的数据的大小，而不应该用这种workaround的方式来做UI显示。（不过类似于我们项目的特殊性，可能有一些并无法通过这种方式的，就要考虑前面两种方式了）