【动画图解】这个值取对了，ViewPager2才能纵享丝滑

原创已于 2023-04-12 12:47:07 修改 · 2.4k 阅读

11 ·

CC 4.0 BY-SA版权

文章标签：

#java #android

于 2023-02-15 18:56:58 首次发布

前言

在前两篇文章中，我们通过一张张清晰明了的「示意图」，详细地复盘了RecyclerView「缓存复用机制」与「预拉取机制」的工作流程，这种「图解」创作形式也得到了来自不同平台读者们的一致认可。

而从本文开始，我们将正式进入ViewPager2的篇章，并将辅以更加生动易懂的「动态示意图」来进行讲解。

ViewPager2可讲的内容有很多，今天我们主要介绍是ViewPager2的「离屏加载机制」，你可能是第一次听说这个术语，但在实际开发中，你肯定使用过它，因为它对应的配置入口，就是ViewPager2的OffscreenPageLimit属性。

OffscreenPageLimit是什么？

OffscreenPageLimit，直译过来是离屏页面限制值的意思，该值代表的是在滑动视图中应保留在当前可见页面之外的任一方向上的页面数。

比如，当我们采用水平分页时，该值代表的便是在左右两侧应保留的页面数。

而当我们采用垂直分页时，该值代表的则是在上下两侧应保留的页面数。

保留页面的方式是通过扩展额外的布局空间实现的，以LinearLayoutManager为例，其最关键的步骤在于对calculateExtraLayoutSpace方法的重写：

    /**
    * 计算额外的布局空间
    */
    @Override
    protected void calculateExtraLayoutSpace(@NonNull RecyclerView.State state,
            @NonNull int[] extraLayoutSpace) {
        int pageLimit = getOffscreenPageLimit();
        if (pageLimit == OFFSCREEN_PAGE_LIMIT_DEFAULT) {
            // 仅在需要时才对屏幕外页面进行自定义预取
            super.calculateExtraLayoutSpace(state, extraLayoutSpace);
            return;
        }
        // 计算多pageLimit*2个页面大小的空间
        final int offscreenSpace = getPageSize() * pageLimit;
        extraLayoutSpace[0] = offscreenSpace;
        extraLayoutSpace[1] = offscreenSpace;
    }
    
    /**
    * 获取单个页面大小
    */
    int getPageSize() {
        final RecyclerView rv = mRecyclerView;
        // 水平分页时，取去除了左右内边距后的RecyclerView宽度
        // 垂直分页时，取去除了上下内边距后的RecyclerView高度
        return getOrientation() == ORIENTATION_HORIZONTAL
                ? rv.getWidth() - rv.getPaddingLeft() - rv.getPaddingRight()
                : rv.getHeight() - rv.getPaddingTop() - rv.getPaddingBottom();
    }

该方法会计算LinearLayoutManager应布置的额外空间量（以像素为单位）。已知默认布置的空间量为单个页面大小，则额外布置的空间量应为OffscreenPageLimit*2个单页面大小，计算出来的结果会存储在int数组类型的extraLayoutSpace结构中，其中：

extraLayoutSpace[0]应用于顶部或左侧的额外空间；
extraLayoutSpace[1]应用于底部或右侧的额外空间。

虽然这部分额外创建的页面在当前屏幕上并不可见，但实际已经被添加至我们的视图层次结构中了。这么做可以减少切换分页时花费在视图创建与布局上的时间，从而提升ViewPager2滑动时的整体流畅度。

结合前面两篇文章我们可以看到，从缓存复用机制到预拉取机制再到现在的离屏加载机制，RecyclerView与ViewPager2在提升滑动流畅度方面真的是做了非常多的努力。

区别在于：

缓存复用机制是通过缓存已创建的页面，以提供给新进入屏幕的页面重用来实现的。
预拉取机制是通过利用UI线程空闲的时机，提前创建并缓存下一个待进入屏幕的页面来实现的。
离屏加载机制则是通过扩展额外的布局空间，以提前创建并保留屏幕两侧的页面来实现的。

从调用方法流程上讲，离屏加载机制除了常规的onCreateViewHolder、onBindViewHolder方法之外，还会执行一个多onViewAttachedToWindow方法，以将页面提前添加至我们的视图层次结构中。

虽然我们一直强调的是“ViewPager2的离屏加载机制”，但其实，离屏加载机制并不是ViewPager2才引入的新特性，作为ViewPager的改进版本，ViewPager2也只是把早已存在于ViewPager中的这个特性照搬过来而已，二者的主要区别有以下几点：

对于OffscreenPageLimit默认值的设置
对于OffscreenPageLimit赋值条件的限制

OffscreenPageLimit的默认值设置与赋值条件限制

ViewPager一直为人所诟病的一个点就是，其设置的OffscreenPageLimit默认值为1，且不允许外部传入低于1的修改值，即会强制开启离屏加载机制。

    // 默认的离屏加载限制值为1
    private static final int DEFAULT_OFFSCREEN_PAGES = 1;

    public void setOffscreenPageLimit(int limit) {
        // 小于默认值的数会被强制设为默认值
        if (limit < DEFAULT_OFFSCREEN_PAGES) {
            Log.w(TAG, "Requested offscreen page limit " + limit + " too small; defaulting to "
                    + DEFAULT_OFFSCREEN_PAGES);
            limit = DEFAULT_OFFSCREEN_PAGES;
        }
        if (limit != mOffscreenPageLimit) {
            mOffscreenPageLimit = limit;
            populate();
        }
    }

// 谁赞成，谁反对

这也就意味着，在使用ViewPager构建的滑动视图中，不管开发者需不需要，都至少会有1~2个页面会被离屏加载，而这会导致一系列依赖于Fragment生命周期的逻辑被异常执行，进而产生非预期的结果，需要开发者手动实现延迟加载机制。

相比较之下，ViewPager2设置的OffscreenPageLimit默认值则为-1，也即默认不开启离屏加载机制，且对于外部传入的修改值也只要求必须是大于0的正数或默认值。

     // 默认的离屏加载限制值为-1
    public static final int OFFSCREEN_PAGE_LIMIT_DEFAULT = -1;

    public void setOffscreenPageLimit(@OffscreenPageLimit int limit) {
        // 低于1且非默认值的传参会报异常
        if (limit < 1 && limit != OFFSCREEN_PAGE_LIMIT_DEFAULT) {
            throw new IllegalArgumentException(
                    "Offscreen page limit must be OFFSCREEN_PAGE_LIMIT_DEFAULT or a number > 0");
        }
        mOffscreenPageLimit = limit;
        // 触发重新布局操作，以便通过getExtraLayoutSize()方法进行离屏加载
        mRecyclerView.requestLayout();
    }

另外，我们在本系列的第一篇就讲了，ViewPager2是在RecyclerView的基础上构建而成的。因此，即使是默认不开启离屏加载机制，预拉取机制也会正常工作。

而我们前面又讲了，预拉取机制会提前创建并缓存下一个待进入屏幕的页面，但不会添加至我们的视图层次结构中，因此不会像ViewPager一样，导致一系列依赖于Fragment生命周期的逻辑被异常执行，相当于自动帮我们实现延迟加载机制了。

从以上2个默认数值我们可以看到，无论是ViewPager还是ViewPager2，其对于OffscreenPageLimit默认值的设置都是比较克制的。实际上，在setOffscreenPageLimit方法的注释中，Android也是建议我们将此限制值保持在较低水平，尤其是当我们的页面具有复杂的布局时。

但实际情况是，大部分的开发者为图方便，往往会将此值设为页面总数-1，也即默认会离屏加载所有的页面。

这种做法无疑是很不规范的，为什么说不规范呢？这就引申出我们下一个问题了，即OffscreenPageLimit的不同赋值，会对ViewPager2产生什么样的影响呢？

不同的OffscreenPageLimit值产生的影响

行为表现

OffscreenPageLimit值为-1

当OffscreenPageLimit值为-1时，也即保持默认不开启离屏加载机制，这种情况下只有RecyclerView的缓存复用机制和预拉取机制会工作。

当滑动视图初始化完成时，只有position=0的页面项会被添加至当前视图层次结构中。
随着我们往左滑动屏幕，预拉取机制会开始工作，提前创建position=2的页面项并放入mCachedView中。
同时，position=0的页面项也将随着向左滑动的手势被移出屏幕，并放入mCachedView中。

再次向左滑动屏幕，滑动视图会取出预拉取的position=2的页面项进行使用，同时开启对position=3的页面项的预拉取。
此时，由于还未超过mCachedView大小的限制，下一个被移出屏幕的position=1的页面项也将放入mCachedView中。

第三次向左滑动屏幕，同样，会取出预拉取的position=3的页面项进行使用，同时开启对position=4的页面项的预拉取。
但是，由于超过了mCachedView大小的限制，在下一个被移出屏幕的position=2的页面项尝试进入时，会先按照先进先出的顺序，先从mCachedView中移出position=0的页面项，放入RecyclerPool中对应itemType的ArrayList容器中，然后position=2的页面项才顺利进入mCachedView。
之后的滑动同样遵循这个规律，不再赘述。

OffscreenPageLimit值为1

当OffscreenPageLimit值为1时，也即会在左右两侧各离屏加载1个页面。

当滑动视图初始化完成时，由于左侧无更多的页面项，因此只有position=0及position=1的页面项会被添加至当前视图层次结构中。
随着我们往左滑动屏幕，position=2的页面项会被添加至当前视图层次结构中，而position=0的页面项会继续保留在当前视图层次结构中，同时预拉取机制会开始工作，提前创建position=3的页面项并放入mCachedView中。

再次向左滑动屏幕，滑动视图会取出预拉取的position=3的页面项添加至当前视图层次结构中，而position=1的页面项会继续保留在当前视图层次结构中，并开启对position=4的页面项的预拉取。
同时，position=0的页面项也将随着向左滑动的手势被移出屏幕，并放入mCachedView中。

第三次向左滑动屏幕，同样，会取出预拉取的position=4的页面项添加至当前视图层次结构中，并保留position=2的页面项在当前视图层次结构中，同时开启对position=5的页面项的预拉取。
此时，由于还未超过mCachedView大小的限制，下一个被移出屏幕的position=1的页面项也将放入mCachedView中。

第四次向左滑动屏幕，同样，会取出预拉取的position=5的页面项添加至当前视图层次结构中，并保留position=3的页面项在当前视图层次结构中，同时开启对position=6的页面项的预拉取。
但是，由于超过了mCachedView大小的限制，在下一个被移出屏幕的position=2的页面项尝试进入时，会先按照先进先出的顺序，先从mCachedView中移出position=0的页面项，放入RecyclerPool中对应itemType的ArrayList容器中。

OffscreenPageLimit值为3

当OffscreenPageLimit值为3时，也即会在左右两侧各离屏加载3个页面。

当滑动视图初始化完成时，由于左侧无更多的页面项，因此只有position=0至position=3的页面项会被添加至当前视图层次结构中。
随着我们往左滑动屏幕，position=4的页面项会被添加至当前视图层次结构中，而position=0的页面项会继续保留在当前视图层次结构中，同时预拉取机制会开始工作，提前创建position=5的页面项并放入mCachedView中。

再次向左滑动屏幕，滑动视图会取出预拉取的position=5的页面项添加至当前视图层次结构中，而position=1的页面项会继续保留在当前视图层次结构中，并开启对position=6的页面项的预拉取。

第三次向左滑动屏幕，滑动视图会取出预拉取的position=6的页面项添加至当前视图层次结构中，而position=2的页面项会继续保留在当前视图层次结构中。也即这个时候，所有的页面项已经都被添加至当前视图层次结构中了。

第四次向左滑动屏幕，由于超出了OffscreenPageLimit值，position=0的页面项将随着向左滑动的手势被移出屏幕，并放入mCachedView中。

第五次向左滑动屏幕，此时，由于还未超过mCachedView大小的限制，下一个被移出屏幕的position=1的页面项也将放入mCachedView中。
第六次向左滑动屏幕，由于开启了预拉取机制，mCachedView大小的限制由默认的2项再加上预拉取的1项，变为3项，因此仍未超过mCachedView大小的限制，下一个被移出屏幕的position=2的页面项仍将放入mCachedView中，此处不再进行动画展示。

OffscreenPageLimit值为页面总数-1

当OffscreenPageLimit值为页面总数-1时，也即在滑动视图初始化完成时就已经离屏加载所有的页面了，这种情况下RecyclerView的缓存复用机制和预拉取机制完全没有工作的机会。

虽然设置更高的OffscreenPageLimit值，可以更好地提升ViewPager2滑动时的流畅度，但由于需要在初始化阶段同时创建多个页面项，意味着将花费更久的创建时间，页面项内容也将更慢显示，同时，由于两侧有更多的页面项被保留而不走缓存复用流程，意味着应用会占用更多的内存，且这些问题将随着页面复杂度提升更加突出。

为了更直观地展示不同的OffscreenPageLimit值对应用的性能影响，我们将从白屏时间、流畅度、占用内存三个维度来进行横向对比：