ViewPager2知识大合集，让你一次看过瘾！
/ 今日科技快讯 /
近日，随着新型冠状病毒疫情继续蔓延，美国当地时间周二，谷歌通过电子邮件发布通知，建议其北美地区所有员工在家办公，并一直持续到4月10日。谷歌在北美有超过10万名员工。
/ 作者简介 /
本篇文章来自真心czx的投稿，分享了他对ViewPager2的解析以及和Viewpager相区别的知识整理，相信会对大家有所帮助！同时也感谢作者贡献的精彩文章。
真心czx的博客地址：
https://www.jianshu.com/u/c038fa518b35
/ 前言 /
最近发现AndroidX与Support库下的PagerAdapter还是有些许区别，多个api都标上了@Deprecate。
所以这篇文章第一部分会先分析一下二者的区别。第二部分则讲述ViewPager与Viewpager2的接口区别。第三部为Viewpager2的解析。
/ FragmentPagerAdapter的变化 /
其中FragmentPagerAdapter和FragmentStatePagerAdapter的变化大同小异，就以FragmentPagerAdapter为例。
@Behavior
首先很明显的一点就是FragmentPagerAdapter的构造函数多了一个参数！
@Retention(RetentionPolicy.SOURCE)
@IntDef({BEHAVIOR_SET_USER_VISIBLE_HINT, BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT})
private @interface Behavior { }
@Deprecated
public FragmentPagerAdapter(@NonNull FragmentManager fm) {
this(fm, BEHAVIOR_SET_USER_VISIBLE_HINT);
}
/ *
* @param fm fragment manager that will interact with this adapter
* @param behavior determines if only current fragments are in a resumed state
*/
public FragmentPagerAdapter(@NonNull FragmentManager fm, @Behavior int behavior) {
mFragmentManager = fm;
mBehavior = behavior;
}
就是Behavior这个玩意，当其值为默认的BEHAVIOR_SET_USER_VISIBLE_HINT时，那么FragmentPagerAdapter的表现就会与原support库下一致，当为BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT时，那事情就会有点意思了！会影响ViewPager下Fragment的生命周期。
懒加载
As we know （翻译：众所周知。知识点！），以前我们切换Fragment页面时，Adapter会调用fragement.setUserVisibleHint(boolean isVisibleToUser)来标志ViewPager的当前显示页面。而我们用getUserVisibleHint()来判断并执行懒加载。
就这几年开发经验来说，见过几个项目不同同事的关于ViewPager中不同的懒加载的处理，大多数是不处理！在onViewCreated()的时候，把当前页面以及两侧缓存的页面的数据都做了请求~没有一丝丝防备。。
当然这样写非常的简单，也不会出错，只是没必要，毕竟不少情况下，用户可能都不会去滑动ViewPager。所以作为一位码农，还是要有点追求的，何况这个问题处理起来也不难。
懒加载的三个判断：
是否为当前页面（是否可见）
是否已经加载过了
视图是否初始化完成（setUserVisibleHint()的调用在onCreateView之前！）
当然还可以加个是否强制刷新之类的~
var hasLoad = false
var isViewInitiated = false
fun loadData() {
if (userVisibleHint && !hasLoad && isViewInitiated) {
// load
hasLoad = true
}
}
override fun setUserVisibleHint(isVisibleToUser: Boolean) {
super.setUserVisibleHint(isVisibleToUser)
loadData()
}
override fun onActivityCreated(savedInstanceState: Bundle?) {
super.onActivityCreated(savedInstanceState)
isViewInitiated = true
loadData()
}
override fun onDestroyView() {
super.onDestroyView()
isViewInitiated = false // 注意考虑View被销毁，而Fragment对象还在
}
现在世道变了，BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT之下用的是Lifecycle。
public Object instantiateItem(@NonNull ViewGroup container, int position) {
Fragment fragment = mFragmentManager.findFragmentByTag(name);
...
if (fragment != mCurrentPrimaryItem) {
fragment.setMenuVisibility(false);
// 看这里
if (mBehavior == BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT) {
mCurTransaction.setMaxLifecycle(fragment, Lifecycle.State.STARTED);
} else {
fragment.setUserVisibleHint(false);
}
}
return fragment;
}
@Override
public void setPrimaryItem(@NonNull ViewGroup container, int position, @NonNull Object object) {
Fragment fragment = (Fragment)object;
if (fragment != mCurrentPrimaryItem) {
if (mCurrentPrimaryItem != null) {
mCurrentPrimaryItem.setMenuVisibility(false);
// 看这里
if (mBehavior == BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT) {
if (mCurTransaction == null) {
mCurTransaction = mFragmentManager.beginTransaction();
}
mCurTransaction.setMaxLifecycle(mCurrentPrimaryItem, Lifecycle.State.STARTED);
} else {
mCurrentPrimaryItem.setUserVisibleHint(false);
}
}
fragment.setMenuVisibility(true);
// 看这里
if (mBehavior == BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT) {
if (mCurTransaction == null) {
mCurTransaction = mFragmentManager.beginTransaction();
}
mCurTransaction.setMaxLifecycle(fragment, Lifecycle.State.RESUMED);
} else {
fragment.setUserVisibleHint(true);
}
mCurrentPrimaryItem = fragment;
}
}
注意两个函数中的mCurTransaction.setMaxLifecycle(fragment, Lifecycle.State.RESUMED);可发现初始化Fragment时，生命周期最大状态为STARTED。而setPrimaryItem()设置当前的页面为RESUMED, 原先的页面改为STARTED。
STARTED这个值意味着什么呢？
新建的Fragment生命周期在执行onActivityCreated()之后会继续执行onStrat() ，但不会执行onResume()！
而原先处于RESUME状态的则会执行onPause()。
相信这时候，你应该有了如何改写懒加载的方法了！
var hasLoad = false
fun loadData() {
if (hasLoad) {
// load
hasLoad = true
}
}
override fun onResume() {
super.onResume()
loadData()
}
一个变量搞定。so easy, mama never mind my study.押韵就好，Never mind the details.
/ ViewPager与Viewpager2的区别 /
ViewPager2发布好几个月咯（2019.11.20），这么香的控件不学习一波？这一部分主要参考官网的文档。
ViewPager2新增功能
1.0.0 的主要功能，对之前的 ViewPager 实现的改进。
RTL（从右向左）布局支持
垂直方向支持
android:orientation="vertical"
可靠的Fragment支持（包括处理Fragment的数据集）
运行时，notifyDatasetChanged()来更新UI，正确的展示。
数据集更改动画（包括 DiffUtil 支持）
接口变更
虽然ViewPager2保持了大多的ViewPager的API的一致。但是总有一些必须改变，容我娓娓道来。
FragmentStateAdapter<<==FragmentStatePagerAdapter、FragmentPagerAdapter
是的，不用纠结了，统一使用FragmentStateAdapter
RecyclerView.Adapter<<==PagerAdapter
你没有看错，就是RecycleView，还有熟悉的ViewHolder、onBindViewHodler()。
FragmentStateAdapter#createFragment<<==PagerAdapter#getItem
事实证明，以前的方法名称是过去出现问题的根源。使得不少新手在getItem()与instantiateItem()之间打交道时吃过亏。
getItemCount<<==getCount
ViewPage2#registerOnPageChangeCallback<<==addPageChangeListener
用抽象类替代接口，可以不用一次性override三个接口方法了，想用哪个就重载哪个
class ScreenSlidePagerAdapter(fa: FragmentActivity) : FragmentStateAdapter(fa) {
override fun getItemCount(): Int = NUM_PAGES
override fun createFragment(position: Int): Fragment = ScreenSlidePageFragment()
}
另外若使用了TabLayout，那记得升级material至1.1.0。
implementation "com.google.android.material:material:1.1.0"
然后使用TabLayoutMediator。
class CollectionDemoFragment : Fragment() {
...
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
val tabLayout = view.findViewById(R.id.tab_layout)
TabLayoutMediator(tabLayout, viewPager) { tab, position ->
tab.text = "OBJECT ${(position + 1)}"
}.attach()
}
...
}
emmm... mama nerver...
ViewPager2的解析
???? 终于到了重中之重的第三部分， == 让我来看下现在的时间，
刚好午夜12点。休息一下，玩会手机。明天再搬运代码。
好的，又是一周过去了，真是令人怀念这又浪费的一周的时光。
进入正题。去年有天晚上闲着没事，我研究了一晚上的ViewPager源码，最后得出结论，我真是闲得蛋疼。简直毫无意义，各种view偏移量计算以及意义不明的变量，看得是真难受。
发现ViewPager2是RecycleView封装的之后，来了兴趣，于是又干起这无意义的事，研究ViewPager2的源码。幸亏，收获还是有的，源码也很通俗易懂，算上注释代码量也就1607行，原来的一半都不到！
真正进入正题~里面的内容比起ViewPager是极简了。简单说就是将RecycleView再封装了一遍，然后协同FragmentStateAdapter将RecycleView的每个Item与Fragment绑定！
ending，happy~
别打脸，我继续说就是了。看下ViewPager2的初始化。
ViewPager2中除了初始化的代码，其它值得关注的地方并不多。
private void initialize(Context context, AttributeSet attrs) {
mAccessibilityProvider = sFeatureEnhancedA11yEnabled
? new PageAwareAccessibilityProvider()
: new BasicAccessibilityProvider();
mRecyclerView = new RecyclerViewImpl(context);
mRecyclerView.setId(ViewCompat.generateViewId());
mRecyclerView.setDescendantFocusability(FOCUS_BEFORE_DESCENDANTS);
mLayoutManager = new LinearLayoutManagerImpl(context);
mRecyclerView.setLayoutManager(mLayoutManager);
mRecyclerView.setScrollingTouchSlop(RecyclerView.TOUCH_SLOP_PAGING);
setOrientation(context, attrs);
mRecyclerView.setLayoutParams(
new ViewGroup.LayoutParams(LayoutParams.MATCH_PARENT, LayoutParams.MATCH_PARENT));
mRecyclerView.addOnChildAttachStateChangeListener(enforceChildFillListener());
// Create ScrollEventAdapter before attaching PagerSnapHelper to RecyclerView, because the
// attach process calls PagerSnapHelperImpl.findSnapView, which uses the mScrollEventAdapter
mScrollEventAdapter = new ScrollEventAdapter(this);
// Create FakeDrag before attaching PagerSnapHelper, same reason as above
mFakeDragger = new FakeDrag(this, mScrollEventAdapter, mRecyclerView);
mPagerSnapHelper = new PagerSnapHelperImpl();
mPagerSnapHelper.attachToRecyclerView(mRecyclerView);
// Add mScrollEventAdapter after attaching mPagerSnapHelper to mRecyclerView, because we
// don't want to respond on the events sent out during the attach process
mRecyclerView.addOnScrollListener(mScrollEventAdapter);
mPageChangeEventDispatcher = new CompositeOnPageChangeCallback(3);
mScrollEventAdapter.setOnPageChangeCallback(mPageChangeEventDispatcher);
// Callback that updates mCurrentItem after swipes. Also triggered in other cases, but in
// all those cases mCurrentItem will only be overwritten with the same
// 删除几个设置各种事件监听的代码
...
attachViewToParent(mRecyclerView, 0, mRecyclerView.getLayoutParams());
}
其中mRecyclerView = new RecyclerViewImpl(context);和mLayoutManager = new LinearLayoutManagerImpl(context); 属于重新封装的RecyclerView和LinearLayoutManager，是分别为了处理事件拦截和ViewPager缓存页面的问题。
事件拦截我们结合mFakeDragger = new FakeDrag(this, mScrollEventAdapter, mRecyclerView); 来看。FakeDragger模拟拖拽事件！通过设置 setUserInputEnabled(false)拦截用户触摸事件，那就得通过模拟拖拽来实现切换下一页了。
class RecyclerViewImpl {
...
public boolean onTouchEvent(MotionEvent event) {
// isUserInputEnabled == false 则 不执行super.onTouchEvent(event)
return isUserInputEnabled() && super.onTouchEvent(event);
}
@Override
public boolean onInterceptTouchEvent(MotionEvent ev) {
// isUserInputEnabled == false 结合上面，就是，不拦截也不消费，也不往下传递，直接还给父View
return isUserInputEnabled() && super.onInterceptTouchEvent(ev);
}
}
而mPagerSnapHelper = new PagerSnapHelperImpl();，PagerSnapHelper，即RecycleView的官方辅助类，则是为使得RecycleView的每个Item默认大小都是MATCH_PARENT，即每滑动一个就是一页，且不能快速滑动。最终RecycleView成为ViewPager的子View。
attachViewToParent(mRecyclerView, 0, mRecyclerView.getLayoutParams());
也就是这样使得RecycleView有了ViewPager的特性！真的不能再简单了，去你的ViewPager源码。
/ 结合到一起 /
当然这里还要继续说下FragmentStateAdapter与ViewPager2是怎么玩的。而关键之处就是如何使ViewItem与Fragment绑定，使之拥有生命周期。
先看看熟悉这两个方法：
@NonNull
@Override
public final FragmentViewHolder onCreateViewHolder(@NonNull ViewGroup parent, int viewType) {
return FragmentViewHolder.create(parent);
}
@Override
public final void onBindViewHolder(final @NonNull FragmentViewHolder holder, int position) {
final long itemId = holder.getItemId();
final int viewHolderId = holder.getContainer().getId();
final Long boundItemId = itemForViewHolder(viewHolderId); // item currently bound to the VH
if (boundItemId != null && boundItemId != itemId) {
removeFragment(boundItemId);
mItemIdToViewHolder.remove(boundItemId);
}
mItemIdToViewHolder.put(itemId, viewHolderId); // this might overwrite an existing entry
ensureFragment(position);
/** Special case when {@link RecyclerView} decides to keep the {@link container}
* attached to the window, but not to the view hierarchy (i.e. parent is null) */
// 这里不是很懂了。指的是特殊情况下：container已经AttcahedToWindow，但是container.getParent() == null，需要重新绑定下Fragment。啥时候会发生这情况呢？
final FrameLayout container = holder.getContainer();
if (ViewCompat.isAttachedToWindow(container)) {
if (container.getParent() != null) {
throw new IllegalStateException("Design assumption violated.");
}
container.addOnLayoutChangeListener(new View.OnLayoutChangeListener() {
@Override
public void onLayoutChange(View v, int left, int top, int right, int bottom,
int oldLeft, int oldTop, int oldRight, int oldBottom) {
if (container.getParent() != null) {
container.removeOnLayoutChangeListener(this);
placeFragmentInViewHolder(holder);
}
}
});
}
gcFragments();
}
大致顺序解读下这两段代码.
普普通通的FragmentViewHolder
就是一个普通的仅有一个FrameLayout的Holder。等待Fragment的视图在正确的时机被add进来。
/**
* {@link ViewHolder} implementation for handling {@link Fragment}s. Used in
* {@link FragmentStateAdapter}.
*/
public final class FragmentViewHolder extends ViewHolder {
private FragmentViewHolder(@NonNull FrameLayout container) {
super(container);
}
@NonNull static FragmentViewHolder create(@NonNull ViewGroup parent) {
FrameLayout container = new FrameLayout(parent.getContext());
container.setLayoutParams(
new ViewGroup.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT,
ViewGroup.LayoutParams.MATCH_PARENT));
container.setId(ViewCompat.generateViewId());
container.setSaveEnabled(false);
return new FragmentViewHolder(container);
}
@NonNull FrameLayout getContainer() {
return (FrameLayout) itemView;
}
}
onBindViewHolder() 变量解析
开局就三个无知所谓的id，真叫人头大。
final long itemId = holder.getItemId();
final int viewHolderId = holder.getContainer().getId();
final Long boundItemId = itemForViewHolder(viewHolderId); // 1
if (boundItemId != null && boundItemId != itemId) {
removeFragment(boundItemId);
mItemIdToViewHolder.remove(boundItemId);
}
// 与注释1结合，boundItemId要么为null，要么等于itemId
mItemIdToViewHolder.put(itemId, viewHolderId)
先看下itemId的值是什么。由于FragmentStateAdapter初始化时就调用了setHasStableIds(true)，使得holder.getItemId()返回的即为holder所在的位置。
class ViewHolder {
public final long getItemId() {
return mItemId;
}
}
class RecycleView.Adapter：
public final void bindViewHolder(@NonNull VH holder, int position) {
holder.mPosition = position;
if (hasStableIds()) {
holder.mItemId = getItemId(position); // 看我看我
}
...
}
class FragmentStateAdapter extend RecycleView.Adapter {
public FragmentStateAdapter(@NonNull FragmentManager fragmentManager,
@NonNull Lifecycle lifecycle) {
mFragmentManager = fragmentManager;
mLifecycle = lifecycle;
// 注意使用的super。因为这里FragmentStateAdapter覆盖了这个方法
// 其实现是接直接抛出UnsupportedOperationException,并不想让你设置为false
super.setHasStableIds(true); // 看我
}
public long getItemId(int position) { // 看我
return position;
}
}
所以也就是说itemId = holder.getItemId() = adapter.getItemId() = position。而至于viewHolderId就是ViewHolder中的FrameLayout的viewId。跟定义在xml中的固定值不一样了，这里每个ViewHolder的viewId都不相同。
container.setId(ViewCompat.generateViewId());
boundItemId则是 用于将 viewHolderId 保存在Adapter的LongSparseArray中所使用的Key值（位置），这个值在另外一个列表中同时也指向某个Fragment。实际上 保存的时候，最终值依然等于position。
确定相应的Fragment，ensureFragment()
onBindViewHolder中还会继续执行这一步，根据缓存判断是否需要创建新的Fragment，并将之前回收Fragment的时保留的状态恢复回来。
private void ensureFragment(int position) {
long itemId = getItemId(position);
if (!mFragments.containsKey(itemId)) {
// TODO(133419201): check if a Fragment provided here is a new Fragment
Fragment newFragment = createFragment(position);
newFragment.setInitialSavedState(mSavedStates.get(itemId));
mFragments.put(itemId, newFragment); // itemId也对应着Fragment
}
}
ViewHolder与Fragment进行绑定与解除
除了上面onBindViewHolder中注释提到的特殊情况，一般是在这里进行绑定：placeFragmentInViewHolder中的逻辑判断比较多，我就不贴代码了。
public final void onViewAttachedToWindow(@NonNull final FragmentViewHolder holder) {
placeFragmentInViewHolder(holder);
gcFragments();
}
大概就是Fragment是否已经添加入FragmentManager，View是否销毁了。否则执行：
class FragmentStateAdapter {
placeFragmentInViewHolder() {
mFragmentManager.beginTransaction()
.add(fragment, "f" + holder.getItemId())
.setMaxLifecycle(fragment, STARTED) // 嘿嘿
.commitNow();
//然后等待Fragment的View创建完成后， 添加到holder的FrameLayout上：
mFragmentManager.registerFragmentLifecycleCallbacks(
new FragmentManager.FragmentLifecycleCallbacks() {
// TODO(b/141956012): Suppressed during upgrade to AGP 3.6.
@SuppressWarnings("ReferenceEquality")
@Override
public void onFragmentViewCreated(@NonNull FragmentManager fm,
@NonNull Fragment f, @NonNull View v,
@Nullable Bundle savedInstanceState) {
if (f == fragment) {
fm.unregisterFragmentLifecycleCallbacks(this);
// 这里
addViewToContainer(v, container);
}
}
}, false);
}
}
嘿，注意关键点！setMaxLifecycle(fragment, STARTED) 懒加载！默认STARTED,跟ViewPager一样。滑动页面时：
public void onPageScrollStateChanged(int state) {
updateFragmentMaxLifecycle(false);
}
会将当前的Fragent设置为RESUME，所以说起来ViewPager2的懒加载就跟AndroidX中的ViewPager一样咯。在onResume()中判断下是否已经加载过了就好了。
最后在onViewRecycled时 回收Fragment，保留状态。跟FragmentStatePagerAdapter很是相似了。
@Override
public final void onViewRecycled(@NonNull FragmentViewHolder holder) {
final int viewHolderId = holder.getContainer().getId();
final Long boundItemId = itemForViewHolder(viewHolderId); // item currently bound to the VH
if (boundItemId != null) {
removeFragment(boundItemId);
mItemIdToViewHolder.remove(boundItemId);
}
}
到这里，就接近尾声了。突然想起还有个玩意，还是要提一下的。
页面缓存数量
public void setOffscreenPageLimit(@OffscreenPageLimit int limit) {
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;
// Trigger layout so prefetch happens through getExtraLayoutSize()
mRecyclerView.requestLayout();
}
这里的OFFSCREEN_PAGE_LIMIT_DEFAULT默认值为-1，若调用该方法则不可设置小于1的情况。上面我们提LinearLayoutManagerImp有设置页面缓存的作用，就是这里了：
@Override
protected void calculateExtraLayoutSpace(@NonNull RecyclerView.State state,
@NonNull int[] extraLayoutSpace) {
int pageLimit = getOffscreenPageLimit(); // 看我看我
if (pageLimit == OFFSCREEN_PAGE_LIMIT_DEFAULT) {
// Only do custom prefetching of offscreen pages if requested
super.calculateExtraLayoutSpace(state, extraLayoutSpace);
return;
}
final int offscreenSpace = getPageSize() * pageLimit;
extraLayoutSpace[0] = offscreenSpace; // 左右两边额外布局
extraLayoutSpace[1] = offscreenSpace;
}
调用setOffscreenPageLimit使得RecycleView 预加载（绘制）了前后的页面。当其值为默认的OFFSCREEN_PAGE_LIMIT_DEFAULT时，则会依旧按照RecycleView的默认缓存机制进行。
另外，我们上面提了Fragment在onViewRecycled()时被销毁！注意，并不是onViewDetachedFromWindow, 也就是当前页面移出视野，且也不在PageLimit的范围内的时候，虽然View已经DetachedFromWindow，但并未执行onViewRecycled()，所以Fragment, 还是与这个View绑定的呢，毕竟，又滑回到这个页面时，并不会执行onBindViewHolder。一般再多滑两页，这个Fragment才会被销毁。
这里引出一个思考，为什么不在onViewRecycled()对应的onBindViewHolder()中进行 ViewHolder与Fragment的绑定？
发现，在使用ViewPager2中，滑动页面会预加载执行onBindViewHolder()。看这份log，当前使用的setOffscreenPageLimit(1)。
//打开页面
2020-03-07 18:19:12.298 I: createFragment 0
2020-03-07 18:19:12.299 I: onBindViewHolder 0
2020-03-07 18:19:12.300 I: onCreate 0
2020-03-07 18:19:12.300 I: onStart 0
2020-03-07 18:19:12.301 I: onResume 0
2020-03-07 18:19:12.302 I: createFragment 1
2020-03-07 18:19:12.303 I: onBindViewHolder 1
2020-03-07 18:19:12.303 I: onCreate 1
2020-03-07 18:19:12.303 I: onStart 1 // 初始化第一页和第二页，✔️
//这个时间点开始滑动切换第2页(注意，下标为1！)
2020-03-07 18:19:18.556 I: createFragment 2
2020-03-07 18:19:18.557 I: onBindViewHolder 2
2020-03-07 18:19:18.561 I: onCreate 2
2020-03-07 18:19:18.566 I: onStart 2
// 看这里，执行了第四页的onBindViewHolder！
2020-03-07 18:19:18.590 I: createFragment 3
2020-03-07 18:19:18.591 I: onBindViewHolder 3
2020-03-07 18:19:18.942 I: onPause 0
2020-03-07 18:19:18.943 I: onResume 1
// 切换至第三页，第四页的生命周期才被加载！
2020-03-07 18:31:35.898 I: onCreate 3
2020-03-07 18:31:35.900 I: onStart 3
OFFSCREEN_PAGE_LIMIT_DEFAULT的情况也类似！也就是说，滑动会预先实例化Fragment的情况，若在onBindViewHolder进行绑定，Fragment的生命周期开始执行，那就出问题了嘛。
我原本以为这只是ViewPager2才会这样（预加载），是不是自己遗漏了什么。然后用RecycleView直接加载一个一些普通View试试，同时也用了support 包下28.0.0版本RecycleView进行验证。才发现其实这个预加载在RecycleView中本来就有的，以前居然没注意过，太失败了。
推荐阅读：
写一篇最好懂的https讲解
Handler的文章一大把，这篇写的真形象
Kotlin vs Flutter，我到底应该怎么选？
欢迎关注我的公众号
学习技术或投稿
长按上图，识别图中二维码即可关注