該文主要從三個方面去介紹，分別為Activity的布局流程，資源加載流程以及換膚思路。
Activity的布局流程
回顧我們寫app的習慣，創(chuàng)建Activity，寫xxx.xml,在Activity里面setContentView(R.layout.xxx). 我們寫的是xml，最終呈現(xiàn)出來的是一個一個的界面上的UI控件，那么setContentView到底做了什么事，使得XML里面的內(nèi)容，變成了UI控件呢？首先先來看一張圖，
從圖中我們可以看到主要的兩個東西，LayoutInflater 和setFactory。LayoutInflater是將xml轉(zhuǎn)化為界面元素的控制類，在這里面會得到xml布局的相應控件的相關屬性并進行view的創(chuàng)建，然后會調(diào)用Factory的onCreateView()進行view的轉(zhuǎn)換。
LayoutInflater
關于LayoutInflater的介紹，可以看下下面這個的博客，寫的很詳細，在這就不一一去添代碼講流程了，畢竟用別人寫好的就很香。
Android 中LayoutInflater（布局加載器）之介紹篇
下面我們只挑我需要的代碼講。
在setContentView中，之后調(diào)用 LayoutInflater.inflate 方法，來解析 XML 資源文件，
public View inflate(@LayoutRes int resource, @Nullable ViewGroup root) {
return inflate(resource, root, root != null);
}
inflate有很多重載方法，最終調(diào)用的是下面的這個方法：
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 lastContext = (Context) mConstructorArgs[0];
mConstructorArgs[0] = inflaterContext;
View result = root;
try {
final String name = parser.getName();
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 {
final View temp = createViewFromTag(root, name, inflaterContext, attrs);
ViewGroup.LayoutParams params = null;
if (root != null) {
params = root.generateLayoutParams(attrs);
if (!attachToRoot) {
temp.setLayoutParams(params);
}
}
rInflateChildren(parser, temp, attrs, true);
if (root != null && attachToRoot) {
root.addView(temp, params);
}
if (root == null || !attachToRoot) {
result = temp;
}
}
} catch (XmlPullParserException e) {
}
return result;
}
}
從代碼中我們可以看到，先判斷是不是TAG_MERGE標簽，如果是，則調(diào)用rInflate（）方法對其處理：
使用 merge 標簽必須有父布局，且依賴于父布局加載
merge 并不是一個 ViewGroup，也不是一個 View，它相當于聲明了一些視圖，等待被添加，解析過程中遇到 merge 標簽會將 merge 標簽下面的所有子 view 添加到根布局中
merge 標簽在 XML 中必須是根元素
相反的 include 不能作為根元素，需要放在一個 ViewGroup 中
使用 include 標簽必須指定有效的 layout 屬性
使用 include 標簽不寫寬高是沒有關系的，會去解析被 include 的layout
而這些解析的過程中，最終會調(diào)用rInflateChildren（），所以說為什么復雜的布局會產(chǎn)生卡頓，XmlResourseParser 對 XML 的遍歷，隨著布局越復雜，層級嵌套越多，所花費的時間也越長，調(diào)用 onCreateView 與 createView 方法是通過反射創(chuàng)建 View 對象導致的耗時。
在 Android 10上，新增 tryInflatePrecompiled 方法是為了減少 XmlPullParser 解析 XML 的時間，但是用一個全局變量 mUseCompiledView 來控制是否啟用 tryInflatePrecompiled 方法，根據(jù)源碼分析，mUseCompiledView 始終為 false，所以 tryInflatePrecompiled 方法目前在 release 版本中不可使用。
不是則調(diào)用createViewFromTag來創(chuàng)建View，然后判斷root是否為null，如果不為null，拿到root的params，如果不添加到父布局root中，就將解析到的LayoutParams設置到該view中去。具體的操作規(guī)則如下：
當 attachToRoot == true 且 root ！= null 時，新解析出來的 View 會被 add 到 root 中去，然后將 root 作為結(jié)果返回
當 attachToRoot == false 且 root ！= null 時，新解析的 View 會直接作為結(jié)果返回，而且 root 會為新解析的 View 生成 LayoutParams 并設置到該 View 中去
當 attachToRoot == false 且 root == null 時，新解析的 View 會直接作為結(jié)果返回
那我們繼續(xù)看createViewFromTag。
View createViewFromTag(View parent, String name, Context context, AttributeSet attrs,
boolean ignoreThemeAttr) {
......
try {
View view = tryCreateView(parent, name, context, attrs);
if (view == null) {
final Object lastContext = mConstructorArgs[0];
mConstructorArgs[0] = context;
try {
if (-1 == name.indexOf('.')) {
view = onCreateView(context, parent, name, attrs);
} else {
view = createView(context, name, null, attrs);
}
} finally {
mConstructorArgs[0] = lastContext;
}
}
return view;
} catch (InflateException e) {
}
}
在該方法中可以看到，先調(diào)用tryCreateView（）去創(chuàng)建View，在這個方法里面就是調(diào)用下面需要講的Factory，所以放在后面講，onCreateView最終調(diào)用的是createView，而在createView中采用的是反射的方式創(chuàng)建View實例。
setFactory
講這個之前先看幾個圖，
我們在布局中寫的是Button,TextView,ImageView,但是在AS的Layout Inspector功能查看下，變成了AppCompatButton,AppCompatTextView,AppComaptImageView,那到底是我們的按鈕真的已經(jīng)在編譯的時候自動變成了AppCompatXXX系列，還是只是單純的在這個工具里面看的時候我們的控件只是顯示給我們看到的名字是AppCompatXXX系列而已。
我們把我們的Activity的父類做下修改，改為：
public class TestActivity extends AppCompatActivity{
......
}
變?yōu)?public class TestActivity extends Activity{
......
}
我們再來查看下Layout Inspector界面：
我們可以看到，控件就自動變成了我們布局里面寫的控件名稱了，造成這種現(xiàn)象的原因就是下面我們要分析的。我們首先來看tryCreateView（）方法。
public final View tryCreateView(@Nullable View parent, @NonNull String name,
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);
}
return view;
}
如果mFactory2不為null的時候就會調(diào)用mFactory2.onCreateView（），
public interface Factory2 extends Factory {
@Nullable
View onCreateView(@Nullable View parent, @NonNull String name,
@NonNull Context context, @NonNull AttributeSet attrs);
}
Factory2是一個接口，具體的實現(xiàn)類是AppCompatDelegateImpl。
@Override
public View createView(View parent, final String name, @NonNull Context context,
@NonNull AttributeSet attrs) {
if (mAppCompatViewInflater == null) {
TypedArray a = mContext.obtainStyledAttributes(R.styleable.AppCompatTheme);
String viewInflaterClassName =
a.getString(R.styleable.AppCompatTheme_viewInflaterClass);
if ((viewInflaterClassName == null)
|| AppCompatViewInflater.class.getName().equals(viewInflaterClassName)) {
// Either default class name or set explicitly to null. In both cases
// create the base inflater (no reflection)
mAppCompatViewInflater = new AppCompatViewInflater();
} else {
try {
Class viewInflaterClass = Class.forName(viewInflaterClassName);
mAppCompatViewInflater =
(AppCompatViewInflater) viewInflaterClass.getDeclaredConstructor()
.newInstance();
} catch (Throwable t) {
Log.i(TAG, "Failed to instantiate custom view inflater "
+ viewInflaterClassName + ". Falling back to default.", t);
mAppCompatViewInflater = new AppCompatViewInflater();
}
}
}
boolean inheritContext = false;
if (IS_PRE_LOLLIPOP) {
inheritContext = (attrs instanceof XmlPullParser)
// If we have a XmlPullParser, we can detect where we are in the layout
? ((XmlPullParser) attrs).getDepth() > 1
// Otherwise we have to use the old heuristic
: shouldInheritContext((ViewParent) parent);
}
return mAppCompatViewInflater.createView(parent, name, context, attrs, inheritContext,
IS_PRE_LOLLIPOP, /* 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 */
);
}
會調(diào)用mAppCompatViewInflater的createView（），
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;
// We can emulate Lollipop's android:theme attribute propagating down the view hierarchy
// by using the parent's context
if (inheritContext && parent != null) {
context = parent.getContext();
}
if (readAndroidTheme || readAppTheme) {
// We then apply the theme on the context, if specified
context = themifyContext(context, attrs, readAndroidTheme, readAppTheme);
}
if (wrapContext) {
context = TintContextWrapper.wrap(context);
}
View view = null;
// We need to 'inject' our tint aware Views in place of the standard framework versions
switch (name) {
case "TextView":
view = createTextView(context, attrs);
verifyNotNull(view, name);
break;
case "ImageView":
view = createImageView(context, attrs);
verifyNotNull(view, name);
break;
case "Button":
view = createButton(context, attrs);
verifyNotNull(view, name);
break;
case "EditText":
view = createEditText(context, attrs);
verifyNotNull(view, name);
break;
case "Spinner":
view = createSpinner(context, attrs);
verifyNotNull(view, name);
break;
case "ImageButton":
view = createImageButton(context, attrs);
verifyNotNull(view, name);
break;
case "CheckBox":
view = createCheckBox(context, attrs);
verifyNotNull(view, name);
break;
case "RadioButton":
view = createRadioButton(context, attrs);
verifyNotNull(view, name);
break;
case "CheckedTextView":
view = createCheckedTextView(context, attrs);
verifyNotNull(view, name);
break;
case "AutoCompleteTextView":
view = createAutoCompleteTextView(context, attrs);
verifyNotNull(view, name);
break;
case "MultiAutoCompleteTextView":
view = createMultiAutoCompleteTextView(context, attrs);
verifyNotNull(view, name);
break;
case "RatingBar":
view = createRatingBar(context, attrs);
verifyNotNull(view, name);
break;
case "SeekBar":
view = createSeekBar(context, attrs);
verifyNotNull(view, name);
break;
default:
// The fallback that allows extending class to take over view inflation
// for other tags. Note that we don't check that the result is not-null.
// That allows the custom inflater path to fall back on the default one
// later in this method.
view = createView(context, name, attrs);
}
if (view == null && originalContext != context) {
// If the original context does not equal our themed context, then we need to manually
// inflate it using the name so that android:theme takes effect.
view = createViewFromTag(context, name, attrs);
}
if (view != null) {
// If we have created a view, check its android:onClick
checkOnClickListener(view, attrs);
}
return view;
}
protected AppCompatTextView createTextView(Context context, AttributeSet attrs) {
return new AppCompatTextView(context, attrs);
}
從這里我們知道，為什么我們在前面的截圖中看到的變成那樣了。
那這個Factory2什么時候設置的？
protected void onCreate(@Nullable Bundle savedInstanceState) {
final AppCompatDelegate delegate = getDelegate();
delegate.installViewFactory();//1
delegate.onCreate(savedInstanceState);
super.onCreate(savedInstanceState);
}
重點就在這個注釋1，
public void installViewFactory() {
LayoutInflater layoutInflater = LayoutInflater.from(mContext);
if (layoutInflater.getFactory() == null) {
LayoutInflaterCompat.setFactory2(layoutInflater, this);
} else {
if (!(layoutInflater.getFactory2() instanceof AppCompatDelegateImpl)) {
Log.i(TAG, "The Activity's LayoutInflater already has a Factory installed"
+ " so we can not install AppCompat's");
}
}
}
資源加載流程
常規(guī)操作先上一張圖，
從圖中可以知道，
1、ResourcesManager管理著一個Resources類
2、Resources類里有他的實現(xiàn)類ResourcesImpl，各種創(chuàng)建，調(diào)用，getColor等方法都是在實現(xiàn)類里實現(xiàn)的
3、ResourcesImpl里管理著一個AssetManager
4、AssetManager負責從apk里獲取資源，寫入資源等 addAssetPath（）
下面我們來分析一下。起點是ActivityThread.java handleBindApplication（）方法 ，在這加載Application的。
final ContextImpl appContext = ContextImpl.createAppContext(this, data.info);
static ContextImpl createAppContext(ActivityThread mainThread, LoadedApk packageInfo) {
return createAppContext(mainThread, packageInfo, null);
}
static ContextImpl createAppContext(ActivityThread mainThread, LoadedApk packageInfo,
String opPackageName) {
if (packageInfo == null) throw new IllegalArgumentException("packageInfo");
ContextImpl context = new ContextImpl(null, mainThread, packageInfo, null, null, null, 0,
null, opPackageName);
context.setResources(packageInfo.getResources());
return context;
}
在handleBindApplication中創(chuàng)建ContextImpl，然后setResources.而這個資源是從LoadedApk中獲取到。
public Resources getResources() {
if (mResources == null) {
final String[] splitPaths;
try {
splitPaths = getSplitPaths(null);
} catch (NameNotFoundException e) {
// This should never fail.
throw new AssertionError("null split not found");
}
mResources = ResourcesManager.getInstance().getResources(null, mResDir,
splitPaths, mOverlayDirs, mApplicationInfo.sharedLibraryFiles,
Display.DEFAULT_DISPLAY, null, getCompatibilityInfo(),
getClassLoader());
}
return mResources;
}
然后調(diào)用ResourcesManager中的getResources（）,
public @Nullable Resources getResources(@Nullable IBinder activityToken,
@Nullable String resDir,
@Nullable String[] splitResDirs,
@Nullable String[] overlayDirs,
@Nullable String[] libDirs,
int displayId,
@Nullable Configuration overrideConfig,
@NonNull CompatibilityInfo compatInfo,
@Nullable ClassLoader classLoader) {
try {
Trace.traceBegin(Trace.TRACE_TAG_RESOURCES, "ResourcesManager#getResources");
final ResourcesKey key = new ResourcesKey(
resDir,
splitResDirs,
overlayDirs,
libDirs,
displayId,
overrideConfig != null ? new Configuration(overrideConfig) : null, // Copy
compatInfo);
classLoader = classLoader != null ? classLoader : ClassLoader.getSystemClassLoader();
return getOrCreateResources(activityToken, key, classLoader);
} finally {
Trace.traceEnd(Trace.TRACE_TAG_RESOURCES);
}
}
根據(jù)傳過來的參數(shù)封裝成key.這個key在后面用來生成Resources。
private @Nullable Resources getOrCreateResources(@Nullable IBinder activityToken,
@NonNull ResourcesKey key, @NonNull ClassLoader classLoader) {
synchronized (this) {
if (DEBUG) {
Throwable here = new Throwable();
here.fillInStackTrace();
Slog.w(TAG, "!! Get resources for activity=" + activityToken + " key=" + key, here);
}
if (activityToken != null) {
final ActivityResources activityResources =
getOrCreateActivityResourcesStructLocked(activityToken);
// Clean up any dead references so they don't pile up.
ArrayUtils.unstableRemoveIf(activityResources.activityResources,
sEmptyReferencePredicate);
// Rebase the key's override config on top of the Activity's base override.
if (key.hasOverrideConfiguration()
&& !activityResources.overrideConfig.equals(Configuration.EMPTY)) {
final Configuration temp = new Configuration(activityResources.overrideConfig);
temp.updateFrom(key.mOverrideConfiguration);
key.mOverrideConfiguration.setTo(temp);
}
ResourcesImpl resourcesImpl = findResourcesImplForKeyLocked(key);
if (resourcesImpl != null) {
if (DEBUG) {
Slog.d(TAG, "- using existing impl=" + resourcesImpl);
}
return getOrCreateResourcesForActivityLocked(activityToken, classLoader,
resourcesImpl, key.mCompatInfo);
}
// We will create the ResourcesImpl object outside of holding this lock.
} else {
// Clean up any dead references so they don't pile up.
ArrayUtils.unstableRemoveIf(mResourceReferences, sEmptyReferencePredicate);
// Not tied to an Activity, find a shared Resources that has the right ResourcesImpl
ResourcesImpl resourcesImpl = findResourcesImplForKeyLocked(key);
if (resourcesImpl != null) {
if (DEBUG) {
Slog.d(TAG, "- using existing impl=" + resourcesImpl);
}
return getOrCreateResourcesLocked(classLoader, resourcesImpl, key.mCompatInfo);
}
// We will create the ResourcesImpl object outside of holding this lock.
}
// If we're here, we didn't find a suitable ResourcesImpl to use, so create one now.
ResourcesImpl resourcesImpl = createResourcesImpl(key);
if (resourcesImpl == null) {
return null;
}
// Add this ResourcesImpl to the cache.
mResourceImpls.put(key, new WeakReference<>(resourcesImpl));
final Resources resources;
if (activityToken != null) {
resources = getOrCreateResourcesForActivityLocked(activityToken, classLoader,
resourcesImpl, key.mCompatInfo);
} else {
resources = getOrCreateResourcesLocked(classLoader, resourcesImpl, key.mCompatInfo);
}
return resources;
}
}
首先從軟引用中獲取，如果獲取不到，則調(diào)用createResourcesImpl創(chuàng)建。
private @Nullable ResourcesImpl createResourcesImpl(@NonNull ResourcesKey key) {
final DisplayAdjustments daj = new DisplayAdjustments(key.mOverrideConfiguration);
daj.setCompatibilityInfo(key.mCompatInfo);
final AssetManager assets = createAssetManager(key);
if (assets == null) {
return null;
}
final DisplayMetrics dm = getDisplayMetrics(key.mDisplayId, daj);
final Configuration config = generateConfig(key, dm);
final ResourcesImpl impl = new ResourcesImpl(assets, dm, config, daj);
if (DEBUG) {
Slog.d(TAG, "- creating impl=" + impl + " with key: " + key);
}
return impl;
}
ResourcesImpl的創(chuàng)建需要AssetManager作為參數(shù)。
關于AssetManager的詳細解析請參考下面這篇文章。
Android資源管理框架：Asset Manager的創(chuàng)建過程
換膚思路
具體思路為：
1.收集xml數(shù)據(jù)，根據(jù)View創(chuàng)建過程的Factory2（源碼里拷貝過來就行）需要修改的地方就是View創(chuàng)建完事以后，將需要修改的屬性及他的View記錄下來（比如要改color、src、backgrand）
2.讀取皮膚包里的內(nèi)容。先通過assets.addAssetPath()加載進來，這樣就能通過assetManager來獲取皮膚包里的資源了
3.如果遇到了需要替換的屬性（color、src、backgrand等）那就替換，通過assetManager里的方法
另外參考下面兩篇文章：
Android 換膚那些事兒， Resource包裝流 ？AssetManager替換流？
參考資料
Android 中LayoutInflater（布局加載器）之介紹篇
