LayoutInflater源码分析（三）fragment 标签的处理

发表于 | 更新于: | 分类于 ， | | 阅读次数: | 次
字数统计: 1.9k | 阅读时长 ≈ 8 分钟

前言

在上一篇LayoutInflater 源码分析（二）中分析了LayoutInflater对include以及merge标签的处理，但是并没有找到对fragment的处理痕迹。

本文将继续探索以求揭晓答案。

可能有同学不知道，在这里提一下fragment标签的使用方式： 

1
2
3
4
5
6
7
<fragment
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    class="me.yifeiyuan.MainFragment"
    android:tag="Main"
    android:id="@+id/main"
    />

这属于加载 Fragment 中的静态加载，在 XML 中写死了 class，缺乏灵活性，实际开发中并不常用，甚至已经淘汰了，所以不推荐使用。

不过这并不妨碍对它的原理探究。

分析思路

在第一篇分析中提到了 Factory 的 Hook 机制，代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
View view;
if (mFactory2 != null) {
    view = mFactory2.onCreateView(parent, name, context, attrs);
} else if (mFactory != null) {
    view = mFactory.onCreateView(name, context, attrs);
} else {
    view = null;
}
// mPrivateFactory 是个 FactoryMerger 
if (view == null && mPrivateFactory != null) {
    view = mPrivateFactory.onCreateView(parent, name, context, attrs);
}

为了便于理解那些个 Factory，特意大致的画了一张类图：

注意：前面代码中的mPrivateFactory 是个 FactoryMerger 对象。

可能看到这里还是会有些茫然，不过仔细一回想我们在使用 Fragment 的时候都会继承 FragmentActivity，所以去 FragmentActivity 寻找答案感觉比较靠谱。

接下去开始分析。

寻找踪迹之 FragmentActivity

查看了源码后发现，FragmentActivity 的继承结构如下

其实 Activity 就已经实现了 LayoutInflater.Factory2 接口，具体实现如下：

1
2
3
4
5
6
7
8
9
10
11
12
public View onCreateView(View parent, String name, Context context, AttributeSet attrs) {
    // 如果不是 fragment 则调用另一个onCreateView，而它返回的是 null
    if (!"fragment".equals(name)) {
        return onCreateView(name, context, attrs);
    }
    // 如果是 fragment 标签 则交给了 mFragments
    return mFragments.onCreateView(parent, name, context, attrs);
}

public View onCreateView(String name, Context context, AttributeSet attrs) {
    return null;
}

可以看到如果是 fragment 标签，则会交给一个叫 mFragments 的FragmentController类的对象。

但是需要注意的是：Activity 并没有调用 LayoutInflater.setFactory 使之生效，所以 Activity 并不支持 fragment 的解析。

继续看它的子类的实现。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
// Donut 好古老的版本啊~
abstract class BaseFragmentActivityDonut extends Activity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        if (Build.VERSION.SDK_INT < 11 && getLayoutInflater().getFactory() == null) {
            // On pre-HC devices we need to manually install ourselves as a Factory.
            // On HC and above, we are automatically installed as a private factory
            getLayoutInflater().setFactory(this);
        }
        super.onCreate(savedInstanceState);
    }
    //重写 onCreateView
    @Override
    public View onCreateView(String name, Context context, AttributeSet attrs) {
    	//　优先调用 dispatchFragmentsOnCreateView
        final View v = dispatchFragmentsOnCreateView(null, name, context, attrs);
        if (v == null) {
            return super.onCreateView(name, context, attrs);
        }
        return v;
    }

    abstract View dispatchFragmentsOnCreateView(View parent, String name,
            Context context, AttributeSet attrs);

}
// Honeycomb
abstract class BaseFragmentActivityHoneycomb extends BaseFragmentActivityDonut {
    @Override
    public View onCreateView(View parent, String name, Context context, AttributeSet attrs) {
        final View v = dispatchFragmentsOnCreateView(parent, name, context, attrs);
        if (v == null && Build.VERSION.SDK_INT >= 11) {
            // If we're running on HC or above, let the super have a go
            return super.onCreateView(parent, name, context, attrs);
        }
        return v;
    }

}
// FragmentActivity 并没有重写 onCreateView
public class FragmentActivity extends BaseFragmentActivityHoneycomb{
    @Override
    final View dispatchFragmentsOnCreateView(View parent, String name, Context context,
            AttributeSet attrs) {
        return mFragments.onCreateView(parent, name, context, attrs);
    }
}

可以看到，在BaseFragmentActivityDonut中调用了setFactory，并定义了一个dispatchFragmentsOnCreateView抽象方法，并在onCreateView里调用了它，这样就把创建 View 的工作交给了dispatchFragmentsOnCreateView。

接着，在 FragmentActivity 重写dispatchFragmentsOnCreateView，又把它交给了mFragments，咦，又回去了。

其实到这里已经可以知道，LayoutInflater把处理fragment的事情最终交给了FragmentManagerImpl。

而对于FragmentManagerImpl的分析其实已经超过了本文的界限。

但是我想再深入，看看Fragment的onCreateView方法究竟是什么时候调用的！！

所以继续跟下去：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
public View onCreateView(View parent, String name, Context context, AttributeSet attrs) {
    //mFragmentManager 是 FragmentManagerImpl 的实例
    return mHost.mFragmentManager.onCreateView(parent, name, context, attrs);
}

// #FragmentManagerImpl 
@Override
public View onCreateView(View parent, String name, Context context, AttributeSet attrs) {
    // 不为 fragment 直接 return null 说明确实只处理 fragment
    if (!"fragment".equals(name)) {
        return null;
    }
    // xml 中的 各种 属性 fname为 Fragemnt 的全路径
    String fname = attrs.getAttributeValue(null, "class");
    TypedArray a =  context.obtainStyledAttributes(attrs, FragmentTag.Fragment);
    if (fname == null) {
        fname = a.getString(FragmentTag.Fragment_name);
    }
    int id = a.getResourceId(FragmentTag.Fragment_id, View.NO_ID);
    String tag = a.getString(FragmentTag.Fragment_tag);
    a.recycle();

    if (!Fragment.isSupportFragmentClass(mHost.getContext(), fname)) {
        // Invalid support lib fragment; let the device's framework handle it.
        // This will allow android.app.Fragments to do the right thing.
        return null;
    }
    // 如果配置的信息不够 则会抛异常
    int containerId = parent != null ? parent.getId() : 0;
    if (containerId == View.NO_ID && id == View.NO_ID && tag == null) {
        throw new IllegalArgumentException(attrs.getPositionDescription()
                + ": Must specify unique android:id, android:tag, or have a parent with an id for " + fname);
    }

    // If we restored from a previous state, we may already have
    // instantiated this fragment from the state and should use
    // that instance instead of making a new one.
    // 尝试着先去找 fragment
    Fragment fragment = id != View.NO_ID ? findFragmentById(id) : null;
    if (fragment == null && tag != null) {
        fragment = findFragmentByTag(tag);
    }
    if (fragment == null && containerId != View.NO_ID) {
        fragment = findFragmentById(containerId);
    }

    if (FragmentManagerImpl.DEBUG) Log.v(TAG, "onCreateView: id=0x"
            + Integer.toHexString(id) + " fname=" + fname
            + " existing=" + fragment);
    // 如果没有 则去实例化
    if (fragment == null) {
    	// 调用 instantiate 其实也是反射来实例化的。
        fragment = Fragment.instantiate(context, fname);
        fragment.mFromLayout = true;
        fragment.mFragmentId = id != 0 ? id : containerId;
        fragment.mContainerId = containerId;
        fragment.mTag = tag;
        fragment.mInLayout = true;
        fragment.mFragmentManager = this;
        fragment.mHost = mHost;
        fragment.onInflate(mHost.getContext(), attrs, fragment.mSavedFragmentState);
        addFragment(fragment, true);

    } else if (fragment.mInLayout) {
        // A fragment already exists and it is not one we restored from
        // previous state.
        throw new IllegalArgumentException(attrs.getPositionDescription()
                + ": Duplicate id 0x" + Integer.toHexString(id)
                + ", tag " + tag + ", or parent id 0x" + Integer.toHexString(containerId)
                + " with another fragment for " + fname);
    } else {
        // This fragment was retained from a previous instance; get it
        // going now.
        fragment.mInLayout = true;
        fragment.mHost = mHost;
        // If this fragment is newly instantiated (either right now, or
        // from last saved state), then give it the attributes to
        // initialize itself.
        if (!fragment.mRetaining) {
            fragment.onInflate(mHost.getContext(), attrs, fragment.mSavedFragmentState);
        }
    }

    // If we haven't finished entering the CREATED state ourselves yet,
    // push the inflated child fragment along.
    if (mCurState < Fragment.CREATED && fragment.mFromLayout) {
        moveToState(fragment, Fragment.CREATED, 0, 0, false);
    } else {
        moveToState(fragment);
    }

    if (fragment.mView == null) {
        throw new IllegalStateException("Fragment " + fname
                + " did not create a view.");
    }
    if (id != 0) {
        fragment.mView.setId(id);
    }
    if (fragment.mView.getTag() == null) {
        fragment.mView.setTag(tag);
    }
    return fragment.mView;
}

可以看到，在处理 xml 中的属性后，会先去寻找要加载的 fragment 是否已经加载过了，如果没有则会调用fragment = Fragment.instantiate(context, fname);，这个方法也是
反射，这点其实跟 View 的处理是一样的。

接着会去调用moveToState方法，而这个方法里，我看了onCreateView方法的调用时机。

伪代码如下（太复杂，删减了绝大部分代码）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// # FragmentManager
void moveToState(Fragment f, int newState, int transit, int transitionStyle,boolean keepActive) {
	//...
	f.mView = f.performCreateView(xxx);
	//....
}
// 真正的调用时机在这里！！
// # Fragment
View performCreateView(LayoutInflater inflater, ViewGroup container,
        Bundle savedInstanceState) {
    if (mChildFragmentManager != null) {
        mChildFragmentManager.noteStateNotSaved();
    }
    // 调用onCreateView 熟悉吧？
    return onCreateView(inflater, container, savedInstanceState);
}

可以看到，FragmentManager的moveToState中会去调用Fragment的performCreateView方法，而它里面，调用了onCreateView！！

onCreateView熟悉吧？就是我们使用 Fragment 第一个重写的方法！

终于找到啦！！

呼，藏得真深。

不过功夫不负有心人！~~~

爽！~

小结

FragmentActivity通过 setFactory把对fragment标签的处理委托给了 FragmentManageImpl的onCreateView方法。

最终通过反射，实例化指定的 Fragment，并调用了Fragment.performCreateView，最后到我们所熟悉的onCreateView。

整体的流程分析完毕。

另外要说的是，LayoutInflater.Factory的作用其实非常强大，我们可以 Hook 每个 View 的创建于设置，比如 AppCompact库通过AppCompactViewInflater Hook 了大部分 View，给我们提供了向下兼容的功能；

另外它也还可以配合 DayNight 实现夜间模式功能，有兴趣可以去看看AppCompactActivity、AppCompactViewInflater等类，有机会再讲吧。

到此对于 LayoutInflater 的源码分析已经结束，在查看源码的过程中发现一枚彩蛋，下一篇分享。

推荐阅读

一步一步深入理解CoordinatorLayout
ViewStub是如何实现懒加载的
Space源码分析
LayoutInflater 源码分析（一）之 inflate 深度分析
LayoutInflater源码分析（二）之include以及merge标签的处理

程序亦非猿 wechat
都看到这里了，不关注下我的公众号吗？

热评文章