Android在XML文件中創建或者引用資源語法定義如下：

//在R.java的type內部類中添加一條靜態常量id資源標識符，如果標示符（包括系統資源）已經存在則表示引用該標示符。
@+type/name

//在R.java中尋找已經定義的標識符，如果找不到則提示失敗錯誤，一般在xml中定義有先後關系。
@type/name

//所以一般推薦直接使用+號避免不必要的意外。

Android在XML文件中xmlns語法定義如下：

//xmlns（XML Namespaces）是XML的命名空間
//通用XML命名空間格式規則
xmlns:namespace-prefix="namespaceURI"

在Android的XML中命名空間規則如下：

xmlns:namespace-prefix=http://schemas.android.com/apk/res/應用程序包路徑

在使用時規則如下：

namespace-prefix：屬性

切記，xmlns的定義必須放在最外層開始的的標記中，譬如我們Activity的xml文件的根布局中的android前綴、tools前綴、自定義View的前綴等。常見的例子如下：

//android即為frameworks/base/core/res/res/values/attrs.xml中的屬性
xmlns:android="http://schemas.android.com/apk/res/android"

//開發調試利器，不再過多說明
xmlns:tools="http://schemas.android.com/tools"

//Email App中res/values/attrs.xml等自定義屬性
xmlns:settings="http://schemas.android.com/apk/res/com.android.email"

2-6 Android應用Theme、Style使用小結

到此關於Android應用中如何定義Theme、Style及使用和繼承重寫相信大家已經明白了，再出現詭異的現象就可以通過查詢相關API及google結合就能完全理會其中的原因了，而不是停留在能搜到復制；下面一節我們將針對上面的這些使用進行粗略的源碼分析說明。

3 源碼結構淺析

有了上面的應用使用基礎，下面的源碼簡單淺析可能存在跳躍性和經驗性，不會像之前博客那樣系統性的從頭到尾進行分析，而是分點點到為止，感興趣的同學可以自行深入研讀。

3-1 追根溯源Theme、Style等根源

在我們App開發中通常我們會在新建工程後的AndroidManifest.xml文件中看見工程默認引用了應用包下自定義的主題@style/AppTheme（用法完全符合上一大節的規則）。該主題在當前應用包的style.xml中定義如下：

看著木有，它活生生的繼承了Theme.AppCompat.Light.DarkActionBar這個style，這玩意又在framework的support v7包下res的themes.xml文件中，具體如下：

哈哈，原來如此，這裡的Theme.Light你應該十分熟悉了吧（這就是以前我們App用的不是Support包，而是默認的時候，theme默認就是這玩意哈），這玩意就在framework的base下的themes.xml中定義著呢（所以通過了android:進行引用，留意細節吧），具體如下：

到這裡我們就很容易明白啦，Theme.Light的父類原來是Theme哇，也在這個文件中，如下：

看注釋吧，這貨有接近400多個item屬性，這也就是我們Android關於Theme的開山鼻祖了，在我們自定義時其實來這看比去API查還方便呢（其實需要兩個互相配合，一個查，一個看解釋，哈哈），因為它裡面定義了關於我們整個應用中文字樣式、按鈕樣式、列表樣式、窗體樣式、對話框樣式等，這些樣式都是默認樣式，它還有很多我們常用的擴展樣式，譬如Theme.Light、Theme.NoTitleBar、Theme.NoTitleBar.Fullscreen等等，反正你要有需求來這裡搞就行。當我們繼承使用時只用在前加上android:即可，有些屬性可能是找不到的。同理，我們所謂的style、attr等等也都是這麼個框架，大致位置也類似主題Theme的，所以這裡不再過多說明，自行腦補即可。

3-2 Theme、Style等res資源客戶化流程

對於純App開發來說這一個知識點可以忽略，因為本小節需要大致了解Android源碼的結構和編譯框架，對於固件等開發來說這個還是比較重要的，記得以前做TV盒子開發時很多系統資源需要替換及添加，也就是說會稍微涉及到修改System UI及FW的res，那時候好坑爹，雖然修改的地方不多，只是換幾個圖標和加幾個資源，但是那時候自己還是蒙圈了一段時間才搞明白，所以說有必要啰嗦幾句。

首先我們先要明白設備裡系統目錄下的這些常見jar與apk的來源，如下：

有了上邊這幾個和我們本文相關的核心常識後我們簡單說下怎麼修改編譯：

不過這裡有些坑大家要明白，我們在mm前最好每次都去清除對應out/obj目錄下的中間文件，特別是資源文件更新時，否則容易被坑。還有就是切記添加系統API或者修改@hide的API或者添加資源（包含添加修改public.xml等）後，需要執行make update-api命令來同步base/api下的current.txt的修改，完事再make就行啦，這些編譯文檔都有介紹。

有了上面這些相信大家對於客戶化資源也就有了一些認識啦，想想如果我們需要用到framework.jar的hide資源或者framework-res.apk中新加的資源時又不想用反射和源碼下編譯怎麼辦？當然是編譯一個no hide的jar引入我們工程即可哇，要注意我們引入以後一定是Providered的模式，也就是該jar只編譯不打包入該apk，還有就是依賴的先後優先級順序，否則又用的是sdk默認的。還有就是萬能的android.jar也是一種曲線救國的辦法。當然啦，如果是SDK開發則完全可以復制一份自己搞，完事編譯進系統即可，同時提供給App開發。

3-3 Theme、Style加載時機及加載源碼淺析

前面我們介紹了Android的Theme、Style的定義及使用及Theme、Style等res的由來，這裡我們來看看這些被使用的Theme的最終是何時、怎樣被加載生效的。我們都知道對於Theme有兩種方式來使用，具體如下（Style等attr在View的使用也比較同類，這裡只分析Theme、其他的請在View等地自行分析腦補）：

可以看見，這兩種方式我們都比較常用，甚至有時候還會設置Window的一些屬性標記，這些標記方法都在Window類中。我們平時在設置這些Theme時總是有很多疑惑，譬如為毛只能在setContentView()前設置等等，那麼下面我們就來庖丁解牛一把。故事在開始之前可能還需要你自行腦補下《Android應用setContentView與LayoutInflater加載解析機制源碼分析》與《Android應用Activity、Dialog、PopWindow、Toast窗口添加機制及源碼分析》兩篇文章，完事再來繼續下面的內容。

關於Activity通過setContentView方法設置View的來源這裡就不多說了，參考前面兩篇即可，我們直接跳到PhoneWindow的setContentView方法來看下，如下：

    public void setContentView(int layoutResID) {
        if (mContentParent == null) {
                installDecor();//每個Activity第一次進來必走
        } else if (!hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
            mContentParent.removeAllViews();
        }
        ......
    }

我們接著來看下installDecor()方法，如下：

private void installDecor() {
    if (mDecor == null) {
        //僅僅new DecorView(getContext(), -1)而已，也就是FrameLayout
        mDecor = generateDecor();
        ......
    }
    if (mContentParent == null) {
        //生成我們布局的父布局
        mContentParent = generateLayout(mDecor);

        // Set up decor part of UI to ignore fitsSystemWindows if appropriate.
        mDecor.makeOptionalFitsSystemWindows();

        final DecorContentParent decorContentParent = (DecorContentParent) mDecor.findViewById(
                R.id.decor_content_parent);
        ......
    }
}

接著我們繼續看看generateLayout(mDecor);這個方法，如下：

protected ViewGroup generateLayout(DecorView decor) {
    // Apply data from current theme.
    //獲取當前主題，重點！！！！！！！
    TypedArray a = getWindowStyle();
    ......
    //解析一堆主題屬性，譬如下面的是否浮動window（dialog）等
    mIsFloating = a.getBoolean(R.styleable.Window_windowIsFloating, false);
    ......
    // Inflate the window decor.
    //依據屬性獲取不同的布局添加到Decor
    int layoutResource;
    int features = getLocalFeatures();
    // System.out.println("Features: 0x" + Integer.toHexString(features));
    if ((features & (1 << layoutresource="R.layout.screen_swipe_dismiss;" ......="" view="" in="mLayoutInflater.inflate(layoutResource," new="" mcontentroot="(ViewGroup)" viewgroup="" contentparent="(ViewGroup)findViewById(ID_ANDROID_CONTENT);" return="" pre="">

一樣喽，繼續先看下getWindowStyle()方法是神馬鬼，這個方法在其基類Window中，如下：

/**
 * Return the {@link android.R.styleable#Window} attributes from this
 * window's theme.
 */
public final TypedArray getWindowStyle() {
    synchronized (this) {
        if (mWindowStyle == null) {
            mWindowStyle = mContext.obtainStyledAttributes(
                    com.android.internal.R.styleable.Window);
        }
        return mWindowStyle;
    }
}

哎，沒啥好看的，沒有邏輯，就是流程，繼續跟吧，去Context類看看obtainStyledAttributes(com.android.internal.R.styleable.Window)方法吧，如下：

/**
 * Return the Theme object associated with this Context.
 */
@ViewDebug.ExportedProperty(deepExport = true)
public abstract Resources.Theme getTheme();

/**
 * Retrieve styled attribute information in this Context's theme.  See
 * {@link android.content.res.Resources.Theme#obtainStyledAttributes(int[])}
 * for more information.
 *
 * @see android.content.res.Resources.Theme#obtainStyledAttributes(int[])
 */
public final TypedArray obtainStyledAttributes(@StyleableRes int[] attrs) {
        //獲取當前Theme對應的TypedArray對象  
    return getTheme().obtainStyledAttributes(attrs);
}

哎呦我去，憋大招呢，急死人了！可以看見Context的getTheme()方法時一個抽象方法，那他的實現在哪呢，看過《Android應用Context詳解及源碼解析》一文的同學一定知道對於Activity來說他的實現類就是ContextThemeWapprer，那我們趕緊進去看看它到底搞了啥玩意，如下：

@Override 
public Resources.Theme getTheme() {
    //一旦設置有Theme則不再走後面邏輯，直接返回以前設置的Theme
    if (mTheme != null) {
        return mTheme;
    }
    //沒有設置Theme則獲取默認的selectDefaultTheme
    mThemeResource = Resources.selectDefaultTheme(mThemeResource,
            getApplicationInfo().targetSdkVersion);
    //初始化選擇的主題，mTheme就不為null了
    initializeTheme();

    return mTheme;
}

@Override
public void setTheme(int resid) {
    //通過外部設置以後mTheme和mThemeResource就不為null了
    if (mThemeResource != resid) {
        mThemeResource = resid;
        //初始化選擇的主題，mTheme就不為null了
        initializeTheme();
    }
}

我勒個去，憋大招總算憋出來翔了，ContextThemeWapprer才是重頭戲啊，總算看見了光明了。這裡的getTheme方法有一個判斷，沒有設置過Theme（mTheme為空）則通過Resources.selectDefaultTheme獲取默認主題，否則用setTheme設置的主題。那麼我們就來先看下假設沒有設置主題，使用默認主題的方法，Resources.selectDefaultTheme如下：
 

　　/**

　　* Returns the most appropriate default theme for the specified target SDK version.

　　* 


　　* 

Below API 11: Gingerbread

　　* 

APIs 11 thru 14: Holo

　　* 

APIs 14 thru XX: Device default dark

　　* 

API XX and above: Device default light with dark action bar

　　* 


　　*

　　* @param curTheme The current theme, or 0 if not specified.

　　* @param targetSdkVersion The target SDK version.

　　* @return A theme resource identifier

　　* @hide

　　*/

　　public static int selectDefaultTheme(int curTheme, int targetSdkVersion) {

　　return selectSystemTheme(curTheme, targetSdkVersion,

　　com.android.internal.R.style.Theme,

　　com.android.internal.R.style.Theme_Holo,

　　com.android.internal.R.style.Theme_DeviceDefault,

　　com.android.internal.R.style.Theme_DeviceDefault_Light_DarkActionBar);

　　}

　　/** @hide */

　　public static int selectSystemTheme(int curTheme, int targetSdkVersion, int orig, int holo,

　　int dark, int deviceDefault) {

　　if (curTheme != 0) {

　　return curTheme;

　　}

　　if (targetSdkVersion < Build.VERSION_CODES.HONEYCOMB) {

　　return orig;

　　}

　　if (targetSdkVersion < Build.VERSION_CODES.ICE_CREAM_SANDWICH) {

　　return holo;

　　}

　　if (targetSdkVersion < Build.VERSION_CODES.CUR_DEVELOPMENT) {

　　return dark;

　　}

　　return deviceDefault;

　　}

哎呀媽呀，這不就解釋了我們創建不同版本的App時默認主題不一樣的原因麼，哈哈，原來如果我們沒有設置主題Theme，系統會依據版本給我們選擇一個默認的主題，也就是上面這段代碼實現了該功能。

我們回過頭繼續回到ContextThemeWapprer的getTheme方法，當我們已經設置了Theme該方法就直接返回了，恰巧設置Theme的方法也在ContextThemeWapprer中。那這個方法啥時候被調運的呢？這一小節一開始我們就說了Activity的Theme設置有兩種方法，主動通過Java調運setTheme()和在AndroidManifest文件配置，AndroidManifest文件配置的Theme又是啥時候調運的呢？有了前面幾篇博客的鋪墊，我想你也一定能找到的，就在ActivityThread的performLaunchActivity()方法中，也就是我們通過startActivity()方法啟動Activity時就調運了Activity的setTheme方法，這個就不多說了，感興趣的自己進去看下就行了，也是流程憋大招，最終調用了activity.setTheme()完成了AndroidManifest文件的Theme獲取。

我們現在把目光回到ContextThemeWapprer的setTheme或者getTheme中調運的initializeTheme()方法中來看看，如下：

protected void onApplyThemeResource(Resources.Theme theme, int resid, boolean first) {
    theme.applyStyle(resid, true);
}

//大招！！！！！！！
private void initializeTheme() {
    //這就解釋了為何setTheme必須在setContentView前調運，不多解釋了，很明白了吧！！！！！！！！
    final boolean first = mTheme == null;
    if (first) {
        mTheme = getResources().newTheme();
        Resources.Theme theme = getBaseContext().getTheme();
        if (theme != null) {
            mTheme.setTo(theme);
        }
    }
    onApplyThemeResource(mTheme, mThemeResource, first);
}

這個方法就解釋了為何setTheme必須在setContentView前調運。最終通過onApplyThemeResource調運Resources.Theme的方法進行了設置，如下：
 

/**
 * Place new attribute values into the theme.  The style resource
 * specified by resid will be retrieved from this Theme's
 * resources, its values placed into the Theme object.
 * 
 * 

The semantics of this function depends on the force * argument: If false, only values that are not already defined in * the theme will be copied from the system resource; otherwise, if * any of the style's attributes are already defined in the theme, the * current values in the theme will be overwritten. * * @param resId The resource ID of a style resource from which to * obtain attribute values. * @param force If true, values in the style resource will always be * used in the theme; otherwise, they will only be used * if not already defined in the theme. */ public void applyStyle(int resId, boolean force) { AssetManager.applyThemeStyle(mTheme, resId, force); mThemeResId = resId; mKey.append(resId, force); }

到此注釋也說明了一些概念，關於AssetManager的應用又是另一個大話題了，這裡先不展開討論，我們只用知道到此一個Theme就選擇完成了，還有就是一個Theme的是怎麼被選擇出來的，當然對於Dialog等Window的Theme也是一個樣子，這裡不多說明，感興趣的自行腦補即可。

到現在為止我們已經找到了Theme是怎麼來的了，下來我們需要回到我們這一小節開頭部分的源碼分析，也就是Resources的obtainStyledAttributes()方法，還記得我們最終傳遞了com.android.internal.R.styleable.Window進行獲取該style麼。這貨不就是FW中res的attr.xml中自定義的屬性麼，如下：

    
    
    ......
    

可以看見，Style、Theme其實就是一組自定義的內置在Android系統資源中的屬性集合，而這裡唯一比較特殊的就是這些定義的屬性沒有聲明format字段。其實在Android中如果某個自定義屬性沒有聲明format屬性則意味著該屬性已經定義過，這裡只是別名而已。在哪定義的呢？當然還是attr中哇，屬性麼，自然只能在這了，找找看發下如下：

    ......
    
    
    
    ......

原來Theme屬性集才是這貨的正身哇，哈哈。有了這些屬性集在themes.xml中的Theme style就是對上面這些屬性的設置值了，如下樣例：

哈哈，有沒有覺得和App層開發自定義attr和style一樣呢，原來系統也是這麼干的，哈哈！

到此我們已經知道Theme是怎麼來的，其中的attr是怎麼定義及設置的，下面我們就回到PhoneWindow的generateLayout(DecorView decor) 方法來看下萬事俱備以後的應用大雜燴即可，如下：

protected ViewGroup generateLayout(DecorView decor) {
    //上面已經分析過了，獲取Theme及Theme中Style定義的attr的屬性，這裡獲取Window的屬性
    TypedArray a = getWindowStyle();
    //獲取是否floating的窗口，也就是是否Dialog
    mIsFloating = a.getBoolean(R.styleable.Window_windowIsFloating, false);
    ......
    //各種屬性獲取及feature、flag設置
    if (a.getBoolean(R.styleable.Window_windowNoTitle, false)) {
        requestFeature(FEATURE_NO_TITLE);
    } else if (a.getBoolean(R.styleable.Window_windowActionBar, false)) {
        // Don't allow an action bar if there is no title.
        requestFeature(FEATURE_ACTION_BAR);
    }
    ......
    if (a.getBoolean(R.styleable.Window_windowFullscreen, false)) {
        setFlags(FLAG_FULLSCREEN, FLAG_FULLSCREEN & (~getForcedWindowFlags()));
    }

    // Inflate the window decor.
    //依據Theme及feature、flag獲取一個匹配的layoutResourceId資源布局
    int layoutResource;
    int features = getLocalFeatures();
    // System.out.println("Features: 0x" + Integer.toHexString(features));
    if ((features & (1 << FEATURE_SWIPE_TO_DISMISS)) != 0) {
        layoutResource = R.layout.screen_swipe_dismiss;
    } else if ((features & ((1 << FEATURE_LEFT_ICON) | (1 << FEATURE_RIGHT_ICON))) != 0) {
        if (mIsFloating) {
            TypedValue res = new TypedValue();
            getContext().getTheme().resolveAttribute(
                    R.attr.dialogTitleIconsDecorLayout, res, true);
            layoutResource = res.resourceId;
        } else {
            layoutResource = R.layout.screen_title_icons;
        }
        // XXX Remove this once action bar supports these features.
        removeFeature(FEATURE_ACTION_BAR);
        // System.out.println("Title Icons!");
    }
    ......
    //將獲取到的資源id布局文件inflate成View添加到DectorView中，同時將mContentRoot賦值為當前resourceId View
    View in = mLayoutInflater.inflate(layoutResource, null);
    decor.addView(in, new ViewGroup.LayoutParams(MATCH_PARENT, MATCH_PARENT));
    mContentRoot = (ViewGroup) in;
    //找到contentParent返回使用，至此關於Window的屬性基本應用完畢
    ViewGroup contentParent = (ViewGroup)findViewById(ID_ANDROID_CONTENT);
    ......
    return contentParent;
}

哈哈，整明白了吧，到此就是整個Android關於Theme、Style的核心由來、流程、實現、使用的過程，相信有了上面這些知識後在使用Theme、Style時你該不會繼續蒙圈了吧，加油。

總結

基礎也整理了，源碼也簡單分析了，雖然上面主要是圍繞Android的Theme與Style來敘述解釋的，但是對於整個Android的res資源都是適用的，所以關於其他資源文中也給出了相關鏈接，感興趣的自行腦補即可。

由此可見，Theme實質是style，style實質是系統已經幫忙我們預定義很多attr，我們只用按照規則使用即可，不懂時翻看API和源碼即可，其他加載流程是通過Context與Window框架及Resource進行組合交互判斷處理應用。