Android实战技巧：Fragment的那些坑（转）

 

原文地址：http://toughcoder.net/blog/2015/04/30/android-fragment-the-bad-parts/?utm_source=tuicool&utm_medium=referral

Fragment是Android在3.0（Homeycomb)版本时加入的用以更灵活的构建多屏幕界面的可UI组件。关于Fragment以基本使用方法能够参考官方的教程和最佳实践，以及选择Activity仍是Fragment。 可是Fragment使用起来却远没有教程中说的那样简单，也远比Activity要复杂一些，这里总结了孤在使用Fragment时所遇到的坑。

嵌套Fragment时Duplicated id或者Tag之痒

这是一个小坑，可是初学者很容易遇到，特别是在Fragment之中套有Fragment时，且又是布局中添加子Fragment时更容易遇到。

现象：

Fragment中套有另外一个Fragment，当第二次进入父Fragment时或者由Fragment建立的界面时会抛异常，大体意思是子Fragment的Id或Tag重复了。若是你在layout中给子fragment加了id或者tag，那么必定会遇到此异常。

缘由：

在添加Fragment时均可觉得Fragment指定一个Id或者Tag用以标识这个Fragment。由于每一个Activity所附带的Fragment都是放在一个对象池中，在Activity的生命周期里，Fragment仍然在池中，即便是把某一个Fragment从Activity中detach掉（也即用FragmentManager pop掉），这个池是由FragmentManager来管理的。当你再次要以某个id或者Tag添加Fragment时，FragmentManager会在池中检索，若是发现已经存在Fragment对象带有此Id或者Tag时，就会抛此异常并报怨Id重复。这么作的目的就是减小对象的建立，尽能够的复用对象。

如何破解：

1. 在布局中写fragment时，不要添加id或者tag；

2. 若是非要添加id或者tag，就在代码中添加fragment，如使用Id或者Tag时，先到FragmentManager中查找对象是否存在，不存在时再建立，也即：

   Fragment target = getFragmentManager().findFragmentByTag("tag");
     if (target == null) {
         targe = new SomeFragment();
     }
     FragmentTransaction ft = getFragmentManager().beginTransaction();
     ft.add(R.id.content, target, "tag");
     ft.commit();

replace之痛

现象：

当有二个相同的总体页面层叠时，想把最后一个布局中的某个用Fragment来replace，会发现，它把前面的replace，后面的没效果。

缘由：

布局的Id在一个窗体（Activity)中是惟一的，Fragment的replace也是使用此惟一的Id来把相应布局替换成Fragment的。当相同的页面层叠时，同一个Id的布局出现了二次，但Id是同样的。因此FragmentTransaction在replace时仅替换了一个。而不会像期待的那样，替换最后一个页面。

如何破解：

若是相同的页面非要层叠，要么不使用Fragment，要么为布局设置不一样的Id。这种状况多出如今布局的复用上面，好比某二个页面长的像，因此复用了同一总体布局。但实际的逻辑上不是相同的页面，彻底能够为布局设置不一样的Id。

可见性之疼

现象：

当有多个Fragment层叠在一块儿时，每一个Fragment如何能感知其对用户的可见性。好比应用有三个页面，A，B和C，好比A是总体类别列表，B是每一个类别的详情，C又是类别的某种更详细的信息，当C显示出来时，A和B怎么能知道它其实对于用户已经不可见了，因此就能够不刷新，不加载数据等等。当C被用户BACK后，B又如何感受它变成可见了？

缘由：

Fragment的生命周期与Activity是同样的，添加到Activity会把OnCreate相似的回调走一遍，而后，Activity onResume/onPause/onstart/onStop时，其所持有的Fragment也走相应的onResume/onPause/onstart/onPause。可是Fragment与Activity很是不一样的是，Activity当有另外一个Activity显示时，当前的Activity会走onPause/onStop，而Fragment则彻底没有感知。最多只能从FragmentManager那里知道BackStackState改变了，可是是Fragment增长了，仍是减小了，并不能知道。

如何破解：

这个一个很是使人蛋疼的问题，简单的页面还好，可是涉及到数据加载或者要针对某些事件（网络）刷新时就有问题了，对用户不可见的页面不必刷新。可行的解法就是：

1. 监听FragmentManager的BackStackState的改变
2. 定义页面路径深度而后与BackStack深度比较，以感知是否对用户可见 如前面A是一级，其path为1，B是2，C是3。当前Stack深度为3时，C是可见的，A与B不可见，以此类推。

空白区域的点击之脓

现象:

一个Fragment，层叠在另一个Fragment或者Activity之上，此Fragment中有一些空白区域，也即Widget以外的空白区域，当点击这些空白区域的时候发现这个Fragment下面的Fragment或者Activity中的View收到了事件而且响应了点击事件。

缘由：

Fragment的本质就是一个View布局的管理器，当Fragment attach到Activity时，其实就是把Fragment#onCreateView()返回的View，替换掉(若是是用replace)FragmentTransaction#replace中指定的View，或者添加到(若是是add)FragmentTransaction#add()中指定的ViewGroup里面。

当咱们以层叠方式显示多个Fragment时，一般的作法就是弄一个FrameLayout，而后每次把Fragment add到此布局。所以，这时Activity的页面布局树实际上就是一个FrameLayout里面包含几个View。

因此，当点击上面Fragment的空白区域时，若是事件没被吃掉，就会向下传递。

如何破解：

在Fragment的根布局加上一个clickable=true，这会让根布局把点击事件吃掉，以防止事件会继续传递下去，形成上面的状况。

Activity从新建立之殇

现象：

这个没有通常性的错误，只会有与项目相关的具体的错误异常，或者页面显示不正确。以及为何教程中都有这么一句：

1 2 3 4 5 6

@Override onCreate(Bundle savedInstance) { if (savedIntance == null) { // create fragment and add it to Activity. } }

缘由：

Activity除了正常启动走到onCreate，还有另外的入口，好比系统配置信息发生变化时，或者Activity在栈比较深的地方，系统会把Activity杀掉，而后再从新建立它，问题就是在这个从新建立。从新建立与新建一个Activity不一样，它是要尽量的恢复先前所在的状态，由于这对用户来讲是透明的，也就是说不能让用户感知到，不然体验会至关差。惟一与常规建立的区别就在于传给onCreate的参数savedInstanceState是否是null.

如何破解：

为了能在Activity重建时恢复状态，须要：

1. 对于Activity

   要在onSaveInstanceState()时，把一些变量保存，而后在onCreate时恢复

2. 对于Fragment

   告诉系统，你想恢复状态Fragment#setRetainInstance(true)。而后，也在onSavedInstance()中保存状态，在onCreate时恢复。 这就够了，系统会在从新建立Activity时把其所持有的Fragment也建立出来。因此为何每一个Fragment子类都须要定义一个默认的Constructor。更多的能够参考这篇文章。

FragmentTransaction的异步操做之殇

FragmentTransaction是异步的，commit()仅是至关于把操做加入到FragmentManager的队列，而后FragmentManager会在某一个时刻来执行，并非当即执行。因此，真正开始执行commit()时，若是Activity的生命周期发生了变化，好比走到了onPause，或者走到了onStop，或者onDestroy都走完了，那么就会报出IllegalStateException。

还有一个异步的缘由就是，在异步中操做（显示）Fragment。好比，先去网络请求数据，而后根据数据显示一个Fragment，这个特别容易出现的状况是网络请求回来了，可是Activity已经不在了，这时若是commit也会报出IllegalStateException。

具体的缘由，以及如何避免能够参考大牛的这篇文章。

常见的解法就是做者建议的：1. 当心在生命周期中commit 。2 尽可能不要在异步回调中commit 另外的解法 就是

• 在异步回调中判断Activity是否在销毁中，isFinishing，若是true，就中止作其余事情

• 尽量把异步任务控制在活动的生命周期内（onStart->onStop）。当出现stop时终止异步任务。再次start时再次启动。

  可是这个并不适用全部状况。好比按HOME的状况，一般这个过程不须要把任务停掉。由于通常状况下，再切回来时，应用应该保持切走时的状态，好比，加载一个数据，按HOME切走，再回来时，应该加载完成。这也正是多任务系统的一个表现。 若是onstop时停掉任务，那么要作不少工做来在onstart时恢复状态。

• 使用commitAllowStateLoss（） 这个是最终方案。除了从设计 上避免之外，这是惟 一的方式。

恶心的Activity重建以及恢复其Fragment

首先说安卓系统很是恶心的一点就是某些状况下系统会杀掉Activity，而后从新建立并尝试恢复其先前的状态，好比当旋转屏幕时，当系统语言发生变化时，当栈中的Activity被回收了，又到栈顶时等等，这点很是恶心，经常带来问题。识别重建与新建的方法就是看onCreate中的Bundle参数是否是null。

对于FragmentActivity，更加恶心，此种场景时，它在onSaveInstance时会保存Fragment，而后在onCreate时会从新建立，会调用Framgment的默认无参构造来建立Fragment对象。因此这也是为何文档中说Fragment必定要有一个默认的构造函数，并且最好不要有带参数的构造函数，传参数要用setArguments。默认构造函数的缘由是为了重建Fragment实例。setArguments的参数是一个Bundle也会跟随Fragment保存起来，在重建Fragment时会帮你恢复。这里的恢复状态的数据的保存都是经过Binder方式保存在系统中，这也说明为啥参数非要是一个Bundle。

那么问题来了，当你确实须要带参数的构造函数，或者说系统没法帮你重建Fragment（好比Fragment要从动态加载的Dex中获取）时怎么办呢？

首先，咱们要模拟这一场景，最方便的就是把activity的configChanges去掉，而后旋转屏幕。

一个思路就是阻止系统恢复Fragment，咱们能够本身来加载，由于重建也会走到Activity的onCreate，因此咱们有理由重走一遍初始化流程。怎么阻止呢，就是在FragmentActivity保存全部Fragment状态前把Fragment从FragmentManager中移除掉。

1 2 3 4 5 6 7

@Override public void onSaveInstance(Bundle out) { FragmentTransaction ft = getSupportFragmentManager().benginTransaction(); ft.remove(frag); ft.commitAllowStateLoss(); super.onSaveInstance(out); }