关于Fragment重叠异常的问题

本文内容参考来源于：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();