亲宝软件园·资讯

展开

Android中Fragment管理及重叠 Android中Fragment管理及重叠问题的解决办法

人气:0
想了解Android中Fragment管理及重叠问题的解决办法的相关内容吗,在本文为您仔细讲解Android中Fragment管理及重叠的相关知识和一些Code实例,欢迎阅读和指正,我们先划重点:android,fragment重叠,android,fragment,fragment重叠解决方案,下面大家一起来学习吧。

一、Fragment介绍

fragment在3.0被引入以后,项目使用fragment越来越多,特别是主界面是底部tab页点击切换更换内容,当然啦, Fragment 在项目中存在着广泛的时候,例如通常在首页的设计中,通常底部的每一个 navigation 都对应这一个对应的 Fragment ,使用 Fragment 减轻了对应 Activity 的职责,让 Fragmen t充当了部分的Activity的职责。而且使用 Fragment 的时候,提高了代码和布局的封装和复用,这个优势也是特别的明显。

Fragment 拥有自己的生命周期管理,但是它是依赖对应的Activity的。

嗯,生命周期的介绍不是本篇的重点,贴个图加深一下印象。

二、Fragment的栈管理及其生命周期

addToShow

FragmentTransaction transaction = manager.beginTransaction();
 String tag = to.getClass().getSimpleName();
 transaction.add(from.getContainerId(), to, tag)
   .addToBackStack(tag)
   .hide(from)
   .show(to)
   .commit();

如果使用 add() hide() 来控制跳转的话,对应的生命周期是这样的:

E/TAG: onAttach: Fragment09
 E/TAG: onCreate: Fragment09
 E/TAG: onCreateView: Fragment09
 E/TAG: onStart: Fragment09
 E/TAG: onResume: Fragment09
 E/____TAG____: onClick: 2131558527
 E/TAG: onAttach: Fragment10
 E/TAG: onCreate: Fragment10
 E/TAG: onHiddenChanged: Fragment09不可见了!
 E/TAG: onCreateView: Fragment10
 E/TAG: onStart: Fragment10
 E/TAG: onResume: Fragment10

如果此时从第二个 Fragment 再次返回到第一个 Fragment :

E/TAG: onHiddenChanged: Fragment10不可见了!
 E/TAG: onHiddenChanged: Fragment09可见了!!
 E/TAG: onPause: Fragment10
 E/TAG: onStop: Fragment10
 E/TAG: onDestroyView: Fragment10
 E/TAG: onDestroy: Fragment10
 E/TAG: onDetach: Fragment10

可以对应上面的图片,当返回的时候是直接销毁的当前的 Fragment 的,然后第一个 Fragment 只是从不可见的状态变为了可见的状态,并没有走相关的生命周期,所以 hide() 的方法不会触发 onPause() 等生命周期回调方法。

那么如果我们锁屏了或者切换任务之后再切换回来的话:

E/TAG: onPause: Fragment09
 E/TAG: onPause: Fragment10
 E/TAG: onStop: Fragment09
 E/TAG: onStop: Fragment10
 E/TAG: onStart: Fragment09
 E/TAG: onStart: Fragment10
 E/TAG: onResume: Fragment09
 E/TAG: onResume:不可见的 Fragment09
 E/TAG: onResume: Fragment10
 E/TAG: onResume:可见的 Fragment10

这里可以看到,所有的 Fragment 都回去随着 Activity 去回调相关方法,不管它是否可见。

replaceTo

FragmentTransaction transaction = manager.beginTransaction();
 String tag = to.getClass().getSimpleName();
 transaction.replace(from.getContainerId(), to, tag)
   .addToBackStack(tag)
   .commit();

replace() 的方法其实就是相当于 remove() 移除之前添加到这个容器中的所有 Fragment 然后再 add() 添加当前的。那么既然会调用 remove() 方法,所以生命周期就是这样的啦:

E/TAG: onAttach: Fragment09
 E/TAG: onCreate: Fragment09
 E/TAG: onCreateView: Fragment09
 E/TAG: onStart: Fragment09
 E/TAG: onResume: Fragment09
 E/TAG: onResume:可见的 Fragment09
 E/____TAG____: onClick: 2131558527
 E/TAG: onAttach: Fragment10
 E/TAG: onCreate: Fragment10
 E/TAG: onPause: Fragment09
 E/TAG: onStop: Fragment09
 E/TAG: onDestroyView: Fragment09
 E/TAG: onCreateView: Fragment10
 E/TAG: onStart: Fragment10
 E/TAG: onResume: Fragment10
 E/TAG: onResume:可见的 Fragment10

对比上面的log来看的话,当 remove() 调用之后, Fragment 会执行 onPause() onStop()onDestroyView() 会一次被调用,但是 onDestroy() onDetach() 是不会被调用的,这就是说它的视图会被摧毁了,那么重新回来的时候,就得重新创建:

E/TAG: onPause: Fragment10
 E/TAG: onStop: Fragment10
 E/TAG: onDestroyView: Fragment10
 E/TAG: onDestroy: Fragment10
 E/TAG: onDetach: Fragment10
 E/TAG: onCreateView: Fragment09
 E/TAG: onStart: Fragment09
 E/TAG: onResume:可见的 Fragment09

同样的,锁屏了或者切换任务之后再切换回来的话:

E/TAG: onStart: Fragment10
 E/TAG: onResume:可见的 Fragment10
 E/TAG: onPause: Fragment10
 E/MainActivity: onSaveInstanceState: 保存当前TAG
 E/TAG: onStop: Fragment10
 E/TAG: onStart: Fragment10
 E/TAG: onResume:可见的 Fragment10

可以看到,当使用了 replace() 之后,这些情况之下只会有top的 Fragment 来响应对应的生命周期。在上面的 add() 中,两个 Fragment 都走了相关的生命周期的。

那么问题来了:什么时候使用 replace() 什么时候使用 add() hide() 的呢?!其实对比来看,主要就是效率的问题和相关生命周期问题。

效率问题:

如果使用 replace() 就意味着每次的需要走 onCreateView() 再次去重新填充布局。如果在 onCreateView() 方法中还包含了初始化数据的话,也意味着相关的也要重新执行一次。

数据、页面刷新问题:

如果你使用 replace() 从 AFragment 跳转到 BFragment , BFragment 中更新了相关数据会影响到 AFragment 的相关 View 展示的话,这里也会有问题,就算你使用 EventBus 什么的通知了, AFragment 的确可以改变,但是当你切回到 AFragment ,它会走 onCreateView() 重新创建相关布局,除非你保存到了全局,初始化的时候再次设置,那么之前发送的数据就会丢失了。

生命周期匹配问题:

生命周期的方法都是匹配成对出现的,上面说到的 replace() 方法中,A替换的时候走了以下三个生命周期回调方法:

E/TAG: onPause: Fragment09
 E/TAG: onStop: Fragment09
 E/TAG: onDestroyView: Fragment09

当回退到它的时候,对应的三个生命周期回调就被调用了:

E/TAG: onCreateView: Fragment09
 E/TAG: onStart: Fragment09
 E/TAG: onResume:可见的 Fragment09

但是使用 add() hide() 的时候就会比较尴尬,你会发现它的 onPause()onResume() 方法完全不匹配了。只要 add() 了,即使你调用 hide() ,不会影响它的生命周期回调,也不会有 onPause() 等回调。这也就出现了当我们锁屏或者切换任务回来的话,所有add进来的 Fragment 都会执行一遍相关生命周期回调方法:

E/TAG: onPause: Fragment09
 E/TAG: onPause: Fragment10
 E/TAG: onStop: Fragment09
 E/TAG: onStop: Fragment10
 E/TAG: onStart: Fragment09
 E/TAG: onStart: Fragment10
 E/TAG: onResume: Fragment09
 E/TAG: onResume:不可见的 Fragment09
 E/TAG: onResume: Fragment10
 E/TAG: onResume:可见的 Fragment10

所以,如果你做统计相关的,这里可能就有点儿小问题了。当然,它显示与否并不是完全不可知的。

在 Fragment 中可以通过 isHide() 的方法,或者 onHiddenChanged(boolean hiden) 的方法来获取当前是否是 hide 状态。

所以总结起来就是使用 add()hide() 的方式,需要注意 onResume() 等回调方法的不匹配情况和获取数据的时机,应该在可见的时候( isHidden() 返回 false 的时候)才去请求相关数据。

使用 replace() 的话就是要注意频繁的布局填充还有就是 Fragment 与 Fragment 之间的数据传递情况。

状态保存

Fragment重叠异常情况

肯定碰到过Fragment重叠显示的问题吧!?

 

 

这个主要就是 Activity 帮我们在作相关的恢复状态的时候出现的问题。在设置中将不保留后台进程打开,方便产生对应的情况:

然后在第二个页面时回到首页,再次进入,我们先来看看一个异常的情况的log:

E/TAG: onAttach: Fragment09
 E/TAG: onCreate: Fragment09
 E/TAG: onAttach: Fragment10
 E/TAG: onCreate: Fragment10
 E/TAG: onCreateView: Fragment09
 E/TAG: onCreateView: Fragment10
 E/TAG: onAttach: Fragment09
 E/TAG: onCreate: Fragment09
 E/TAG: onCreateView: Fragment09
 E/TAG: onStart: Fragment09
 E/TAG: onStart: Fragment10
 E/TAG: onStart: Fragment09
 E/TAG: onResume:不可见的 Fragment09
 E/TAG: onResume:可见的 Fragment10
 E/TAG: onResume:可见的 Fragment09

尼玛,发现问题没?我们的 Fragment9 居然创建了两次。一个和之前是一样的,不可见的,另外一个居然是可见的,而且还在最上面。所以这个就造成了 Fragment 重叠的情况。

还有一种情况就是断点发现某个 Fragment 初始化成功了,布局也有了,但是里面的View全是空的,这个情况我也遇到过。

为什么会出现这个问题?因为在这种异常情况下,会触发 Android 的临时数据保存机制, Fragment 是它临时保存的重点对象。所以之前的两个 Fragment 相关状态都被保存下来了!但在 Activity 的 onCreate() 中我是这样写的话:

fragmentsUtil.loadRoot(R.id.fragment_container, Fragment9.newInstance());

那么就是说不管是否有保存的状态我都去再次创建加载一次 Fragment9 了,所以这个就导致了 Fragment9 创建了两次(一次是系统恢复出来的,相关状态也是正常的,一次就是我们在 onCreate() 中创建出来的)。那么要避免这个问题就要在 savedInstanceState 这个东西上想想办法了。既然它已经保存了相关的 Fragment 了,我们就不用去再次创建咯!

@Override
protected void onCreate(Bundle savedInstanceState) {
 super.onCreate(savedInstanceState);
 setContentView(R.layout.activity_main);
 ButterKnife.bind(this);
 manager = getSupportFragmentManager();
 if (savedInstanceState == null) {
  Log.e(TAG, "onSaveInstanceState: 恢复相关状态!!");
  fragmentsUtil.loadRoot(R.id.fragment_container, Fragment9.newInstance());
 }
}

所以说呢, savedInstanceState 还是不能忽略的。不过到这里就以为完了的话就太低估 Fragment 的坑了, 如果你的 support-library 是低于24的,那么即使判断了 savedInstanceState 再去创建但是也有可能出现重叠的情况!

这里要说说 FragmentState 这个类,它是用来保存 Fragment 的相关状态的。

发现情况没??在之前的 FragmentState 中并没有保存 mHidden 的状态!

另外也搜索到了 相关Issue提交 ,但是在 Android 的 Revision-History 中并没有看到提及的相关bug修复。所以具体什么时候正式加了 mHidden 的字段也就没有考证出来了。

聊了这么多,最后说说解决方案呗,其实原理很简单,既然它没有自动保存,那么我们就在保存状态的时候手动把 mHidden 状态保存,在初始化的时候根据保存的 mHidden 状态手动显示或者隐藏。

@Override
public void onSaveInstanceState(Bundle outState) {
 //手动保存
 outState.putBoolean(ARG_IS_HIDDEN, isHidden());
 super.onSaveInstanceState(outState);
}
 //onCreate的时候调用
public void initFragments(Bundle savedInstanceState, BaseFragment fragment) {
 if (savedInstanceState == null) {
  return;
 }
 boolean isSupportHidden = savedInstanceState.getBoolean(ARG_IS_HIDDEN);

 FragmentTransaction ft = manager.beginTransaction();
 if (isSupportHidden) {
  ft.hide(fragment);
 } else {
  ft.show(fragment);
 }
 ft.commit();
}

最后封装了一个简单的工具类和 BaseFragment , 用于处理 Fragment 相关的事务的。

总结

以上就是这篇文章的全部内容了,希望本文的内容对各位Android开发者们能有所帮助,如果有疑问大家可以留言交流。

加载全部内容

相关教程
猜你喜欢
用户评论