前言
第一篇文章Fragment 与 FragmentPagerAdapter
我应该算是详细叙述了Fragment与PagerAdapter的一些知识点,但那时候公司还没引进AndroidX的库,最近发现AndroidX与Support库下的PagerAdapter还是有些许区别,多个api都标上了@Deprecate
。
所以这篇文章第一部分会先分析一下二者的区别。
第二部分则讲述ViewPager 与 Viewpager2的接口区别。
第三部为Viewpager2的解析。
一、AndroidX中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().
可以参考 ==> Lifecycle.State
setMaxLifecycle对Fragment周期的具体影响。
相信这时候,你应该有了如何改写懒加载的方法了!
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 版本迭代
viewpager2迁移指南
1. ViewPager2新增功能
1.0.0 的主要功能
- 对之前的 ViewPager 实现的改进:
- RTL(从右向左)布局支持
<androidx.viewpager2.widget.ViewPager2 xmlns:android="http://schemas.android.com/apk/res/android" android:id="@+id/pager" android:layoutDirection="rtl" />
- 垂直方向支持
android:orientation="vertical"
- 可靠的
Fragment
支持(包括处理Fragment
的数据集)
运行时,notifyDatasetChanged()来更新UI,正确的展示。 - 数据集更改动画(包括
DiffUtil
支持)
2. 接口变更
虽然 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的解析
👌 终于到了重中之重的第三部分, == 让我来看下现在的时间,好的,又是一周过去了,真是令人怀念这又浪费的一周的时光。
进入正题。
去年有天晚上闲着没事,我研究了一晚上的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,若子View不消费,直接还给父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源码。
RecycleView的知识,推荐这篇
看完这篇,面试RecyclerView的时候再也不怕了
当然这里没有涉及ViewPager2的具体api的使用,由于实践并不多,所以,还是推荐篇文章吧:
学不动也要学!深入了解ViewPager2
FragmentStateAdapter与ViewPager2
当然这里还要继续说下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();
}
大致顺序解读下这两段代码.
1. 普普通通的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;
}
}
2. 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
。
3. 确定相应的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
}
}
4. ViewHolder与Fragment进行绑定与解除
除了上面onBindViewHolder
中注释提到的特殊情况,一般是在这里进行绑定:
public final void onViewAttachedToWindow(@NonNull final FragmentViewHolder holder) {
placeFragmentInViewHolder(holder);
gcFragments();
}
placeFragmentInViewHolder
中的逻辑判断比较多,我就不贴代码了
大概就是 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);
}
}
到这里,就接近尾声了。
突然想起还有个玩意,还是要提一下的。
5. 页面缓存数量
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中本来就有的,以前居然没注意过,太失败了。
End
这下真的尾声了。
请大佬不吝赐教。