關於作者
郭孝星，程式設計師，吉他手，主要從事Android平臺基礎架構方面的工作，歡迎交流技術方面的問題，可以去我的Github提issue或者發郵件至guoxiaoxingse@163.com與我交流。
文章目錄
- 一 View樹解析
- 二 View解析
Instantiates a layout XML file into its corresponding {@link android.view.View}objects.
LayoutInflater可以把xml佈局檔案裡內容載入成一個View，LayoutInflater可以說是Android裡的無名英雄，你經常用的到它，卻體會不到它的好。因為隔壁的iOS兄弟是沒有 這種東西的，他們只能用程式碼來寫佈局，需要應用跑起來才能看到效果。相比之下Android的開發者就幸福的多，但是大家有沒有相關xml是如何轉換成一個View的，今天我們就來分析 這個問題。
LayoutInflater也是通過Context獲取，它也是系統服務的一種，被註冊在ContextImpl的map裡，然後通過LAYOUT_INFLATER_SERVICE來獲取。
layoutInflater = (LayoutInflater) context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
複製程式碼LayoutInflater是一個抽象類，它的實現類是PhoneLayoutInflater。LayoutInflater會採用深度優先遍歷自頂向下遍歷View樹，根據View的全路徑名利用反射獲取構造器 從而構建View的例項。整個邏輯還是很清晰的，我們來具體看一看。
我們先來看看總的排程方法inflate()，這個也是我們最常用的
public View inflate(@LayoutRes int resource, @Nullable ViewGroup root, boolean attachToRoot)
複製程式碼這個方法有三個引數：
int resource：佈局ID，也就是要解析的xml佈局檔案，boolean attachToRoot表示是否要新增到父佈局root中去。這裡面還有個關鍵的引數root。它用來表示根佈局，這個就很常見的，我們在用 這個方法的時候，有時候給root賦值了，有時候直接給了null（給null的時候IDE會有警告提示），這個root到底有什麼作用呢？?
它主要有兩個方面的作用：
- 當attachToRoot == true且root ！= null時，新解析出來的View會被add到root中去，然後將root作為結果返回。
- 當attachToRoot == false且root ！= null時，新解析的View會直接作為結果返回，而且root會為新解析的View生成LayoutParams並設定到該View中去。
- 當attachToRoot == false且root == null時，新解析的View會直接作為結果返回。
注意第二條和第三條是由區別的，你可以去寫個例子試一下，當root為null時，新解析出來的View沒有LayoutParams引數，這時候你設定的layout_width和layout_height是不生效的。
說到這裡，有人可能有疑問了，Activity裡的佈局應該也是LayoutInflater載入的，我也沒做什麼處理，但是我設定的layout_width和layout_heigh引數都是可以生效的，這是為什麼？?
這是因為Activity內部做了處理，我們知道Activity的setContentView()方法，實際上呼叫的PhoneWindow的setContentView()方法。它呼叫的時候將Activity的頂級DecorView（FrameLayout） 作為root傳了進去，mLayoutInflater.inflate(layoutResID, mContentParent)實際呼叫的是inflate(resource, root, root != null)，所以在呼叫Activity的setContentView()方法時 可以將解析出的View新增到頂級DecorView中，我們設定的layout_width和layout_height引數也可以生效。
具體程式碼如下：
@Override
public void setContentView(int layoutResID) {
if (mContentParent == null) {
installDecor();
} else if (!hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
mContentParent.removeAllViews();
}
if (hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
final Scene newScene = Scene.getSceneForLayout(mContentParent, layoutResID,
getContext());
transitionTo(newScene);
} else {
mLayoutInflater.inflate(layoutResID, mContentParent);
}
mContentParent.requestApplyInsets();
final Callback cb = getCallback();
if (cb != null && !isDestroyed()) {
cb.onContentChanged();
}
mContentParentExplicitlySet = true;
}
複製程式碼瞭解了inflate()方法各個引數的含義，我們正式來分析它的實現。
public abstract class LayoutInflater {
public View inflate(@LayoutRes int resource, @Nullable ViewGroup root, boolean attachToRoot) {
final Resources res = getContext().getResources();
if (DEBUG) {
Log.d(TAG, "INFLATING from resource: \"" + res.getResourceName(resource) + "\" ("
+ Integer.toHexString(resource) + ")");
}
//獲取xml資源解析器
final XmlResourceParser parser = res.getLayout(resource);
try {
return inflate(parser, root, attachToRoot);
} finally {
parser.close();
}
}
public View inflate(XmlPullParser parser, @Nullable ViewGroup root, boolean attachToRoot) {
synchronized (mConstructorArgs) {
Trace.traceBegin(Trace.TRACE_TAG_VIEW, "inflate");
final Context inflaterContext = mContext;
final AttributeSet attrs = Xml.asAttributeSet(parser);
//Context物件
Context lastContext = (Context) mConstructorArgs[0];
mConstructorArgs[0] = inflaterContext;
//儲存根檢視
View result = root;
try {
// 獲取根元素
int type;
while ((type = parser.next()) != XmlPullParser.START_TAG &&
type != XmlPullParser.END_DOCUMENT) {
// Empty
}
if (type != XmlPullParser.START_TAG) {
throw new InflateException(parser.getPositionDescription()
+ ": No start tag found!");
}
final String name = parser.getName();
if (DEBUG) {
System.out.println("**************************");
System.out.println("Creating root view: "
+ name);
System.out.println("**************************");
}
//1. 解析merge標籤，rInflate()方法會將merge下面的所有子View直接新增到根容器中，這裡
//我們也理解了為什麼merge標籤可以達到簡化佈局的效果。
if (TAG_MERGE.equals(name)) {
if (root == null || !attachToRoot) {
throw new InflateException("<merge /> can be used only with a valid "
+ "ViewGroup root and attachToRoot=true");
}
rInflate(parser, root, inflaterContext, attrs, false);
} else {
//2. 不是merge標籤那麼直接呼叫createViewFromTag()方法解析成佈局中的檢視，這裡的引數name就是要解析檢視的型別，例如：ImageView
final View temp = createViewFromTag(root, name, inflaterContext, attrs);
ViewGroup.LayoutParams params = null;
if (root != null) {
if (DEBUG) {
System.out.println("Creating params from root: " +
root);
}
//3. 呼叫generateLayoutParams()f方法生成佈局引數，如果attachToRoot為false，即不新增到根容器裡，為View設定佈局引數
params = root.generateLayoutParams(attrs);
if (!attachToRoot) {
// Set the layout params for temp if we are not
// attaching. (If we are, we use addView, below)
temp.setLayoutParams(params);
}
}
if (DEBUG) {
System.out.println("-----> start inflating children");
}
//4. 呼叫rInflateChildren()方法解析當前View下面的所有子View
rInflateChildren(parser, temp, attrs, true);
if (DEBUG) {
System.out.println("-----> done inflating children");
}
//如果根容器不為空，且attachToRoot為true，則將解析出來的View新增到根容器中
if (root != null && attachToRoot) {
root.addView(temp, params);
}
//如果根佈局為空或者attachToRoot為false，那麼解析出來的額View就是返回結果
if (root == null || !attachToRoot) {
result = temp;
}
}
} catch (XmlPullParserException e) {
final InflateException ie = new InflateException(e.getMessage(), e);
ie.setStackTrace(EMPTY_STACK_TRACE);
throw ie;
} catch (Exception e) {
final InflateException ie = new InflateException(parser.getPositionDescription()
+ ": " + e.getMessage(), e);
ie.setStackTrace(EMPTY_STACK_TRACE);
throw ie;
} finally {
// Don't retain static reference on context.
mConstructorArgs[0] = lastContext;
mConstructorArgs[1] = null;
Trace.traceEnd(Trace.TRACE_TAG_VIEW);
}
return result;
}
}
複製程式碼- 解析merge標籤，rInflate()方法會將merge下面的所有子View直接新增到根容器中，這裡我們也理解了為什麼merge標籤可以達到簡化佈局的效果。
- 不是merge標籤那麼直接呼叫createViewFromTag()方法解析成佈局中的檢視，這裡的引數name就是要解析檢視的型別，例如：ImageView。
- 呼叫generateLayoutParams()f方法生成佈局引數，如果attachToRoot為false，即不新增到根容器裡，為View設定佈局引數。
- 呼叫rInflateChildren()方法解析當前View下面的所有子View。
- 如果根容器不為空，且attachToRoot為true，則將解析出來的View新增到根容器中，如果根佈局為空或者attachToRoot為false，那麼解析出來的額View就是返回結果。返回解析出來的結果。
接下來，我們分別看下View樹解析以及View的解析。
一 View樹解析
上面我們已經提到View樹的解析是有rInflate()方法來完成的。
public abstract class LayoutInflater {
void rInflate(XmlPullParser parser, View parent, Context context,
AttributeSet attrs, boolean finishInflate) throws XmlPullParserException, IOException {
//1. 獲取樹的深度，執行深度優先遍歷
final int depth = parser.getDepth();
int type;
//2. 逐個進行元素解析
while (((type = parser.next()) != XmlPullParser.END_TAG ||
parser.getDepth() > depth) && type != XmlPullParser.END_DOCUMENT) {
if (type != XmlPullParser.START_TAG) {
continue;
}
final String name = parser.getName();
if (TAG_REQUEST_FOCUS.equals(name)) {
//3. 解析新增ad:focusable="true"的元素，並獲取View焦點。
parseRequestFocus(parser, parent);
} else if (TAG_TAG.equals(name)) {
//4. 解析View的tag。
parseViewTag(parser, parent, attrs);
} else if (TAG_INCLUDE.equals(name)) {
//5. 解析include標籤，注意include標籤不能作為根元素。
if (parser.getDepth() == 0) {
throw new InflateException("<include /> cannot be the root element");
}
parseInclude(parser, context, parent, attrs);
} else if (TAG_MERGE.equals(name)) {
//merge標籤必須為根元素
throw new InflateException("<merge /> must be the root element");
} else {
//6. 根據元素名進行解析，生成View。
final View view = createViewFromTag(parent, name, context, attrs);
final ViewGroup viewGroup = (ViewGroup) parent;
final ViewGroup.LayoutParams params = viewGroup.generateLayoutParams(attrs);
//7. 遞迴呼叫解析該View裡的所有子View，也是深度優先遍歷，rInflateChildren內部呼叫的也是rInflate()方
//法，只是傳入了新的parent View
rInflateChildren(parser, view, attrs, true);
//8. 將解析出來的View新增到它的父View中。
viewGroup.addView(view, params);
}
}
if (finishInflate) {
//9. 回撥根容器的onFinishInflate()方法，這個方法我們應該很熟悉。
parent.onFinishInflate();
}
}
//rInflateChildren內部呼叫的也是rInflate()方法，只是傳入了新的parent View
final void rInflateChildren(XmlPullParser parser, View parent, AttributeSet attrs,
boolean finishInflate) throws XmlPullParserException, IOException {
rInflate(parser, parent, parent.getContext(), attrs, finishInflate);
}
}
複製程式碼上述方法描述了整個View樹的解析流程，我們來概括一下：
- 獲取樹的深度，執行深度優先遍歷.
- 逐個進行元素解析。
- 解析新增ad:focusable="true"的元素，並獲取View焦點。
- 解析View的tag。
- 解析include標籤，注意include標籤不能作為根元素，而merge必須作為根元素。
- 根據元素名進行解析，生成View。
- 遞迴呼叫解析該View裡的所有子View，也是深度優先遍歷，rInflateChildren內部呼叫的也是rInflate()方法，只是傳入了新的parent View。
- 將解析出來的View新增到它的父View中。
- 回撥根容器的onFinishInflate()方法，這個方法我們應該很熟悉。
你可以看到，負責解析單個View的正是createViewFromTag()方法，我們再來分析下這個方法。
二 View解析
public abstract class LayoutInflater {
View createViewFromTag(View parent, String name, Context context, AttributeSet attrs,
boolean ignoreThemeAttr) {
//1. 解析view標籤。注意是小寫view，這個不太常用，下面會說。
if (name.equals("view")) {
name = attrs.getAttributeValue(null, "class");
}
//2. 如果標籤與主題相關，則需要將context與themeResId包裹成ContextThemeWrapper。
if (!ignoreThemeAttr) {
final TypedArray ta = context.obtainStyledAttributes(attrs, ATTRS_THEME);
final int themeResId = ta.getResourceId(0, 0);
if (themeResId != 0) {
context = new ContextThemeWrapper(context, themeResId);
}
ta.recycle();
}
//3. BlinkLayout是一種會閃爍的佈局，被包裹的內容會一直閃爍，像QQ訊息那樣。
if (name.equals(TAG_1995)) {
// Let's party like it's 1995!
return new BlinkLayout(context, attrs);
}
try {
View view;
//4. 使用者可以設定LayoutInflater的Factory來進行View的解析，但是預設情況下
//這些Factory都是為空的。
if (mFactory2 != null) {
view = mFactory2.onCreateView(parent, name, context, attrs);
} else if (mFactory != null) {
view = mFactory.onCreateView(name, context, attrs);
} else {
view = null;
}
if (view == null && mPrivateFactory != null) {
view = mPrivateFactory.onCreateView(parent, name, context, attrs);
}
//5. 預設情況下沒有Factory，而是通過onCreateView()方法對內建View進行解析，createView()
//方法進行自定義View的解析。
if (view == null) {
final Object lastContext = mConstructorArgs[0];
mConstructorArgs[0] = context;
try {
//這裡有個小技巧，因為我們在使用自定義View的時候是需要在xml指定全路徑的，例如：
//com.guoxiaoxing.CustomView，那麼這裡就有個.了，可以利用這一點判定是內建View
//還是自定義View，Google的工程師很機智的。?
if (-1 == name.indexOf('.')) {
//內建View解析
view = onCreateView(parent, name, attrs);
} else {
//自定義View解析
view = createView(name, null, attrs);
}
} finally {
mConstructorArgs[0] = lastContext;
}
}
return view;
} catch (InflateException e) {
throw e;
} catch (ClassNotFoundException e) {
final InflateException ie = new InflateException(attrs.getPositionDescription()
+ ": Error inflating class " + name, e);
ie.setStackTrace(EMPTY_STACK_TRACE);
throw ie;
} catch (Exception e) {
final InflateException ie = new InflateException(attrs.getPositionDescription()
+ ": Error inflating class " + name, e);
ie.setStackTrace(EMPTY_STACK_TRACE);
throw ie;
}
}
}
複製程式碼單個View的解析流程也很簡單，我們來梳理一下：
- 解析View標籤。
- 如果標籤與主題相關，則需要將context與themeResId包裹成ContextThemeWrapper。
- BlinkLayout是一種會閃爍的佈局，被包裹的內容會一直閃爍，像QQ訊息那樣。
- 使用者可以設定LayoutInflater的Factory來進行View的解析，但是預設情況下這些Factory都是為空的。
- 預設情況下沒有Factory，而是通過onCreateView()方法對內建View進行解析，createView()方法進行自定義View的解析。這裡有個小技巧，因為 我們在使用自定義View的時候是需要在xml指定全路徑的，例如：com.guoxiaoxing.CustomView，那麼這裡就有個.了，可以利用這一點判定是內建View 還是自定義View，Google的工程師很機智的。?
關於view標籤
<view
class="RelativeLayout"
android:layout_width="match_parent"
android:layout_height="match_parent"/>
複製程式碼在使用時，相當於所有控制元件標籤的父類一樣，可以設定class屬性，這個屬性會決定view這個節點會是什麼控制元件。
關於BlinkLayout
這個也是個冷門的控制元件，本質上是一個FrameLayout，被它包裹的控制元件會像電腦版的QQ小企鵝那樣一直閃爍。
<blink
android:layout_width="wrap_content"
android:layout_height="wrap_content">
<TextView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="這個控制元件會一直閃爍"/>
</blink>
複製程式碼關於onCreateView()與createView()
這兩個方法在本質上都是一樣的，只是onCreateView()會給內建的View前面加一個字首，例如：android.widget，方便開發者在寫內建View的時候，不用謝全路徑名。 前面我們也提到了LayoutInflater是一個抽象類，我們實際使用的PhoneLayoutInflater，這個類的實現很簡單，它重寫了LayoutInflater的onCreatView()方法，該 方法就是做了一個給內建View加字首的事情。
public class PhoneLayoutInflater extends LayoutInflater {
private static final String[] sClassPrefixList = {
"android.widget.",
"android.webkit.",
"android.app."
};
@Override protected View onCreateView(String name, AttributeSet attrs) throws ClassNotFoundException {
//迴圈遍歷三種字首，嘗試建立View
for (String prefix : sClassPrefixList) {
try {
View view = createView(name, prefix, attrs);
if (view != null) {
return view;
}
} catch (ClassNotFoundException e) {
// In this case we want to let the base class take a crack
// at it.
}
}
return super.onCreateView(name, attrs);
}
public LayoutInflater cloneInContext(Context newContext) {
return new PhoneLayoutInflater(this, newContext);
}
}
複製程式碼這樣一來，真正的View構建還是在createView()方法裡完成的，createView()主要根據完整的類的路徑名利用反射機制構建View物件，我們具體來 看看createView()方法的實現。
public abstract class LayoutInflater {
public final View createView(String name, String prefix, AttributeSet attrs)
throws ClassNotFoundException, InflateException {
//1. 從快取中讀取建構函式。
Constructor<? extends View> constructor = sConstructorMap.get(name);
if (constructor != null && !verifyClassLoader(constructor)) {
constructor = null;
sConstructorMap.remove(name);
}
Class<? extends View> clazz = null;
try {
Trace.traceBegin(Trace.TRACE_TAG_VIEW, name);
if (constructor == null) {
// Class not found in the cache, see if it's real, and try to add it
//2. 沒有在快取中查詢到建構函式，則構造完整的路徑名，並加裝該類。
clazz = mContext.getClassLoader().loadClass(
prefix != null ? (prefix + name) : name).asSubclass(View.class);
if (mFilter != null && clazz != null) {
boolean allowed = mFilter.onLoadClass(clazz);
if (!allowed) {
failNotAllowed(name, prefix, attrs);
}
}
//3. 從Class物件中獲取建構函式，並在sConstructorMap做下快取，方便下次使用。
constructor = clazz.getConstructor(mConstructorSignature);
constructor.setAccessible(true);
sConstructorMap.put(name, constructor);
} else {
//4. 如果sConstructorMap中有當前View建構函式的快取，則直接使用。
if (mFilter != null) {
// Have we seen this name before?
Boolean allowedState = mFilterMap.get(name);
if (allowedState == null) {
// New class -- remember whether it is allowed
clazz = mContext.getClassLoader().loadClass(
prefix != null ? (prefix + name) : name).asSubclass(View.class);
boolean allowed = clazz != null && mFilter.onLoadClass(clazz);
mFilterMap.put(name, allowed);
if (!allowed) {
failNotAllowed(name, prefix, attrs);
}
} else if (allowedState.equals(Boolean.FALSE)) {
failNotAllowed(name, prefix, attrs);
}
}
}
Object[] args = mConstructorArgs;
args[1] = attrs;
//5. 利用建構函式，構建View物件。
final View view = constructor.newInstance(args);
if (view instanceof ViewStub) {
// Use the same context when inflating ViewStub later.
final ViewStub viewStub = (ViewStub) view;
viewStub.setLayoutInflater(cloneInContext((Context) args[0]));
}
return view;
} catch (NoSuchMethodException e) {
final InflateException ie = new InflateException(attrs.getPositionDescription()
+ ": Error inflating class " + (prefix != null ? (prefix + name) : name), e);
ie.setStackTrace(EMPTY_STACK_TRACE);
throw ie;
} catch (ClassCastException e) {
// If loaded class is not a View subclass
final InflateException ie = new InflateException(attrs.getPositionDescription()
+ ": Class is not a View " + (prefix != null ? (prefix + name) : name), e);
ie.setStackTrace(EMPTY_STACK_TRACE);
throw ie;
} catch (ClassNotFoundException e) {
// If loadClass fails, we should propagate the exception.
throw e;
} catch (Exception e) {
final InflateException ie = new InflateException(
attrs.getPositionDescription() + ": Error inflating class "
+ (clazz == null ? "<unknown>" : clazz.getName()), e);
ie.setStackTrace(EMPTY_STACK_TRACE);
throw ie;
} finally {
Trace.traceEnd(Trace.TRACE_TAG_VIEW);
}
}
}
複製程式碼好了，到這篇文章為止，我們對整個Android顯示框架的原理分析就算是告一段落了，在這些文章裡我們側重的是Client端的分析，WindowManagerService、SurfaceFlinger這些Server端的 並沒有過多的涉及，因為對大部分開發者而言，紮實的掌握Client端的原理就足夠了。等到你完全掌握了Client端的原理或者是需要進行Android Framework層的開發，可以進一步去深入Server 端的原理。
關於Android顯示框架主要包括五篇文章：
- 01Android顯示框架：Android顯示框架概述
- 02Android顯示框架：Android應用檢視的載體View
- 03Android顯示框架：Android應用檢視的管理者Window
- 04Android顯示框架：Android應用視窗管理者WindowManager
- 05Android顯示框架：Android佈局解析者LayoutInflater
後續我們會接著進行
- Android元件框架
- Android動畫框架
- Android通訊框架
- Android多媒體框架
等Android子系統的分析，後續的內容可以關注Android open source project analysis專案。