Fragment全面解析

生命周期

图1：

图2：

Fragment必须是依存于Activity而存在的，因此Activity的生命周期会直接影响到Fragment的生命周期，并且Fragment的生命周期和Activity的生命周期很相似。

onAttach()

onAttach()将在Fragment与其Activity关联之后调用。需要使用Activity作为其他操作的上下文，将在此回调方法中实现。

onCreate(Bundle savedInstanceState)

当Fragment的onCreate()回调时，该Fragment还没有获得Activity的onCreate()已完成的通知，所以不能将依赖于Activity视图层次结构存在性的代码放入此回调方法中。在onCreate()回调方法中，我们应该尽量避免耗时操作。

但可以通过getArguments()获得setArguments()设置的Bundle参数。

• 注意：只有在Fragment添加到Activity之前可以调用setArguments()来给Fragment设置参数。

onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState)

创建该Fragment的视图。

• 注意：不要将视图层次结构附加到传入的ViewGroup父元素中，该关联会自动完成。如果在此回调中将Fragment的视图层次结构附加到父元素，很可能会出现异常。这句话什么意思呢？就是不要把初始化的view视图主动添加到container里面，因为系统会自动完成关联，所以inflate函数的第三个参数必须填false，而且不能出现container.addView(v)的操作。

onActivityCreated()

onActivityCreated()会在Activity完成其onCreate()回调之后调用。

在调用onActivityCreated()之前，Activity的视图层次结构已经准备好了，这是在用户看到界面之前你可对界面进行最后调整的地方。

onStart()，onResume()，onPause()，onStop()

它们与Activity的回调方法进行绑定，也就是说与Activity中的生命周期相对应，这里不做过多介绍。

onDestroyView()

与onCreateView()相对应，当该Fragment的视图被移除时调用。

onDestroy()

不再使用Fragment时调用。

• 注意：Fragment仍然附加在Activity，也可以被找到，但是不能执行其他操作。

onDetach()

与onAttach()相对应，Fragment与Activity解除绑定，释放资源。

创建实例

像普通的类一样，Fragment 拥有自己的构造函数，于是我们可以像下面这样在 Activity 中创建 Fragment 实例：

MainFragment mainFragment = new MainFragment();

如果需要在创建 Fragment 实例时传递参数进行初始化的话，可以创建一个带参数的构造函数，并初始化 Fragment 成员变量等。这样做，看似没有问题，但在一些特殊状况下还是有问题的。

我们知道，Activity 在一些特殊状况下会发生 destroy 并重新 create 的情形，比如屏幕旋转、内存吃紧时；对应的，依附于 Activity 存在的 Fragment 也会发生类似的状况。而一旦重新 create 时，Fragment 便会调用默认的无参构造函数，导致无法执行有参构造函数进行初始化工作：

     * Default constructor.  <strong>Every</strong> fragment must have an
     * empty constructor, so it can be instantiated when restoring its
     * activity's state.  It is strongly recommended that subclasses do not
     * have other constructors with parameters, since these constructors
     * will not be called when the fragment is re-instantiated; instead,
     * arguments can be supplied by the caller with {@link #setArguments}
     * and later retrieved by the Fragment with {@link #getArguments}.

好在Fragment提供了相应的 API setArguments()帮助我们解决这个问题。利用Bundle传递数据，参考代码如下：

public static OneFragment newInstance(int args){
    OneFragment oneFragment = new OneFragment();
    Bundle bundle = new Bundle();
    bundle.putInt("someArgs", args);
    oneFragment.setArguments(bundle);
    return oneFragment;
}

@Override
public void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    Bundle bundle = getArguments();
    int args = bundle.getInt("someArgs");
}

嵌入方式

Activity 嵌入 Fragment 分为布局静态嵌入和代码动态嵌入两种。前者在 Activity 的 Layout 布局中使用 < fragment > 标签嵌入指定 Fragment，如：

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">
    <fragment
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        class="com.yifeng.samples.OneFragment"/>
</LinearLayout>

后者在 Activity 的 Java 代码中借助管理器类 FragmentManager 和 事务类 FragmentTransaction 提供的 replace() 方法替换 Activity 的 Layout 中的相应容器布局，如：

FragmentManager fm = getFragmentManager();
FragmentTransaction ft = fm.beginTransaction();
ft.replace(R.id.fl_content, OneFragment.newInstance());
ft.commit();

这两种嵌入方式对应的 Fragment 生命周期略有不同。相比布局静态嵌入方式，代码动态嵌入方式更为常用，毕竟后者能够实现灵活控制多个 Fragment，动态改变 Activity 中的内容。

获取Fragment的管理器

getFragmentManager() ，当然我们一般不使用它。

我们使用的Fragment一般都是v4包下的，所以应该使用getSupportFragmentManager()。

然而有时候，我们会在 Fragment 里面继续嵌套二级甚至三级 Fragment，即 Activity 嵌套多级 Fragment。此时在 Fragment 里管理子 Fragment 时，也需要使用到 FragmentManager。但是一定要使用 getChildFragmentManager() 方法获取 FragmentManager 对象！

从官方文档注释上也可以看出这两个方法获取到的 FragmentManager 对象的区别：

Activity：getFragmentManager() 

Return the FragmentManager for interacting with fragments associated with this activity.

Fragment：getChildFragmentManager()

Return a private FragmentManager for placing and managing Fragments inside of this Fragment.

操作Fragment

Fragment 的动态添加、删除等操作都需要借助于 FragmentTransaction 类来完成，比如上面提到的 replace() 操作等。

add()

添加 Fragment 到 Activity 界面中。

remove()

移除 Activity 中指定的 Fragment。

replace()

通过内部调用 remove() 和 add() 完成 Fragment 的修改。

hide() 和 show()

隐藏和显示Activity中的Fragment。

• 补充：hide()和show()的时候会回调onHiddenChanged()，而创建Fragment的时候不会回调onHiddenChanged()。

addToBackStack()

添加当前事务到回退栈中，即当按下返回键时，界面回归到当前事物状态。

commit()

提交事务，所有通过上述方法对 Fragment 的改动都必须通过调用 commit() 方法完成提交。

所以操作流程是这样的：

FragmentManager fm = getFragmentManager();
//开启事物
FragmentTransaction ft = fm.beginTransaction();

//其中夹杂一系列操作,比如add(),remove()
……

//提交事物
ft.commit();

• 注意：动态切换显示 Activity 中的多个 Fragment 时，可以通过 replace() 实现，也可以 hide() 和 show() 方法实现。事实上，我们更倾向于使用后者，因为 replace() 方法不会保留 Fragment 的状态，也就是说诸如 EditText 内容输入等用户操作在 remove() 时会消失。当然，如果你不想保留用户操作的话，可以选择前者，视情况而定。

BackStack（回退栈）

在移除片段的事务执行期间通过调用 addToBackStack() 显式请求保存实例时，系统才会将片段放入由宿主 Activity 管理的返回栈。

当用户按下返回键时，如果回退栈中保存有之前的事务，便会执行事务回退，而不是 finish 掉当前 Activity。

举个例子，比如 App 中有一个新用户注册功能，包括设置用户名、密码、手机号等等流程，设计师在 UI 设计上将每个流程单独设计成一个界面，引导用户一步步操作。作为开发人员，如果将每一个完善信息的流程单独设置成一个 Activity 的话操作起来就比较繁琐，并且也不易于应用里的逻辑处理，而如果使用 Fragment 并结合回退栈的话，就非常合适了。

将每一个设置的流程写成一个 Fragment，通过状态控制显示不同的 Fragment，并利用回退栈实现返回上一步操作的功能。比如从 FirstStepFragment 进入 SecondStepFragment 时，比如可以在 LoginActivity.java 中这样操作：

FragmentManager fm = getSupportFragmentManager();
FragmentTransaction ft = fm.beginTransaction();
ft.hide(firstStepFragment);
if (secondStepFragment==null){
    ft.add(R.id.fl_content, secondStepFragment);
}else {
    ft.show(secondStepFragment);
}
ft.addToBackStack(null);
ft.commit();

• 注意：这里使用了 hide() 方法，而不是 replace() 方法，因为我们当然希望用户返回上一步操作时，之前设置的内容不会消失。

通信方式

通常，Fragment 与 Activity 通信存在三种情形：

• Activity 操作内嵌的 Fragment

• Fragment 操作宿主 Activity

• Fragment 操作同属 Activity中的其他 Fragment。

由于 Activity 持有所有内嵌的 Fragment 对象实例（创建实例时保存的 Fragment 对象，或者通过 FragmentManager 类提供的 findFragmentById() 和 findFragmentByTag() 方法也能获取到 Fragment 对象），所以可以直接操作 Fragment。

Fragment 通过 getActivity() 方法可以获取到宿主 Activity 对象（强制转换类型即可），进而可以操作宿主 Activity；那么很自然的，获取到宿主 Activity 对象的 Fragment 便可以操作其他 Fragment 对象。

虽然上述操作已经能够解决 Activity 与 Fragment 的通信问题，但会造成代码逻辑紊乱的结果，极度不符合这一编程思想：高内聚，低耦合。Fragment 做好自己的事情即可，所有涉及到 Fragment 之间的控制显示等操作，都应交由宿主 Activity 来统一管理。

所以强烈推荐，使用对外开放接口的形式将 Fragment 的一些对外操作传递给宿主 Activity。具体实现方式如下：

public class OneFragment extends Fragment implements View.OnClickListener{
    public interface IOneFragmentClickListener{
        void onOneFragmentClick();
    }

    @Nullable
    @Override
    public View onCreateView(LayoutInflater inflater, @Nullable ViewGroup container, @Nullable Bundle savedInstanceState) {
        View contentView = inflater.inflate(R.layout.fragment_one, null);
        contentView.findViewById(R.id.edt_one).setOnClickListener(this);
        return contentView;
    }

    @Override
    public void onClick(View v) {
        if (getActivity() instanceof IOneFragmentClickListener){
             ((IOneFragmentClickListener) getActivity()).onOneFragmentClick();
        }
    }
}

只要在宿主 Activity 实现 Fragment 定义的对外接口 IOneFragmentClickListener，便可以实现 Fragment 调用 Activity 的功能。

当然，你可以这样做：

public class OneFragment extends Fragment implements View.OnClickListener{

    private IOneFragmentClickListener clickListener;

    public interface IOneFragmentClickListener{
        void onOneFragmentClick();

    public void setClickListener(IOneFragmentClickListener clickListener) {
        this.clickListener = clickListener;
    }

    @Nullable
    @Override
    public View onCreateView(LayoutInflater inflater, @Nullable ViewGroup container, @Nullable Bundle savedInstanceState) {
        View contentView = inflater.inflate(R.layout.fragment_one, null);
        contentView.findViewById(R.id.edt_one).setOnClickListener(this);
        return contentView;
    }

    @Override
    public void onClick(View v) {
        clickListener.onOneFragmentClick();
    }
}

原理是一样的，只是相比第一种方式，需要在宿主 Activity 中额外添加一步监听设置：

oneFragment.setClickListener(this);

Fragment 重叠问题

原因

前面我们介绍 Fragment 初始化时提到 Activity 销毁重建的问题，试想一下，当 Activity 重新执行 onCreate() 方法时，是不是会再次执行 Fragment 的创建和显示等操作呢？而之前已经存在的 Fragment 实例也会销毁再次创建，这不就与 Activity 中 onCreate() 方法里面第二次创建的 Fragment 同时显示从而发生 UI 重叠的问题了吗？

根据经验，通常我们会在 AndroidManifest 里将 Activity 设置为横屏模式，所以不会由于屏幕旋转导致这种问题的出现。一种比较多的出现方式是，应用长时间处于后台，但由于设备内存吃紧，导致 Activity 被销毁，而当用户再次打开应用时便会发生 Fragment 重叠的问题。但是这种问题在开发阶段由于应用的频繁使用导致我们很难遇见，但确确实实存在着。所以开发过程中，一定要注意这类问题。

解决方案

知道问题的根源所在之后，对应的解决方案也就有啦。就是在 Activity 中创建 Fragment 实例时，添加一个判断即可，处理方式有三种：

在 Activity 提供的 onAttachFragment() 方法中处理：

@Override
public void onAttachFragment(Fragment fragment) {
    super.onAttachFragment(fragment);
    if (fragment instanceof  OneFragment){
        oneFragment = (OneFragment) fragment;
    }
}

在创建 Fragment 前添加判断，判断是否已经存在：

ragment tempFragment = getSupportFragmentManager().findFragmentByTag("OneFragment");
if (tempFragment==null) {
    oneFragment = OneFragment.newInstance();
    ft.add(R.id.fl_content, oneFragment, "OneFragment");
}else {
    oneFragment = (OneFragment) tempFragment;
}

更为简单，直接利用Activity的onCreate()中的Bundle参数savedInstanceState判断即可：

if (savedInstanceState==null) {
    oneFragment = OneFragment.newInstance();
    ft.add(R.id.fl_content, oneFragment, "OneFragment");
}else {
    oneFragment = (OneFragment) getSupportFragmentManager().findFragmentByTag("OneFragment");
}

getActivity()引用问题

使用中，经常会在 Fragment 中通过 getActivity() 获取到宿主 Activity 对象，但稍有不慎便会引发下面这两个问题：

Activity 的实例销毁问题

比如，Fragment 中存在类似网络请求之类的异步耗时任务，当该任务执行完毕回调 Fragment 的方法并用到宿主 Activity 对象时，很有可能宿主 Activity 对象已经销毁，从而引发 NullPointException 等异常，甚至造成程序崩溃。

所以，异步回调时需要注意添加空值等判断（譬如：fragment.isAdd()，getActivity()!＝null 等），或者在 Fragment 创建实例时就通过 getActivity().getApplicationContext() 方法保存整个应用的上下文对象，再来使用。

内存泄漏问题

如果 Fragment 持有宿主 Activity 的引用，会导致宿主 Activity 无法回收，造成内存泄漏。所以，如果可以的话，尽量不要在 Fragment 中持有宿主 Activity 的引用。

onActivityResult()

Fragment 类提供有 startActivityForResult() 方法用于 Activity 间的页面跳转和数据回传，其实内部也是调用 Activity 的对应方法。但是在页面返回时需要注意 Fragment 没有提供 setResult() 方法，可以通过宿主 Activity 实现。

举个例子，在 ActivityA 中的 FragmentA 里面调用 startActivityForResult() 跳转至 ActivityB 中，并在 ActivityB 中的 FragmentB 里面返回到 ActivityA，返回代码如下：

Intent intent = new Intent();
// putExtra
getActivity().setResult(Activity.RESULT_OK, intent);
getActivity().finish();

在回调时，先会回调 ActivityA 中的 onActivityResult() 方法，然后再分发回调 FragmentA 中的 onActivityResult() 方法，从 FragmentActivity 类的源码中可以看出：

/**
* Dispatch incoming result to the correct fragment.
*/
@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
    mFragments.noteStateNotSaved();
    int requestIndex = requestCode>>16;
    if (requestIndex != 0) {
        requestIndex--;
        String who = mPendingFragmentActivityResults.get(requestIndex);
        mPendingFragmentActivityResults.remove(requestIndex);
        if (who == null) {
            Log.w(TAG, "Activity result delivered for unknown Fragment.");
            return;
        }
        Fragment targetFragment = mFragments.findFragmentByWho(who);
        if (targetFragment == null) {
            Log.w(TAG, "Activity result no fragment exists for who: " + who);
        } else {
            targetFragment.onActivityResult(requestCode & 0xffff, resultCode, data);
        }
        return;
    }
    super.onActivityResult(requestCode, resultCode, data);
}

再拓展一下，如果 FragmentA 中又嵌入一层 FragmentAA ，然后从 FragmentAA 中跳转至 ActivityB，那么在 FragmentAA 中的 onActivityResult() 方法中能收到回调吗？显然不能。从上述源码中可以看出 FragmentActivity 只进行到一级分发。所以，如果想实现多级分发，就得自己在各级 Fragment 中手动添加分发代码，至下一级 Fragment 中。

未必靠谱的出栈方法remove()

如果你想让某一个Fragment出栈，使用remove()在加入回退栈时并不靠谱。

如果你在add()的同时将Fragment加入回退栈：addToBackStack(name)的情况下，它并不能真正将Fragment从栈内移除。

如果你在2秒后（确保Fragment事务已经完成）打印getSupportFragmentManager().getFragments()，会发现该Fragment依然存在，并且依然可以返回到被remove的Fragment，而且是空白页面。

这类似于Activity销毁了，但是没有finish()。

如果你没有将Fragment加入回退栈，remove()可以正常出栈。

ViewPager中Fragment的生命周期

关于ViewPager中Fragment的生命周期，请看这篇文章ViewPager中Fragment的生命周期。

分析到这里就结束了，总结的其实不够详尽，有待补充。

参考：
1.Android Fragment 真正的完全解析（上）
2.Android Fragment 真正的完全解析（下）
3.Android Fragment 的使用，一些你不可不知的注意事项
4.Activity与Fragment生命周期探讨
5.Fragment全解析系列（一）：那些年踩过的坑
6.谷歌官方文档–Fragment