状态方法对比
- onAttach()
作用：fragment已经关联到activity，这个时候 activity已经传进来了， 获得activity的传递的值 就可以进行 与activity的通信里， 当然也可以使用getActivity(),前提是这个fragment已经和宿主的activity关联，并且没有脱离，有且只有调用一次。 - onCreate()
系统创建fragment的时候回调他，在他里面实例化一些变量,这些个变量主要是：当你暂停、停止的时候 你想保持的数据、他只调用一次。 - onCreateView()
第一次使用的时候 fragment会在这上面画一个layout出来， 为了可以画控件 要返回一个 布局的view，也可以返回null 就什么都没有显示。
当系统用到fragment的时候 fragment就要返回他的view，越快越好 ，所以尽量在这里不要做耗时操作，比如从数据库加载大量数据 - onActivityCreated()
当Activity中的onCreate方法执行完后调用。当执行onActivityCreated()的时候 activity的onCreate才刚完成。所以在onActivityCreated()调用之前activity的onCreate可能还没有完成，所以不能再onCreateView()中进行与activity有交互的UI操作，UI交互操作可以在onActivityCreated()里面进行。所以呢，这个方法主要是初始化那些你需要你的父Activity或者Fragment的UI已经被完整初始化才能初始化的元素。 - onStart()
和activity一致，启动Fragement 启动时回调,，此时Fragement可见。 - onResume()
和activity一致 在activity中运行是可见的。激活, Fragement 进入前台, 可获取焦点时激活。 - onPause()
和activity一致 其他的activity获得焦点，这个仍然可见第一次调用的时候，指的是 用户 离开这个fragment（并不是被销毁）
通常用于 用户的提交（可能用户离开后不会回来了） - onStop()
和activity一致， fragment不可见的， 可能情况：activity被stopped了或者 fragment被移除但被，加入到回退栈中，一个stopped的fragment仍然是活着的如果长时间不用也会被移除。 - onDestroyView()
Fragment中的布局被移除时调用。表示fragemnt销毁相关联的UI布局， 清除所有跟视图相关的资源。然后这个知识移除视图 并没有销毁而且还没有脱离activity - onDestroy()
销毁fragment对象， 跟activity类似了。 - onDetach()
Fragment和Activity解除关联的时候调用。 脱离activity。
Activity
优点
作为四大组件之一，是唯一用户可见的组件，是程序入口
使用方便，事件逻辑处理方便，生命周期简单明了，不同activity实例间声明周期互相独立，有系统提供的activityManager来创建和维护实例和栈
缺点
创建和各种状态依赖Frameworks操控
过于庞大和复杂
传递参数困难
注意事项
非必需则要声明configChagnes，至少添加orientation和keyboard以及keyboardHidden
减少activity实例的引用，
通过Intent传递参数时尽量，使用基本数据类型和ArrayList等，必须使用对象时则实现Parcelable接口
Fragment
优点
轻量级Activity，有Activity的部分功能，有生命周期、显示UI元素、逻辑控制等
可以动态创建和控制对象，创建实例，显示方式控制方便
模块化（Modularity）：我们不必把所有代码全部写在Activity中，而是把代码写在各自的Fragment中，以方便不同业务的UI可以分离出来。
可重用（Reusability）：多个Activity可以重用一个Fragment。
可适配（Adaptability）：根据硬件的屏幕尺寸、屏幕方向，能够方便地实现不同的布局，这样用户体验更好。
缺点
依赖activity，不可独立存在
注意事项
Fragment由FragmentManager来管理，每个Activity有一个FragmentManager，管理着一个Fragment的栈
Fragment实例由ID或TAG标识
Activity有一个Fragment池，实例不一定会被销毁，可能会被保存池中，缓存
FragmentManager的作用范围是整个Activity，所以某一个布局ID不能重复被Fragment替换，即同一个activity内不能有两个ID一样的Fragment，FM不认实例，认ID
Fragment的生命周期反映Activity的生命周期
即正在显示时，就跟Activity的一样，Activity被onPause，里面的Fragment就onPause
每个Fragment不知道自己是否真的对用户可见。比如现在是Fragment A，又在其上面显示了Fragment B，当B显示后，A并不知道自己上面还有一个，也不知道自己对用户不可见了
同样再有一个C，B也不知。C退出后，B依然不知自己已在栈顶，对用户可见，B退后，A也不知。也就是说Fragment显示或者退出，栈里的其他Fragment无法感知。
这点就不如Activity，a被b盖住后，a会走到onStop()，同样c显示后，b也能通过onStop()感知。
Fragment可以从FragmentManager监听BackStackState的变化，但它只告诉你Stack变了，不告诉你是多了，还是少，还有你处的位置。
有一个解决方案就是，记录页面的Path深度，再跟Fragment所在的Stack深度来比较，如果一致，那么这个Fragment就在栈顶。因为每个页面的Path深度是固定的，而Stack深度是不变化的，所以这个能准确的判断Fragment是否对用户可见，当然，这个仅针对整个页面有效，对于布局中的一个区域是无效的。
Fragment的事件传递，对于层叠的Fragment，其实就相当于在一个FrameLayout里面加上一堆的View，所以，如果处于顶层的Fragment没处理点击事件，那么事件就会向下层传递，直到事件被处理。比如有二个Fragment A和B，B在A上面，B只有一个简单的TextView且没处理事件，那么点击B时，会发现A里的View处理了事件。这个对于Activity也不会发生，因为事件不能跨窗体传播，上面的Activity没处理事件，也不会传给下面的Activity，即使它可见。
解决之法，就是让上面的Fragment的根布局吃掉事件，为每个根ViewGroup添加onClick=“true”。
与第三方Activity交互。与第三方交互，仍要采用Android的标准startActivityForResult()和onActivityResult()这二个方法来进行。
但对于Fragment有些事情需要注意，Fragment也有这二个方法，但是为了能正确的让Fragment收到onActivityResult()，需要：宿主Activity要实现一个空的onActivityResult()，里面调用super.onActivityResult()，调用Fragment#startActivityForResult()而不是用Activity的 当然，也可以直接使用Activity的startActivityForResult()，那样的话，就只能在宿主Activity里处理返回的结果了。