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重复。这么做的目的就是减少对象的创建，尽可以的复用对象。
如何破解：
. 在布局中写fragment时，不要添加id或者tag；
. 如果非要添加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增加了，还是减少了，并不能知道。
如何破解：
这个一个非常令人蛋疼的问题，简单的页面还好，但是涉及到数据加载或者要针对某些事件（网络）刷新时就有问题了，对用户不可见的页面没必要刷新。可行的解法就是：
. 监听FragmentManager的BackStackState的改变
. 定义页面路径深度然后与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重新创建之殇
现象：
这个没有一般性的错误，只会有与项目相关的具体的错误异常，或者页面显示不正确。以及为什么教程中都有这么一句：
@OverrideonCreate(Bundle savedInstance) { if (savedIntance == null) { // create fragment and add it to Activity. }}原因：
Activity除了正常启动走到onCreate，还有另外的入口，比如系统配置信息发生变化时，或者Activity在栈比较深的地方，系统会把Activity杀掉，然后再 重新创建 它，问题就是在这个重新创建。重新创建与新建一个Activity不同，它是要尽可能的恢复先前所在的状态，因为这对用户来说是透明的，也就是说不能让用户感知到，否则体验会相当差。唯一与常规创建的区别就在于传给onCreate的参数savedInstanceState是不是null.
如何破解：
为了能在Activity重建时恢复状态，需要：
. 对于Activity
要在onSaveInstanceState()时，把一些变量保存，然后在onCreate时恢复
. 对于Fragment
告诉系统，你想恢复状态Fragment#setRetainInstance(true)。然后，也在onSavedInstance()中保存状态，在onCreate时恢复。 这就够了，系统会在重新创建Activity时把其所持有的Fragment也创建出来。所以为什么每个Fragment子类都需要定义一个默认的Constructor。更多的可以参考 这篇文章 。
FragmentTransaction的异步操作之殇
FragmentTransaction是异步的，commit()仅是相当于把操作加入到FragmentManager的队列，然后FragmentManager会在某一个时刻来执行，并不是立即执行。所以，真正开始执行commit()时，如果Activity的生命周期发生了变化，比如走到了onPause，或者走到了onStop，或者onDestroy都走完了，那么就会报出IllegalStateException。
随时随地看视频
