每日一问 ViewPager 这个流传广泛的写法，其实是有问题的！

异常情况：

屏幕旋转 或者内存不足，导致activity被重建。

原因：

重建之后，activity会重新new 三个fragment，但是viewpager持有的三个fragment并不会被替换成这三个新的fragment，而是恢复之前的三个，这个是因为viewpager自身的恢复机制造成。

解决方法：

使用sparsearray 保存fragment，重写instantiateItem，destroyItem，在两个方法里面去增、删fragment。在getItem的时候，new 对应的fragment。

PS：之前看过鸿洋大大的慕课网视频，大概总结了这么多 (^o^)/~

这种写法在什么情况下会有问题？

@licy 同学也已经说了，就是当ViewPager所属Activity被Destroy（非主动finish）后重新初始化过程中，此时新创建的Fragment实例并不会在ViewPager中显示。

为什么会这样呢？

先来看看我们定义Adapter时重写的getItem方法是在哪里被调用的：

public Object instantiateItem(@NonNull ViewGroup container, int position) {
    ......

    final long itemId = getItemId(position);

    // Do we already have this fragment?
    String name = makeFragmentName(container.getId(), itemId);

    Fragment fragment = mFragmentManager.findFragmentByTag(name);
    if (fragment != null) {
        mCurTransaction.attach(fragment);
    } else {
        fragment = getItem(position);
        mCurTransaction.add(container.getId(), fragment, makeFragmentName(container.getId(), itemId));
    }
    ......
    return fragment;
}

咦？在instantiateItem方法中，我们重写的getItem方法竟然不是每次都会被调用的！它会先判断FragmentManager是否已添加了目标Fragment（findFragmentByTag），如果已经添加了的话，就会把它取出来并重新关联上，而getItem方法就不会被调用了。

如果从FragmentManager中找不到的话，才会调用getItem获取目标Fragment，然后通过事务来添加进去，注意此时add方法的第三个参数(tag)传的是makeFragmentName方法的返回值，它跟上面查找时传的值是一样的，来看一下：

private static String makeFragmentName(int viewId, long id) {
    return "android:switcher:" + viewId + ":" + id;
}

超简单，就是拼接一个字符串。

看回instantiateItem方法，可以看到makeFragmentName的两个参数分别传的是container的id值和getItemId方法返回的值：

public long getItemId(int position) {
    return position;
}

getItemId方法如果不重写的话，返回就是参数值，也就是ViewPager页面的索引值了。

好，总结一下：

• 在FragmentPagerAdapter的instantiateItem方法（这个方法会在ViewPager滑动状态变更时调用）中，每个position所对应的Fragment只会添加一次到FragmentManager里面，也就是说，我们在Adapter中重写的getItem方法，它的参数position不会出现两次相同的值。

• 当Fragment被添加时，会给这个Fragment指定一个根据itemId来区分的tag，而这个itemId就是根据getItemId方法来获取的，默认就是当前页面的索引值。

如何避免开头所说的问题？

现在我们已经知道了问题发生的原因，要解决的话，对症下药就行了：

既然ViewPager在添加新Item时会优先查找FragmentManager中已存在的Fragment，那么我们在Activity重建后，实例Fragment时也可以像它那样，先看看FragmentManager中有没有，如果有的话就直接重用，不用new了。

比如定义一个instantiateFragment方法：

private Fragment instantiateFragment(ViewPager viewPager, int position, Fragment defaultResult) {
    String tag = "android:switcher:" + viewPager.getId() + ":" + position;
    Fragment fragment = getSupportFragmentManager().findFragmentByTag(tag);
    return fragment == null ? defaultResult : fragment;
}

然后在原来实例化Fragment的地方：

mfragment1 = new fragment1();
mfragment2 = new fragment2();
mfragment3 = new fragment3();

改成：

mfragment1 = instantiateFragment(m_vp, 0, new fragment1());
mfragment2 = instantiateFragment(m_vp, 1, new fragment2());
mfragment3 = instantiateFragment(m_vp, 2, new fragment3());

就OK啦！！！

这样的话，就算Activity被意外销毁，重新创建时，我们也一样能找回原来已经添加了的Fragment。

利用 adapter.getItem(pos)这个获取fragment

出现问题我觉得应该都是使用不当导致的

如下：

在MainActivity获取到数据某一处数据后，需要通知到所有Fragment更新，书写错误就会这样

        //然后
                m_vp.setOffscreenPageLimit(3);
                这个setOffscreenPageLimit 不写 使用默认的
                //
        mfragment1 = new PageFragment();
        mfragment2 = new PageFragment2();
        mfragment3 = new PageFragment3();
                //button 模拟获取修改数据
                 button.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                PageFragment fragment = (PageFragment) adapter.getItem(0);
                fragment.setText("1");
                PageFragment2 fragment2 = (PageFragment2) adapter.getItem(1);
                fragment2.setText("2");
                PageFragment3 fragment3 = (PageFragment3) adapter.getItem(2);
                fragment3.setText("3");
            }
        });

发生崩溃或异常两种情况：1、PageFragment3这个Fragment没划到也没加载过，button一按 必然崩溃

2、加载过是不会崩溃的 ，但是这样修改的话 不设置这个setOffscreenPageLimit 肯定会有页面因为被回收异常就发生了，

还有现在FragmentAdapter不用这个的，顺带一提改用这个Behavior，方便了处理生命周期了，也方便懒加载了

public FragmentPagerAdapter(@NonNull FragmentManager fm,
            @Behavior int behavior) {
    }

大致我理解是这些，不知道是否回答到点上

为什么都在说和"ViewPager自身的恢复机制造成的"。难道不应该是在activity重建前调用FragmentManager的保存和activity重建后FragmentManager的恢复机制造成的。和ViewPager有什么关系？

而FragmentPagerAdapter在instantiateItem时根据tag获取fragment。那么activity重建后保存的fragment被恢复了。通过findFragmentByTag查找的还是原先的fragment。而此时重建后的activity又重新new了fragment。这就造成你以为是自己，其实不是。如果使用list去get某个位置fragment刷新时，就会刷新无效。而解决此问题的做法@陈小缘 已经解答。另外如果需要获取adapter中的fragment推荐使用FragmentManager# findFragmentByTag

问题

如果这个只是基本的展示，那是没有问题的，可以正常展示，不会崩溃

但是在onCreate里面加一段新的代码：

fun onCreate(savedInstanceState Bundle) {
        adapter.getItem(0).change() //change方法是调用Fragment里一个操作UI的方法
}

同时在调试中把”不保留活动“打开，按home退到后台再点击icon回来的时候就崩溃了！

原因

这是因为ViewPager自身有恢复机制，这时ViewPager里的fragment的list和onCreate赋值的fragmentList已经不是一个对象了。fragmentList里的fragment并没有attch到activity里，所以并没有create，导致对里面的UI进行操作就会崩溃了

解决方案

在onCreate的时候恢复fragmentList

 if (savedInstanceState != null) {
            fragmentList.addAll(supportFragmentManager.fragments)
        } else {
            fragmentList.addAll(listOf(fragment1(), fragment2(), fragment3()))
        }

这样我们外面的fragmentList就和ViewPager恢复出来的list内部保存的对象一样了

不让ViewPager恢复

覆写FragmentPagerAdapter的saveState()方法

override fun saveState() = null

当然这种方式并不推荐

我也遇到过这个问题😄

https://blog.csdn.net/SS_S1gn/article/details/94456382

大佬，请问怎么提问题呢？