这个东西有顾名思义是碎片，和之前的Activity对应。
坑1：一般情况都会想当然的以为进程被杀掉之后，Fragment也会被回收
其实，Fragment有自己的生命周期，有自己的管理器（FragmentManager），也即：
包含Fragment的进程被干掉，Fragment不一定会被回收，而是由FragmentManager来决定生死。
Q：如何验证上面的说法？
A：如果是一般正常的流程“打开-关闭”软件，Fragment的确被回收了。但是如果使用“腾讯手机管家”之类的内存清理工具，清理内存（实际上是杀死进程），会发现Fragment没有被回收，一直缓存着。验证方法如下：缓存Fragment的Tag到本地数据库（可以是xml/sqlite等)，然后用FragmentManager.findFragmentByTag(...)是否为Null来验证Framgent是否被回收了。
有个奇怪的现状是：在上面蓝色的情况发生后，Framgent和包含他的Activity的生命周期顺序都乱套了，原本是：
Activity.onCreate-->Fragment.onCreate-->Fragment.onCreateView
变成：
Fragment.onCreate-->Activity.onCreate-->Fragment.onCreateView
猜测是因为直接用的Frament缓存，其onCreate先于父Activity.onCreate执行了。
坑2：添加Fragment注意事项，
配置（Configuration ）改变是Android应用生命周期的一部分，如果发生了该事件（屏幕从横屏换行为竖屏），就会导致Activity被销毁然后重新创建。就算您在配置文件中设定Activity为竖屏显示的 也无法避免，应为Android应用配置改变的情况有很多种。
如果发生了这种情况，Fragment也会被销毁然后重新创建。如果您是在运行时（在Java代码中添加Fragment到Activity，不是在Activity的布局文件中声明的）创建的，则需要额外小心：
当Activity第一次创建的时候，您需要添加Fragment；当由于配置条件改变导致Activity被重新创建则无需再次添加Fragment（系统会自动添加Fragment）。
所以问题来了，您如何知道何时应该在onCreate函数中添加Fragment呢？
判断的方法就是检查 savedInstanceState 参数，如果该参数为null说明是第一次创建，需要添加Fragment；如果不是null则无需添加。代码如下：
public class MyActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstnaceState); // Only add fragment if this is the initial Activity creation
if (savedInstanceState == null) {
FragmentManager fragmentManager =
getFragmentManager()
FragmentTransaction fragmentTransaction =
fragmentManager.beginTransaction();
ExampleFragment fragment = new ExampleFragment();
fragmentTransaction.add(R.id.fragment_container, fragment);
fragmentTransaction.commit();
} else { // Don't add the fragment!
// (and use savedInstanceState to restore Activity state)
}
}
}如果您没有按照上面的方式添加Fragment，则您的应用可能会出现一种奇怪的现象，同样的Fragment添加了多次。
hasty