本文内容参考来源于:http://www.jianshu.com/p/d9143a92ad94
一、说明
在Activity中添加Fragment几乎是很多app都需要使用到的,原因就是Fragment可以在现有基础上使性能大幅度提高,并且占用内存降低,同样的界面Activity占用内存比Fragment要多,响应速度Fragment比Activty在中低端手机上快了很多,甚至能达到好几倍!如果你的app当前或以后有移植平板等平台时,可以让你节省大量时间和精力。但是Fragment本身就不是完美的,它存在很多的缺陷,今天要说的这个就是我在实际开发中遇到的一个问题,我在一个Activity中放置了三个Fragment,界面与QQ类似,下方是三个按钮用于切换三个Fragment的显示与隐藏,但是在系统内存等一些意外情况下,Fragment的显示居然重叠了,而且无论怎么切换重叠的Fragment就是不隐藏掉。于是乎,就不得不去网上找各类资料了,上方的参考源就是我觉得介绍的非常详细的一部分,当然为了便于记忆整理,我也抽取了中间重叠的一小部分记录下来。
二、原因
如果你add()
了几个Fragment,使用show()、hide()
方法控制,比如微信、QQ的底部tab等情景,如果你什么都不做的话,在“内存重启”后回到前台,app的这几个Fragment界面会重叠。
原因是FragmentManager帮我们管理Fragment,当发生“内存重启”,他会从栈底向栈顶的顺序一次性恢复Fragment;
但是因为没有保存Fragment的mHidden属性,默认为false,即show状态,所以所有Fragment都是以show的形式恢复,我们看到了界面重叠。
(如果是replace
,恢复形式和Activity一致,只有当你pop之后上一个Fragment才开始重新恢复,所有使用replace
不会造成重叠现象)
还有一种场景,add
和replace
都有可能造成重叠: 在onCreate
中加载Fragment,并且没有判断saveInstanceState==null
,导致重复加载了同一个Fragment导致重叠。(PS:replace
情况下,如果没有加入回退栈,则不判断也不会造成重叠,但建议还是统一判断下)
以上是作者原文提到的,我这里试了几种方法,觉得还是标准写法比较好,附上代码:
@Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity); TargetFragment targetFragment; HideFragment hideFragment; if (savedInstanceState != null) { // “内存重启”时调用 targetFragment = getSupportFragmentManager().findFragmentByTag(TargetFragment.class.getName); hideFragment = getSupportFragmentManager().findFragmentByTag(HideFragment.class.getName); // 解决重叠问题 getFragmentManager().beginTransaction() .show(targetFragment) .hide(hideFragment) .commit(); }else{ // 正常时 targetFragment = TargetFragment.newInstance(); hideFragment = HideFragment.newInstance(); getFragmentManager().beginTransaction() .add(R.id.container, targetFragment, targetFragment.getClass().getName()) .add(R.id,container,hideFragment,hideFragment.getClass().getName()) .hide(hideFragment) .commit(); } }
三、补充
标准写法显然是在onCreate的时候就初始化了Fragment并且添加到了FragmentManager,但是如果项目其他地方需要切换显示的话,一定要先判断fragment是否为null,如果不为null的情况下,再去调用getFragmentManager().beginTransaction().add(R.id.container, targetFragment, targetFragment.getClass().getName()).hide(hideFragment).commit();的话就会出现重复添加Fragment的错误,再有一次就是可以将最后的commit()方法替换成commitAllowingStateLoss(),至于原因,android源码中有提到:
/** * Schedules a commit of this transaction. The commit does * not happen immediately; it will be scheduled as work on the main thread * to be done the next time that thread is ready. * * <p class="note">A transaction can only be committed with this method * prior to its containing activity saving its state. If the commit is * attempted after that point, an exception will be thrown. This is * because the state after the commit can be lost if the activity needs to * be restored from its state. See {@link #commitAllowingStateLoss()} for * situations where it may be okay to lose the commit.</p> * * @return Returns the identifier of this transaction's back stack entry, * if {@link #addToBackStack(String)} had been called. Otherwise, returns * a negative number. */ public abstract int commit();