今天我要来纠正一个关于 ViewPager 的错误用法。
这个错误写法其实广为流传,我在早期的博客也有类似的写法。
下面开始正文:
我随便在网上搜了个 ViewPager + Fragment 用法,类似的代码很常见:
public class MainActivity extends FragmentActivity {
private ViewPager m_vp;
private ArrayList<Fragment> fragmentList;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
m_vp = (ViewPager)findViewById(R.id.viewpager);
mfragment1 = new fragment1();
mfragment2 = new fragment2();
mfragment3 = new fragment3();
fragmentList = new ArrayList<Fragment>();
fragmentList.add(mfragment1);
fragmentList.add(mfragment2);
fragmentList.add(mfragment3);
// FragmentPagerAdapter
m_vp.setAdapter(new MyViewPagerAdapter(getSupportFragmentManager()));
}
public class MyViewPagerAdapter extends FragmentPagerAdapter{
@Override
public Fragment getItem(int arg0) {
return fragmentList.get(arg0);
}
@Override
public int getCount() {
return fragmentList.size();
}
}
}
很多同学都喜欢这么写,然后还经常通过
adapter.getItem(pos)
或
fragmentList.get(pos)
去获取对应的 fragment。
其实,这种写法是存在很大的问题的!
我们引出几个问题来慢慢回答:
- 这种写法在什么情况下,会造成什么异常(问题以及对应的场景)?
- 造成该问题的原因是(原理)?
- 更好的写法应该是什么(提供根据 position 获取对应 Fragment 方法)?
1 异常情况
在Activity 被触发重建行为时会发生异常情况,什么时候会重建呢?
例如你的 Activity 被用户切换到后台, 此时用户打王者荣耀去了,打完回来,由于内存原因,你的 Activity 很可能被系统干掉,然后用户切回你的app,对应的 Activity 就会尝试重建。
上面的代码,重建时会产生什么问题呢?
重建会走 Activity#onCreate,然后就会执行:
mfragment1 = new fragment1();
mfragment2 = new fragment2();
mfragment3 = new fragment3();
fragmentList = new ArrayList<Fragment>();
fragmentList.add(mfragment1);
fragmentList.add(mfragment2);
fragmentList.add(mfragment3);
重新创建了 3 个 fragment,然后放到 fragmentList 中。
但是,问题在于Activity 重建的时候,上一次界面上的Fragment 相关信息会被存储下来用于恢复。
对应到上例,ViewPager 的 FragmentPagerAdapter 在恢复的时候,会尝试恢复上次的Fragment。
而你这次新创建的 3 个 Fragment 则完全没有被使用,这就导致后续你在通过 fragmentList 获取的 Fragment 对象其实和界面完全不是一个对象,如果你尝试做一些操作那大概率崩溃了,因为这些二次创建的 Fragment 都没往下走生命周期,里面的 View 都没初始化。
为什么会这样呢?
2 为什么会这样
需要从 FragmentPagerAdapter 的源码中来寻找答案了。
先来看看我们定义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方法就不会被调用了。
咦?在instantiateItem方法中,我们重写的getItem方法竟然不是每次都会被调用的!
它会先判断FragmentManager是否已添加了目标Fragment(findFragmentByTag),如果已经添加了的话,就会把它取出来并重新关联上,而getItem方法就不会被调用了。
超简单,就是拼接一个字符串。
看回 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 方法来获取的,默认就是当前页面的索引值。
怎么避免上面的问题呢?
3 如何避免这样的问题 ,方式一
现在我们已经知道了问题发生的原因,要解决的话,对症下药就行了:
既然 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 。
等等,这个方式好像有一丝小问题。
4 如何避免这样的问题 ,方式二
刚才的方案确实可以,相当于每次先通过 FragmentManager 去取,能够取到就直接使用,取不到就重新创建。
但是取 fragment 需要通过 tag 或者 id 。
上例使用了 tag ,但是 FragmentPagerAdapter 的 makeFragmentName 方法是私有的,也就是说,未来它可能会修改它内部 tag 生成的逻辑。
一旦 tag 的逻辑修改了,上述代码就要一起修改。
还有个解决上述问题的思路。
类似代码如下:
public class MyPagerAdapter extends FragmentStatePagerAdapter {
SparseArray<Fragment> registeredFragments = new SparseArray<Fragment>();
public MyPagerAdapter(FragmentManager fm) {
super(fm);
}
@Override
public int getCount() {
return ...;
}
@Override
public Fragment getItem(int position) {
return MyFragment.newInstance(...);
}
@Override
public Object instantiateItem(ViewGroup container, int position) {
Fragment fragment = (Fragment) super.instantiateItem(container, position);
registeredFragments.put(position, fragment);
return fragment;
}
@Override
public void destroyItem(ViewGroup container, int position, Object object) {
registeredFragments.remove(position);
super.destroyItem(container, position, object);
}
public Fragment getRegisteredFragment(int position) {
return registeredFragments.get(position);
}
}
其实关键点就一点,getItem 这个方法不是 get Fragment,其实称之为 create Fragment更为合适,你的 Fragment 创建逻辑可以放这个方法里。
在 Google 的 ViewPager2 的介绍中,也有类似的话术:
https://developer.android.google.cn/jetpack/androidx/releases/viewpager2
如果你想保存一份 Fragment 的引用,可以利用 instantiateItem,因为这个方法,在重建也会被回调(参考上述源码)。
上述的问题stackoverflow也有相关讨论,这个代码就是来自下面这个链接,也可以阅读下:
https://stackoverflow.com/questions/8785221/retrieve-a-fragment-from-a-viewpager
好了,如果你发现项目中有少量的跟 Fragment 相关的空指针或者一些 Fragment 状态相关的崩溃,很可能就是上述原因引起的,检查下代码吧。
不要觉得很多文章说的复现步骤是横纵屏切换,以为设置为竖屏就能避免该问题,并不能。
感谢内容作者为:@licy,@陈小缘,@鸿洋。