? ? ? 在前文中，我們分析了Android應用程序窗口的運行上下文環(huán)境的創(chuàng)建過程。由此可知，每一個Activity組件都有一個關聯(lián)的ContextImpl對象，同時，它還關聯(lián)有一個Window對象，用來描述一個具體的應用程序窗口。由此又可知，Activity只不過是一個高度抽象的UI組件，它的具體UI實現(xiàn)其實是由其它的一系列對象來實現(xiàn)的。在本文中，我們就將詳細分析Android應用程序窗口對象的創(chuàng)建過程。

? ? ? 從前面Android應用程序窗口（Activity）實現(xiàn)框架簡要介紹和學習計劃一文可以知道，在PHONE平臺上，與Activity組件所關聯(lián)的窗口對象的實際類型為PhoneWindow，后者是從Window類繼承下來的。Activity、Window和PhoneWindow三個類的關系可以參考Android應用程序窗口（Activity）實現(xiàn)框架簡要介紹和學習計劃一文中的圖3和圖5。為了方便接下來描述類型為PhoneWindow的應用程序窗口的創(chuàng)建過程，我們將這兩個圖拿過來，如以下的圖1和圖2所示：

圖1 Activity和Window的類關系圖

圖2 Window和PhoneWindow的類關系圖

? ? ? 上述兩個圖中所涉及到的類的描述可以參考Android應用程序窗口（Activity）實現(xiàn)框架簡要介紹和學習計劃一文，本文主要從Android應用程序窗口的創(chuàng)建過程來理解Activity、Window和PhoneWindow三個類的關系。

? ? ? 從Android應用程序窗口（Activity）的運行上下文環(huán)境（Context）的創(chuàng)建過程分析一文又可以知道，與Activity組件所關聯(lián)的一個PhoneWindow對象是從Activity類的成員函數(shù)attach中創(chuàng)建的，如圖3所示：

圖3 Android應用程序窗口的創(chuàng)建過程

? ? ? 這個過程可以分為9個步驟，接下來我們就詳細分析每一個步驟。

? ? ? Step 1. Activity.attach

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

public?class?Activity?extends?ContextThemeWrapper ????????implements?LayoutInflater.Factory, ????????Window.Callback, KeyEvent.Callback, ????????OnCreateContextMenuListener, ComponentCallbacks { ????......? ??????????????????????????????????????????????????????? ????private?Window mWindow;? ????...... ??????????????????????????????????????????????????????? ????final?void?attach(Context context, ActivityThread aThread, ????????????Instrumentation instr, IBinder token,?int?ident, ????????????Application application, Intent intent, ActivityInfo info, ????????????CharSequence title, Activity parent, String id, ????????????Object lastNonConfigurationInstance, ????????????HashMap<String,Object> lastNonConfigurationChildInstances, ????????????Configuration config) { ????????...... ??????????????????????????????????????????????????????? ????????mWindow = PolicyManager.makeNewWindow(this); ????????mWindow.setCallback(this); ????????if?(info.softInputMode != WindowManager.LayoutParams.SOFT_INPUT_STATE_UNSPECIFIED) { ????????????mWindow.setSoftInputMode(info.softInputMode); ????????} ????????...... ??????????????????????????????????????????????????????? ????????mWindow.setWindowManager(null, mToken, mComponent.flattenToString()); ????????...... ????????????????????????????????????????????????????????? ????} ??????????????????????????????????????????????????????? ????...... }

? ? ? ?這個函數(shù)定義在文件frameworks/base/core/java/android/app/Activity.java中。

? ? ? ?在前面Android應用程序窗口（Activity）的運行上下文環(huán)境（Context）的創(chuàng)建過程分析一文中，我們已經(jīng)分析過這個函數(shù)的實現(xiàn)了，這里我們只關注與應用程序窗口創(chuàng)建相關的代碼。

? ? ? ?函數(shù)首先調(diào)用PolicyManager類的靜態(tài)成員函數(shù)makeNewWindow來創(chuàng)建一個類型為PhoneWindow的應用程序窗口，并且保存在Activity類的成員變量mWindow中。有了這個類型為PhoneWindow的應用程序窗口，函數(shù)接下來還會調(diào)用它的成員函數(shù)setCallback、setSoftInputMode和setWindowManager來設置窗口回調(diào)接口、軟鍵盤輸入?yún)^(qū)域的顯示模式和本地窗口管理器。

? ? ? ?PhoneWindow類的成員函數(shù)setCallback、setSoftInputMode和setWindowManager都是從父類Window繼承下來的，因此，接下來我們就繼續(xù)分析PolicyManager類的靜態(tài)成員函數(shù)makeNewWindow，以及Window類的成員函數(shù)setCallback、setSoftInputMode和setWindowManager的實現(xiàn)。

? ? ? ?Step 2. PolicyManager.makeNewWindow

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

public?final?class?PolicyManager { ????private?static?final?String POLICY_IMPL_CLASS_NAME = ????????"com.android.internal.policy.impl.Policy"; ????private?static?final?IPolicy sPolicy; ????static?{ ????????// Pull in the actual implementation of the policy at run-time ????????try?{ ????????????Class policyClass = Class.forName(POLICY_IMPL_CLASS_NAME); ????????????sPolicy = (IPolicy)policyClass.newInstance(); ????????}?catch?(ClassNotFoundException ex) { ????????????throw?new?RuntimeException( ????????????????????POLICY_IMPL_CLASS_NAME +?" could not be loaded", ex); ????????}?catch?(InstantiationException ex) { ????????????throw?new?RuntimeException( ????????????????????POLICY_IMPL_CLASS_NAME +?" could not be instantiated", ex); ????????}?catch?(IllegalAccessException ex) { ????????????throw?new?RuntimeException( ????????????????????POLICY_IMPL_CLASS_NAME +?" could not be instantiated", ex); ????????} ????} ????...... ????// The static methods to spawn new policy-specific objects ????public?static?Window makeNewWindow(Context context) { ????????return?sPolicy.makeNewWindow(context); ????} ????...... }

? ? ? 這個函數(shù)定義在文件frameworks/base/core/java/com/android/internal/policy/PolicyManager.java中。

? ? ? PolicyManager是一個窗口管理策略類，它在第一次被使用的時候，就會創(chuàng)建一個Policy類實例，并且保存在靜態(tài)成員變量sPolicy中，以后PolicyManager類的窗口管理策略就是通過這個Policy類實例來實現(xiàn)的，例如，PolicyManager類的靜態(tài)成員函數(shù)makeNewWindow就是通過調(diào)用這個Policy類實例的成員函數(shù)makeNewWindow來創(chuàng)建一個具體的應用程序窗口的。

? ? ? 接下來，我們就繼續(xù)分析Policy類的成員函數(shù)makeNewWindow的實現(xiàn)。

? ? ? Step 3. Policy.makeNewWindow

1 2 3 4 5 6 7 8

public?class?Policy?implements?IPolicy { ????...... ????public?PhoneWindow makeNewWindow(Context context) { ????????return?new?PhoneWindow(context); ????} ???????????????????????????????????????????? ????...... }

? ? ? ?這個函數(shù)定義在文件frameworks/base/policy/src/com/android/internal/policy/impl/Policy.java中。

? ? ? ?Policy類的成員函數(shù)makeNewWindow的實現(xiàn)很簡單，它只是創(chuàng)建了一個PhoneWindow對象，然后返回給調(diào)用者。

? ? ? ?接下來，我們就繼續(xù)分析PhoneWindow類的構造函數(shù)的實現(xiàn)，以便可以了解一個類型為PhoneWindow的應用程序窗口的創(chuàng)建過程。

? ? ? ?Step 4. new PhoneWindow

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

public?class?PhoneWindow?extends?Window?implements?MenuBuilder.Callback { ????...... ????// This is the top-level view of the window, containing the window decor. ????private?DecorView mDecor; ????// This is the view in which the window contents are placed. It is either ????// mDecor itself, or a child of mDecor where the contents go. ????private?ViewGroup mContentParent; ????...... ????private?LayoutInflater mLayoutInflater; ????...... ????public?PhoneWindow(Context context) { ????????super(context); ????????mLayoutInflater = LayoutInflater.from(context); ????} ????...... }

? ? ? 這個函數(shù)定義在文件frameworks/base/policy/src/com/android/internal/policy/impl/PhoneWindow.java中。

? ? ? PhoneWindow類的構造函數(shù)很簡單，它首先調(diào)用父類Window的構造函數(shù)來執(zhí)行一些初始化操作，接著再調(diào)用LayoutInflater的靜態(tài)成員函數(shù)from創(chuàng)建一個LayoutInflater實例，并且保存在成員變量mLayoutInflater中。這樣，PhoneWindow類以后就可以通過成員變量mLayoutInflater來創(chuàng)建應用程序窗口的視圖，這個視圖使用類型為DecorView的成員變量mDecor來描述。PhoneWindow類還有另外一個類型為ViewGroup的成員變量mContentParent，用來描述一個視圖容器，這個容器存放的就是成員變量mDecor所描述的視圖的內(nèi)容，不過這個容器也有可能指向的是mDecor本身。在后面的文章中，我們再詳細分析類型為PhoneWindow的應用程序窗口的視圖的創(chuàng)建過程。

? ? ?Window的構造函數(shù)定義在文件frameworks/base/core/java/android/view/Window.java中，它的實現(xiàn)很簡單，只是初始化了其成員變量mContext，如下所示：

1 2 3 4 5 6 7 8 9 10

public?abstract?class?Window { ????...... ????private?final?Context mContext; ????...... ????public?Window(Context context) { ????????mContext = context; ????} ????????????????????????????????????? ????...... }

? ? ? 從前面的調(diào)用過程可以知道，參數(shù)context描述的是正在啟動的Activity組件，將它保存在Window類的成員變量mContext之后，Window類就可以通過它來訪問與Activity組件相關的資源了。

? ? ? 這一步執(zhí)行完成之后，回到前面的Step 1中，即Activity類的成員函數(shù)attach中，接下來就會繼續(xù)調(diào)用前面所創(chuàng)建的PhoneWindow對象從父類Window繼承下來的成員函數(shù)setCallback來設置窗口回調(diào)接口，因此，接下來我們就繼續(xù)分析Window類的成員函數(shù)setCallback的實現(xiàn)。

? ? ? Step 5. Window.setCallback

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

public?abstract?class?Window { ????...... ????private?Callback mCallback; ????...... ????/** ?????* Set the Callback interface for this window, used to intercept key ?????* events and other dynamic operations in the window. ?????* ?????* @param callback The desired Callback interface. ?????*/ ????public?void?setCallback(Callback callback) { ????????mCallback = callback; ????} ????????????????????????????????? ????...... }

? ? ? ?這個函數(shù)定義在文件frameworks/base/core/java/android/view/Window.java中。

? ? ? ?正在啟動的Activity組件會將它所實現(xiàn)的一個Callback接口設置到與它所關聯(lián)的一個PhoneWindow對象的父類Window的成員變量mCallback中去，這樣當這個PhoneWindow對象接收到系統(tǒng)給它分發(fā)的IO輸入事件，例如，鍵盤和觸摸屏事件，轉(zhuǎn)發(fā)給與它所關聯(lián)的Activity組件處理，這一點可以參考前面Android應用程序鍵盤（Keyboard）消息處理機制分析一文。

? ? ? ?這一步執(zhí)行完成之后，回到前面的Step 1中，即Activity類的成員函數(shù)attach中，接下來就會繼續(xù)調(diào)用前面所創(chuàng)建的PhoneWindow對象從父類Window繼承下來的成員函數(shù)setSoftInputMode來設置應用程序窗口的軟鍵盤輸入?yún)^(qū)域的顯示模式，因此，接下來我們就繼續(xù)分析Window類的成員函數(shù)setSoftInputMode的實現(xiàn)。

? ? ? ?Step 6. Window.setSoftInputMode

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

public?abstract?class?Window { ????...... ????private?boolean?mHasSoftInputMode =?false; ????...... ????public?void?setSoftInputMode(int?mode) { ????????final?WindowManager.LayoutParams attrs = getAttributes(); ????????if?(mode != WindowManager.LayoutParams.SOFT_INPUT_STATE_UNSPECIFIED) { ????????????attrs.softInputMode = mode; ????????????mHasSoftInputMode =?true; ????????}?else?{ ????????????mHasSoftInputMode =?false; ????????} ????????if?(mCallback !=?null) { ????????????mCallback.onWindowAttributesChanged(attrs); ????????} ????} ????...... }

? ? ? 這個函數(shù)定義在文件frameworks/base/core/java/android/view/Window.java中。

? ? ? 參數(shù)mode有SOFT_INPUT_STATE_UNSPECIFIED、SOFT_INPUT_STATE_UNCHANGED、SOFT_INPUT_STATE_HIDDEN、SOFT_INPUT_STATE_ALWAYS_HIDDEN、SOFT_INPUT_STATE_VISIBLE和SOFT_INPUT_STATE_ALWAYS_VISIBLE一共六個取值，用來描述窗口的軟鍵盤輸入?yún)^(qū)域的顯示模式，它們的含義如下所示：

? ? ?1.?SOFT_INPUT_STATE_UNSPECIFIED：沒有指定軟鍵盤輸入?yún)^(qū)域的顯示狀態(tài)。

? ? ?2.?SOFT_INPUT_STATE_UNCHANGED：不要改變軟鍵盤輸入?yún)^(qū)域的顯示狀態(tài)。

? ? ?3.?SOFT_INPUT_STATE_HIDDEN：在合適的時候隱藏軟鍵盤輸入?yún)^(qū)域，例如，當用戶導航到當前窗口時。

? ? ?4.?SOFT_INPUT_STATE_ALWAYS_HIDDEN：當窗口獲得焦點時，總是隱藏軟鍵盤輸入?yún)^(qū)域。

? ? ?5.?SOFT_INPUT_STATE_VISIBLE：在合適的時候顯示軟鍵盤輸入?yún)^(qū)域，例如，當用戶導航到當前窗口時。

? ? ?6.?SOFT_INPUT_STATE_ALWAYS_VISIBLE：當窗口獲得焦點時，總是顯示軟鍵盤輸入?yún)^(qū)域。

? ? ?當參數(shù)mode的值不等于SOFT_INPUT_STATE_UNSPECIFIED時，就表示當前窗口被指定軟鍵盤輸入?yún)^(qū)域的顯示模式，這時候Window類的成員函數(shù)setSoftInputMode就會將成員變量mHasSoftInputMode的值設置為true，并且將這個顯示模式保存在用來描述窗口布局屬性的一個WindowManager.LayoutParams對象的成員變量softInputMode中，否則的話，就會將成員變量mHasSoftInputMode的值設置為false。

? ? ?設置完成窗口的軟鍵盤輸入?yún)^(qū)域的顯示模式之后，如果Window類的成員變量mCallback指向了一個窗口回調(diào)接口，那么Window類的成員函數(shù)setSoftInputMode還會調(diào)用它的成員函數(shù)onWindowAttributesChanged來通知與窗口所關聯(lián)的Activity組件，它的窗口布局屬性發(fā)生了變化。

? ? ? 這一步執(zhí)行完成之后，回到前面的Step 1中，即Activity類的成員函數(shù)attach中，接下來就會繼續(xù)調(diào)用前面所創(chuàng)建的PhoneWindow對象從父類Window繼承下來的成員函數(shù)setWindowManager來設置應用程序窗口的本地窗口管理器，因此，接下來我們就繼續(xù)分析Window類的成員函數(shù)setWindowManager的實現(xiàn)。

? ? ? Step 7. Window.setWindowManager

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public?abstract?class?Window { ????...... ????private?WindowManager mWindowManager; ????private?IBinder mAppToken; ????private?String mAppName; ????...... ????public?void?setWindowManager(WindowManager wm, ????????????IBinder appToken, String appName) { ????????mAppToken = appToken; ????????mAppName = appName; ????????if?(wm ==?null) { ????????????wm = WindowManagerImpl.getDefault(); ????????} ????????mWindowManager =?new?LocalWindowManager(wm); ????} ????...... }

? ? ? 這個函數(shù)定義在文件frameworks/base/core/java/android/view/Window.java中。

? ? ? 參數(shù)appToken用來描述當前正在處理的窗口是與哪一個Activity組件關聯(lián)的，它是一個Binder代理對象，引用了在ActivityManagerService這一側(cè)所創(chuàng)建的一個類型為ActivityRecord的Binder本地對象。從前面Android應用程序的Activity啟動過程簡要介紹和學習計劃一系列文章可以知道，每一個啟動起來了的Activity組件在ActivityManagerService這一側(cè)，都有一個對應的ActivityRecord對象，用來描述該Activity組件的運行狀態(tài)。這個Binder代理對象會被保存在Window類的成員變量mAppToken中，這樣當前正在處理的窗口就可以知道與它所關聯(lián)的Activity組件是什么。

? ? ? 參數(shù)appName用來描述當前正在處理的窗口所關聯(lián)的Activity組件的名稱，這個名稱會被保存在Window類的成員變量mAppName中。

? ? ? 參數(shù)wm用來描述一個窗口管理器。從前面的調(diào)用過程可以知道， 這里傳進來的參數(shù)wm的值等于null，因此，函數(shù)首先會調(diào)用WindowManagerImpl類的靜態(tài)成員函數(shù)getDefault來獲得一個默認的窗口管理器。有了這個窗口管理器之后，函數(shù)接著再使用它來創(chuàng)建一個本地窗口管理器，即一個LocalWindowManager對象，用來維護當前正在處理的應用程序窗口。

? ? ? 接下來，我們首先分析WindowManagerImpl類的靜態(tài)成員函數(shù)getDefault的實現(xiàn)，接著再分析本地窗口管理器的創(chuàng)建過程，即LocalWindowManager類的構造函數(shù)的實現(xiàn)。

? ? ? Step 8. WindowManagerImpl.getDefault

1 2 3 4 5 6 7 8 9 10

public?class?WindowManagerImpl?implements?WindowManager { ????...... ????public?static?WindowManagerImpl getDefault() ????{ ????????return?mWindowManager; ????} ???????????????? ????...... ????private?static?WindowManagerImpl mWindowManager =?new?WindowManagerImpl(); }

? ? ?這個函數(shù)定義在文件frameworks/base/core/java/android/view/WindowManagerImpl.java中。

? ? ? WindowManagerImpl類的靜態(tài)成員函數(shù)getDefault的實現(xiàn)很簡單，它只是將靜態(tài)成員變量mWindowManager所指向的一個WindowManagerImpl對象返回給調(diào)用者，這個WindowManagerImpl對象實現(xiàn)了WindowManager接口，因此，它就可以用來管理應用程序窗口。

? ? ?這一步執(zhí)行完成之后，回到前面的Step 7中，即Window類的成員函數(shù)setWindowManager中，接下來就會使用前面所獲得一個WindowManagerImpl對象來創(chuàng)建一個本地窗口管理器，即一個LocalWindowManager對象。

? ? ?Step 9. new LocalWindowManager

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

public?abstract?class?Window { ????...... ????private?final?Context mContext; ????...... ????private?class?LocalWindowManager?implements?WindowManager { ????????LocalWindowManager(WindowManager wm) { ????????????mWindowManager = wm; ????????????mDefaultDisplay = mContext.getResources().getDefaultDisplay( ????????????????????mWindowManager.getDefaultDisplay()); ????????} ????????...... ????????private?final?WindowManager mWindowManager; ????????private?final?Display mDefaultDisplay; ????} ????...... }

? ? ? 這個函數(shù)定義在文件frameworks/base/core/java/android/view/Window.java中。

? ? ? LocalWindowManager類的構造函數(shù)首先將參數(shù)wm所描述的一個WindowManagerImpl對象保存它的成員變量mWindowManager中，這樣以后就將窗口管理工作交給它來處理。

? ? ? LocalWindowManager類的構造函數(shù)接著又通過成員變量mWindowManager所描述的一個WindowManagerImpl對象的成員函數(shù)getDefaultDisplay來獲得一個Display對象，用來描述系統(tǒng)屏幕屬性。

? ? ? 由于前面所獲得的Display對象描述的是全局的屏幕屬性，而當前正在處理的窗口可能配置了一些可自定義的屏幕屬性，因此，LocalWindowManager類的構造函數(shù)需要進一步地調(diào)整前面所獲得的Display對象所描述的屏幕屬性，以便可以適合當前正在處理的窗口使用。LocalWindowManager類的構造函數(shù)首先通過外部類Window的成員變量mContext的成員函數(shù)getResources來獲得一個Resources對象，接著再調(diào)用這個Resources對象的成員函數(shù)getDefaultDisplay來調(diào)整前面所獲得的Display對象所描述的屏幕屬性。最終調(diào)整完成的Display對象就保存在LocalWindowManager類的成員變量mDefaultDisplay中。

? ? ? 從前面的Step 4可以知道，類Window的成員變量mContext描述的是與當前窗口所關聯(lián)的一個Activity組件。Activity類的成員函數(shù)getResources是從父類ContextWrapper繼續(xù)下來的，它實現(xiàn)在文件frameworks/base/core/java/android/content/ContextWrapper.java中，如下所示：

1 2 3 4 5 6 7 8 9 10

public?class?ContextWrapper?extends?Context { ????Context mBase; ????...... ????@Override ????public?Resources getResources() ????{ ????????return?mBase.getResources(); ????} ????...... }

? ? ? 從前面Android應用程序窗口（Activity）的運行上下文環(huán)境（Context）的創(chuàng)建過程分析一文可以知道，ContextWrapper類的成員變量mBase指向的是一個ContextImpl對象，用來描述一個Activity組件的運行上下文環(huán)境。通過調(diào)用這個ContextImpl對象的成員函數(shù)getResources，就可以獲得與一個Resources對象，而通過這個Resources對象，就可以訪問一個Activity組件的資源信息，從而可以獲得它所配置的屏幕屬性。

? ? ? 至此，我們就分析完成一個Activity組件所關聯(lián)的應用程序窗口對象的創(chuàng)建過程了。從分析的過程可以知道：

? ? ?1. 一個Activity組件所關聯(lián)的應用程序窗口對象的類型為PhoneWindow。

? ? ?2. 這個類型為PhoneWindow的應用程序窗口是通過一個類型為LocalWindowManager的本地窗口管理器來維護的。

? ? ?3. 這個類型為LocalWindowManager的本地窗口管理器又是通過一個類型為WindowManagerImpl的窗口管理器來維護應用程序窗口的。

? ? ?4. 這個類型為PhoneWindow的應用程序窗口內(nèi)部有一個類型為DecorView的視圖對象，這個視圖對象才是真正用來描述一個Activity組件的UI的。

? ? ?在接下來的一篇文章中，我們將繼續(xù)分析應用程序窗口內(nèi)部的視圖對象的創(chuàng)建過程，敬請關注！

本文轉(zhuǎn)自 Luoshengyang 51CTO博客，原文鏈接：http://blog.51cto.com/shyluo/1242879，如需轉(zhuǎn)載請自行聯(lián)系原作者

總結

以上是生活随笔為你收集整理的Android应用程序窗口（Activity）的窗口对象（Window）的创建过程分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。