AppCompatActivity是support.v7包裡面用來替代Activity的Activity元件,主要用來相容5.0之後的新特性,當我們在不同版本的系統裡面使用的時候會發現,在5.0之後的系統中,控制元件會帶新特性,而在之前的版本中,則使用的控制元件則不能使用新特新。
比如:
TextView在Activity下是android.widget.TextView
,
而在AppCompatActivity中則是android.support.v7.widget.AppCompatTextView
,
為什麼在AppCompatActivity中,我們的TextView會被系統篡改成AppCompatTextView,今天我們來一起找找原因。
首先我們來看下AppCompatActivity是如何載入佈局的:
// AppCompatActivity.java
@Override
public void setContentView(@LayoutRes int layoutResID) {
getDelegate().setContentView(layoutResID);
}
@NonNull
public AppCompatDelegate getDelegate() {
if (mDelegate == null) {
mDelegate = AppCompatDelegate.create(this, this);
}
return mDelegate;
}
private static AppCompatDelegate create(Context context, Window window,
AppCompatCallback callback) {
final int sdk = Build.VERSION.SDK_INT;
if (BuildCompat.isAtLeastN()) {
return new AppCompatDelegateImplN(context, window, callback);
} else if (sdk >= 23) {
return new AppCompatDelegateImplV23(context, window, callback);
} else if (sdk >= 14) {
return new AppCompatDelegateImplV14(context, window, callback);
} else if (sdk >= 11) {
return new AppCompatDelegateImplV11(context, window, callback);
} else {
return new AppCompatDelegateImplV9(context, window, callback);
}
}
複製程式碼
可以發現在create
方法中,對版本進行了控制,對於不同的版本構建了不同的APPCOMPatDelegate物件。當我們點進去會發現,這些根據版本構建的物件最終都是繼承自同一個類AppCompatDelegateImplV9
,而AppCompatDelegateImplV9
則是實現了一個LayoutInflaterFactory
的介面。這個介面到底是什麼東西呢?
我們暫時先不要管這個,接著向下看:
@Override
public void setContentView(View v) {
ensureSubDecor();
ViewGroup contentParent = (ViewGroup) mSubDecor.findViewById(android.R.id.content);
contentParent.removeAllViews();
contentParent.addView(v);
mOriginalWindowCallback.onContentChanged();
}
private ViewGroup createSubDecor() {
subDecor = (ViewGroup) inflater.inflate(R.layout.abc_screen_simple, null);
final ContentFrameLayout contentView = (ContentFrameLayout) subDecor.findViewById(
R.id.action_bar_activity_content);
}
複製程式碼
這邊其實就和Activity載入佈局是一樣的了,都是通過先新增DecorView,在找到名為content的framelayout的id,通過在這個id上新增我們的佈局:
請參考 【Android原始碼】Activity如何載入佈局
這個時候我們就會發現在我們當時做的【Android原始碼】LayoutInflater 分析和【Android原始碼】View的建立流程,所沒有注意到的細節:
View createViewFromTag(View parent, String name, Context context, AttributeSet attrs,
boolean ignoreThemeAttr) {
try {
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;
}
if (view == null && mPrivateFactory != null) {
view = mPrivateFactory.onCreateView(parent, name, context, attrs);
}
if (view == null) {
final Object lastContext = mConstructorArgs[0];
mConstructorArgs[0] = context;
try {
if (-1 == name.indexOf('.')) {
view = onCreateView(parent, name, attrs);
} else {
view = createView(name, null, attrs);
}
} finally {
mConstructorArgs[0] = lastContext;
}
}
return view;
} catch (InflateException e) {
throw e;
}
}
複製程式碼
createViewFromTag
是用來建立View的,但是我們會發現在程式碼中會有factory2、factory這兩個東西,而這兩個東西就是我們在上面發現的AppCompatDelegateImplV9
實現的LayoutInflaterFactory
介面,只要實現了這個介面,那麼View會被這個介面來賦值,而不是接著走原來的View的建立過程。
所以我們現在返回到AppCompatDelegateImplV9
中,找到介面的實現方法:
@Override
public final View onCreateView(View parent, String name,
Context context, AttributeSet attrs) {
// First let the Activity's Factory try and inflate the view
final View view = callActivityOnCreateView(parent, name, context, attrs);
if (view != null) {
return view;
}
// If the Factory didn't handle it, let our createView() method try
return createView(parent, name, context, attrs);
}
@Override
public View createView(View parent, final String name, @NonNull Context context,
@NonNull AttributeSet attrs) {
final boolean isPre21 = Build.VERSION.SDK_INT < 21;
if (mAppCompatViewInflater == null) {
mAppCompatViewInflater = new AppCompatViewInflater();
}
// We only want the View to inherit its context if we're running pre-v21
final boolean inheritContext = isPre21 && shouldInheritContext((ViewParent) parent);
return mAppCompatViewInflater.createView(parent, name, context, attrs, inheritContext,
isPre21, /* Only read android:theme pre-L (L+ handles this anyway) */
true, /* Read read app:theme as a fallback at all times for legacy reasons */
VectorEnabledTintResources.shouldBeUsed() /* Only tint wrap the context if enabled */
);
}
複製程式碼
在這個實現方法中,最終我們找到類AppCompatViewInflater
,而這個類通過createView方法來直接賦值給View:
public final View createView(View parent, final String name, @NonNull Context context,
@NonNull AttributeSet attrs, boolean inheritContext,
boolean readAndroidTheme, boolean readAppTheme, boolean wrapContext) {
final Context originalContext = context;
View view = null;
// We need to 'inject' our tint aware Views in place of the standard framework versions
switch (name) {
case "TextView":
view = new AppCompatTextView(context, attrs);
break;
case "ImageView":
view = new AppCompatImageView(context, attrs);
break;
// 程式碼省略
}
return view;
}
複製程式碼
可以發現,如果是TextView
,就直接返回V7包中的AppCompatTextView
類,所以這就是為什麼當我們使用AppCompatActivity
的時候,TextView
變成AppCompatTextView
的原因。
通過實現LayoutInflaterFactory
,系統就會根據當前系統的版本號,來對應的生成View,所以這就是為什麼在不同版本中,同一個控制元件會有不同的效果的原因。