Android窗口管理服务WindowManagerService计算Activity窗口大小的过程分析
? ? ? ? 在Android系統(tǒng)中，Activity窗口的大小是由WindowManagerService服務(wù)來計(jì)算的。WindowManagerService服務(wù)會(huì)根據(jù)屏幕及其裝飾區(qū)的大小來決定Activity窗口的大小。一個(gè)Activity窗口只有知道自己的大小之后，才能對(duì)它里面的UI元素進(jìn)行測(cè)量、布局以及繪制。本文將詳細(xì)分析WindowManagerService服務(wù)計(jì)算Activity窗口大小的過程。
《Android系統(tǒng)源代碼情景分析》一書正在進(jìn)擊的程序員網(wǎng)（http://0xcc0xcd.com）中連載，點(diǎn)擊進(jìn)入！
? ? ? ? 一般來說，Activity窗口的大小等于整個(gè)屏幕的大小，但是它并不占據(jù)著整塊屏幕。為了理解這一點(diǎn)，我們首先分析一下Activity窗口的區(qū)域是如何劃分的。
? ? ? ? 我們知道，Activity窗口的上方一般會(huì)有一個(gè)狀態(tài)欄，用來顯示3G信號(hào)、電量使用等圖標(biāo)，如圖1所示。
圖1 Activity窗口的Content區(qū)域示意圖
? ? ? ?從Activity窗口剔除掉狀態(tài)欄所占用的區(qū)域之后，所得到的區(qū)域就稱為內(nèi)容區(qū)域（Content Region）。顧名思義，內(nèi)容區(qū)域就是用來顯示Activity窗口的內(nèi)容的。我們?cè)俪橄笠幌?#xff0c;假設(shè)Activity窗口的四周都有一塊類似狀態(tài)欄的區(qū)域，那么將這些區(qū)域剔除之后，得到中間的那一塊區(qū)域就稱為內(nèi)容區(qū)域，而被剔除出來的區(qū)域所組成的區(qū)域就稱為內(nèi)容邊襯區(qū)域（Content Insets）。Activity窗口的內(nèi)容邊襯區(qū)域可以用一個(gè)四元組（content-left, content-top, content-right, content-bottom）來描述，其中，content-left、content-right、content-top、content-bottom分別用來描述內(nèi)容區(qū)域與窗口區(qū)域的左右上下邊界距離。
? ? ? ?我們還知道，Activity窗口有時(shí)候需要顯示輸入法窗口，如圖2所示。
圖2?Activity窗口的Visible區(qū)域示意圖
? ? ? ? 這時(shí)候Activity窗口的內(nèi)容區(qū)域的大小有可能沒有發(fā)生變化，這取決于它的Soft Input Mode。我們假設(shè)Activity窗口的內(nèi)容區(qū)域沒有發(fā)生變化，但是它在底部的一些區(qū)域被輸入法窗口遮擋了，即它在底部的一些內(nèi)容是不可見的。從Activity窗口剔除掉狀態(tài)欄和輸入法窗口所占用的區(qū)域之后，所得到的區(qū)域就稱為可見區(qū)域（Visible Region）。同樣，我們?cè)俪橄笠幌?#xff0c;假設(shè)Activity窗口的四周都有一塊類似狀態(tài)欄和輸入法窗口的區(qū)域，那么將這些區(qū)域剔除之后，得到中間的那一塊區(qū)域就稱為可見區(qū)域，而被剔除出來的區(qū)域所組成的區(qū)域就稱為可見邊襯區(qū)域（Visible Insets）。Activity窗口的可見邊襯區(qū)域可以用一個(gè)四元組（visible-left, visible-top, visible-right, visible-bottom）來描述，其中，visible-left、visible-right、visible-top、visible-bottom分別用來描述可見區(qū)域與窗口區(qū)域的左右上下邊界距離。
? ? ? ? 在大多數(shù)情況下，Activity窗口的內(nèi)容區(qū)域和可見區(qū)域的大小是一致的，而狀態(tài)欄和輸入法窗口所占用的區(qū)域又稱為屏幕裝飾區(qū)。理解了這些概念之后，我們就可以推斷，WindowManagerService服務(wù)實(shí)際上就是需要根據(jù)屏幕以及可能出現(xiàn)的狀態(tài)欄和輸入法窗口的大小來計(jì)算出Activity窗口的整體大小及其內(nèi)容區(qū)域邊襯和可見區(qū)域邊襯的大小。有了這三個(gè)數(shù)據(jù)之后，Activity窗口就可以對(duì)它里面的UI元素進(jìn)行測(cè)量、布局以及繪制等操作了。
? ? ? ? 從前面Android應(yīng)用程序窗口（Activity）的繪圖表面（Surface）的創(chuàng)建過程分析一文可以知道，應(yīng)用程序進(jìn)程是從ViewRoot類的成員函數(shù)performTraversals開始，向WindowManagerService服務(wù)請(qǐng)求計(jì)算一個(gè)Activity窗口的大小的，因此，接下來我們就從ViewRoot類的成員函數(shù)performTraversals開始分析一個(gè)Activity窗口大小的計(jì)算過程，如圖3所示。
圖3 Activity窗口大小的計(jì)算過程
? ? ? ? ?這個(gè)過程可以分為11個(gè)步驟，接下來我們就詳細(xì)分析每一個(gè)步驟。
? ? ? ? ?Step 1. ViewRoot.performTraversals
? ? ? ? ?這個(gè)函數(shù)定義在文件frameworks/base/core/java/android/view/ViewRoot.java中，它的實(shí)現(xiàn)很復(fù)雜，一共有600-行，不過大部分代碼都是用來計(jì)算Activity窗口的大小的，我們分段來閱讀：
public final class ViewRoot extends Handler implements ViewParent,View.AttachInfo.Callbacks {......private void performTraversals() {......final View host = mView;......int desiredWindowWidth;int desiredWindowHeight;int childWidthMeasureSpec;int childHeightMeasureSpec;......Rect frame = mWinFrame;if (mFirst) {......DisplayMetrics packageMetrics =mView.getContext().getResources().getDisplayMetrics();desiredWindowWidth = packageMetrics.widthPixels;desiredWindowHeight = packageMetrics.heightPixels;} else {desiredWindowWidth = frame.width();desiredWindowHeight = frame.height();if (desiredWindowWidth != mWidth || desiredWindowHeight != mHeight) {......windowResizesToFitContent = true;}}? ? ? ? 注意，Activity窗口當(dāng)前的寬度和高度是保存ViewRoot類的成員變量mWinFrame中的。ViewRoot類的另外兩個(gè)成員變量mWidth和mHeight也是用來描述Activity窗口當(dāng)前的寬度和高度的，但是它們的值是由應(yīng)用程序進(jìn)程上一次主動(dòng)請(qǐng)求WindowManagerService服務(wù)計(jì)算得到的，并且會(huì)一直保持不變到應(yīng)用程序進(jìn)程下一次再請(qǐng)求WindowManagerService服務(wù)來重新計(jì)算為止。Activity窗口的當(dāng)前寬度和高度有時(shí)候是被WindowManagerService服務(wù)主動(dòng)請(qǐng)求應(yīng)用程序進(jìn)程修改的，修改后的值就會(huì)保存在ViewRoot類的成員變量mWinFrame中，它們可能會(huì)與ViewRoot類的成員變量mWidth和mHeight的值不同。
? ? ? ? 如果Activity窗口是第一次被請(qǐng)求執(zhí)行測(cè)量、布局和繪制操作，即ViewRoot類的成員變量mFirst的值等于true，那么它的當(dāng)前寬度desiredWindowWidth和當(dāng)前高度desiredWindowHeight就等于屏幕的寬度和高度，否則的話，它的當(dāng)前寬度desiredWindowWidth和當(dāng)前高度desiredWindowHeight就等于保存在ViewRoot類的成員變量mWinFrame中的寬度和高度值。
? ? ? ??如果Activity窗口不是第一次被請(qǐng)求執(zhí)行測(cè)量、布局和繪制操作，并且Activity窗口主動(dòng)上一次請(qǐng)求WindowManagerService服務(wù)計(jì)算得到的寬度mWidth和高度mHeight不等于Activity窗口的當(dāng)前寬度desiredWindowWidth和當(dāng)前高度desiredWindowHeight，那么就說明Activity窗口的大小發(fā)生了變化，這時(shí)候變量windowResizesToFitContent的值就會(huì)被標(biāo)記為true，以便接下來可以對(duì)Activity窗口的大小變化進(jìn)行處理。
? ? ? ? 我們繼續(xù)往下閱讀代碼：
boolean insetsChanged = false;if (mLayoutRequested) {......if (mFirst) {host.fitSystemWindows(mAttachInfo.mContentInsets);......} else {if (!mAttachInfo.mContentInsets.equals(mPendingContentInsets)) {mAttachInfo.mContentInsets.set(mPendingContentInsets);host.fitSystemWindows(mAttachInfo.mContentInsets);insetsChanged = true;......}if (!mAttachInfo.mVisibleInsets.equals(mPendingVisibleInsets)) {mAttachInfo.mVisibleInsets.set(mPendingVisibleInsets);......}if (lp.width == ViewGroup.LayoutParams.WRAP_CONTENT|| lp.height == ViewGroup.LayoutParams.WRAP_CONTENT) {windowResizesToFitContent = true;DisplayMetrics packageMetrics =mView.getContext().getResources().getDisplayMetrics();desiredWindowWidth = packageMetrics.widthPixels;desiredWindowHeight = packageMetrics.heightPixels;}}childWidthMeasureSpec = getRootMeasureSpec(desiredWindowWidth, lp.width);childHeightMeasureSpec = getRootMeasureSpec(desiredWindowHeight, lp.height); ......host.measure(childWidthMeasureSpec, childHeightMeasureSpec);......}? ? ? ? 在分析這段代碼之前，我們首先解釋一下ViewRoot類的成員變量mAttachInfo和mPendingContentInsets、mPendingVisibleInsets。ViewRoot類的成員變量mAttachInfo指向的一個(gè)AttachInfo對(duì)象，這個(gè)AttachInfo對(duì)象用來描述Activity窗口的屬性，例如，這個(gè)AttachInfo對(duì)象的成員變量mContentInsets和mVisibleInsets分別用來描述Activity窗口上一次主動(dòng)請(qǐng)求WindowManagerService服務(wù)計(jì)算得到的內(nèi)容邊襯大小和可見邊襯大小，即Activity窗口的當(dāng)前內(nèi)容邊襯大小和可見邊襯大小。ViewRoot類的成員變量mPendingContentInsets和mPendingVisibleInsets也是用來描述Activity窗口的內(nèi)容邊襯大小和可見邊襯大小的，不過它們是由WindowManagerService服務(wù)主動(dòng)請(qǐng)求Activity窗口設(shè)置的，但是尚未生效。
? ? ? ? 我們分兩種情況來分析這段代碼。
? ? ? ? 第一種情況是Activity窗口是第一次被請(qǐng)求執(zhí)行測(cè)量、布局和繪制操作，即ViewRoot類的成員變量mFirst的值等于true，那么這段代碼在測(cè)量Activity窗口的頂層視圖host的大小之前，首先會(huì)調(diào)用這個(gè)頂層視圖host的成員函數(shù)fitSystemWindows來設(shè)置它的四個(gè)內(nèi)邊距（mPaddingLeft，mPaddingTop，mPaddingRight，mPaddingBottom）的大小設(shè)置為Activity窗口的初始化內(nèi)容邊襯大小。這樣做的目的是可以在Activity窗口的四周留下足夠的區(qū)域來放置可能會(huì)出現(xiàn)的系統(tǒng)窗口，也就是狀態(tài)欄和輸入法窗口。
? ? ? ? 第二種情況是Activity窗口不是第一次被請(qǐng)求執(zhí)行測(cè)量、布局和繪制操作，即ViewRoot類的成員變量mFirst的值等于false，那么這段代碼就會(huì)檢查Activity窗口是否被WindowManagerService服務(wù)主動(dòng)請(qǐng)求設(shè)置了一個(gè)新的內(nèi)容邊襯大小mPendingContentInsets和一個(gè)新的可見邊襯大小mPendingVisibleInsets。如果是的話，那么就會(huì)分別將它們保存在ViewRoot類的成員變量mAttachInfo所指向的一個(gè)AttachInfo對(duì)象的成員變量mContentInsets和成員變量mVisibleInsets中。注意，如果Activity窗口被WindowManagerService服務(wù)主動(dòng)請(qǐng)求設(shè)置了一個(gè)新的內(nèi)容邊襯大小mPendingContentInsets，那么這段代碼同時(shí)還需要同步調(diào)用Activity窗口的頂層視圖host的成員函數(shù)fitSystemWindows來將它的四個(gè)內(nèi)邊距（mPaddingLeft，mPaddingTop，mPaddingRight，mPaddingBottom）的大小設(shè)置為新的內(nèi)容邊襯大小，并且將變量insetsChanged的值設(shè)置為true，表明Activity窗口的內(nèi)容邊襯大小發(fā)生了變化。
? ? ? ? 在第二種情況下，如果Activity窗口的寬度被設(shè)置為ViewGroup.LayoutParams.WRAP_CONTENT或者高度被設(shè)置為ViewGroup.LayoutParams.WRAP_CONTENT，那么就意味著Activity窗口的大小要等于內(nèi)容區(qū)域的大小。但是由于Activity窗口的大小是需要覆蓋整個(gè)屏幕的，因此，這時(shí)候就會(huì)Activity窗口的當(dāng)前寬度desiredWindowWidth和當(dāng)前高度desiredWindowHeight設(shè)置為屏幕的寬度和高度。也就是說，如果我們將Activity窗口的寬度和高度設(shè)置為ViewGroup.LayoutParams.WRAP_CONTENT，實(shí)際上就意味著它的寬度和高度等于屏幕的寬度和高度。這種情況也意味著Acitivity窗口的大小發(fā)生了變化，因此，就將變量windowResizesToFitContent的值設(shè)置為true。
? ? ? ? 經(jīng)過上面的一系列處理之后，這段代碼就會(huì)調(diào)用ViewRoot類的成員函數(shù)getRootMeasureSpec來根據(jù)Activity窗口的當(dāng)前寬度和寬度測(cè)量規(guī)范以及高度和高度測(cè)量規(guī)范來計(jì)算得到它的頂層視圖host的寬度測(cè)量規(guī)范childWidthMeasureSpec和高度測(cè)量規(guī)范childHeightMeasureSpec。有了這兩個(gè)規(guī)范之后，就可以調(diào)用Activity窗口的頂層視圖host的成員函數(shù)measure來執(zhí)行大小測(cè)量的工作了。這個(gè)大小測(cè)量的過程可以參考前面Android應(yīng)用程序窗口（Activity）的測(cè)量（Measure）、布局（Layout）和繪制（Draw）過程分析一文。
? ? ? ?我們繼續(xù)往下閱讀代碼：
boolean windowShouldResize = mLayoutRequested && windowResizesToFitContent&& ((mWidth != host.mMeasuredWidth || mHeight != host.mMeasuredHeight)|| (lp.width == ViewGroup.LayoutParams.WRAP_CONTENT &&frame.width() < desiredWindowWidth && frame.width() != mWidth)|| (lp.height == ViewGroup.LayoutParams.WRAP_CONTENT &&frame.height() < desiredWindowHeight && frame.height() != mHeight));final boolean computesInternalInsets =attachInfo.mTreeObserver.hasComputeInternalInsetsListeners();? ? ? ?這段代碼主要是做兩件事情。
? ? ? ?第一件事情是檢查是否需要處理Activity窗口的大小變化事件。如果滿足以下條件，那么就需要處理，即將變量windowShouldResize的值設(shè)置為true：
? ? ? ?1. ViewRoot類的成員變量mLayoutRequest的值等于true，這說明應(yīng)用程序進(jìn)程正在請(qǐng)求對(duì)Activity窗口執(zhí)行一次測(cè)量、布局和繪制操作；
? ? ? ?2. 變量windowResizesToFitContent的值等于true，這說明前面檢測(cè)到了Activity窗口的大小發(fā)生了變化；
? ? ? ?3. 前面我們已經(jīng)Activity窗口的頂層視圖host的大小重新進(jìn)行了測(cè)量。如果測(cè)量出來的寬度host.mMeasuredWidth和高度host.mMeasuredHeight和Activity窗口的當(dāng)前寬度mWidth和高度mHeight一樣，那么即使條件1和條件2能滿足，那么也是可以認(rèn)為是Activity窗口的大小是沒有發(fā)生變化的。換句話說，只有當(dāng)測(cè)量出來的大小和當(dāng)前大小不一致時(shí)，才認(rèn)為Activity窗口大小發(fā)生了變化。另一方面，如果測(cè)量出來的大小和當(dāng)前大小一致，但是Activity窗口的大小被要求設(shè)置成WRAP_CONTENT，即設(shè)置成和屏幕的寬度desiredWindowWidth和高度desiredWindowHeight一致，但是WindowManagerService服務(wù)請(qǐng)求Activity窗口設(shè)置的寬度frame.width()和高度frame.height()與它們不一致，而且與Activity窗口上一次請(qǐng)求WindowManagerService服務(wù)計(jì)算的寬度mWidth和高度mHeight也不一致，那么也是認(rèn)為Activity窗口大小發(fā)生了變化的。
? ? ? ? 第二件事情是檢查Activity窗口是否需要指定有額外的內(nèi)容邊襯區(qū)域和可見邊襯區(qū)域。如果有的話，那么變量attachInfo所指向的一個(gè)AttachInfo對(duì)象的成員變量mTreeObserver所描述的一個(gè)TreeObserver對(duì)象的成員函數(shù)hasComputeInternalInsetsListerner的返回值ComputeInternalInsets就會(huì)等于true。Activity窗口指定額外的內(nèi)容邊襯區(qū)域和可見邊襯區(qū)域是為了放置一些額外的東西。
? ? ? ? 我們繼續(xù)往下閱讀代碼：
if (mFirst || windowShouldResize || insetsChanged|| viewVisibilityChanged || params != null) {if (viewVisibility == View.VISIBLE) {// If this window is giving internal insets to the window// manager, and it is being added or changing its visibility,// then we want to first give the window manager "fake"// insets to cause it to effectively ignore the content of// the window during layout. This avoids it briefly causing// other windows to resize/move based on the raw frame of the// window, waiting until we can finish laying out this window// and get back to the window manager with the ultimately// computed insets.insetsPending = computesInternalInsets&& (mFirst || viewVisibilityChanged);......}? ? ? ? 1. Activity窗口是第一次執(zhí)行測(cè)量、布局和繪制操作，即ViewRoot類的成員變量mFirst的值等于true。
? ? ? ? 2. 前面得到的變量windowShouldResize的值等于true，即Activity窗口的大小的確是發(fā)生了變化。
? ? ? ? 3. 前面得到的變量insetsChanged的值等于true，即Activity窗口的內(nèi)容區(qū)域邊襯發(fā)生了變化。
? ? ? ? 4.?Activity窗口的可見性發(fā)生了變化，即變量viewVisibilityChanged的值等于true。
? ? ? ? 5.?Activity窗口的屬性發(fā)生了變化，即變量params指向了一個(gè)WindowManager.LayoutParams對(duì)象。
? ? ? ? 在滿足上述條件之一，并且Activity窗口處于可見狀態(tài)，即變量viewVisibility的值等于View.VISIBLE，那么就需要檢查接下來請(qǐng)求WindowManagerService服務(wù)計(jì)算大小時(shí)，是否要告訴WindowManagerService服務(wù)它指定了額外的內(nèi)容區(qū)域邊襯和可見區(qū)域邊襯，但是這些額外的內(nèi)容區(qū)域邊襯和可見區(qū)域邊襯又還有確定。這種情況發(fā)生在Activity窗口第一次執(zhí)行測(cè)量、布局和繪制操作或者由不可見變化可見時(shí)。因此，當(dāng)前面得到的變量computesInternalInsets等于true時(shí)，即Activity窗口指定了額外的內(nèi)容區(qū)域邊襯和可見區(qū)域邊襯，那么就需要檢查ViewRoot類的成員變量mFirst或者變量viewVisibilityChanged的值是否等于true。如果這些條件能滿足，那么變量insetsPending的值就會(huì)等于true，表示Activity窗口有額外的內(nèi)容區(qū)域邊襯和可見區(qū)域邊襯等待指定。
? ? ? ? 我們繼續(xù)往下閱讀代碼：
boolean contentInsetsChanged = false;boolean visibleInsetsChanged;......try {......relayoutResult = relayoutWindow(params, viewVisibility, insetsPending);contentInsetsChanged = !mPendingContentInsets.equals(mAttachInfo.mContentInsets);visibleInsetsChanged = !mPendingVisibleInsets.equals(mAttachInfo.mVisibleInsets);if (contentInsetsChanged) {mAttachInfo.mContentInsets.set(mPendingContentInsets);host.fitSystemWindows(mAttachInfo.mContentInsets);......}if (visibleInsetsChanged) {mAttachInfo.mVisibleInsets.set(mPendingVisibleInsets);......}......} catch (RemoteException e) {}......attachInfo.mWindowLeft = frame.left;attachInfo.mWindowTop = frame.top;// !!FIXME!! This next section handles the case where we did not get the// window size we asked for. We should avoid this by getting a maximum size from// the window session beforehand.mWidth = frame.width();mHeight = frame.height();? ? ? ? 如果這次計(jì)算得到的Activity窗口的內(nèi)容區(qū)域邊襯大小mPendingContentInsets和可見區(qū)域邊襯大小mPendingVisibleInsets與上一次計(jì)算得到的不一致，即與ViewRoot類的成員變量mAttachInfo所指向的一個(gè)AttachInfo對(duì)象的成員變量mContentInsets和mVisibleInsets所描述的大小不一致，那么變量contentInsetsChanged和visibleInsetsChanged的值就會(huì)等于true，表示Activity窗口的內(nèi)容區(qū)域邊襯大小和可見區(qū)域邊襯大小發(fā)生了變化。
? ? ? ? 由于變量frame和ViewRoot類的成員變量mWinFrame引用的是同一個(gè)Rect對(duì)象，因此，這時(shí)候變量frame描述的也是Activity窗口請(qǐng)求WindowManagerService服務(wù)計(jì)算之后得到的大小。這段代碼分別將計(jì)算得到的Activity窗口的左上角坐標(biāo)保存在變量attachInfo所指向的一個(gè)AttachInfo對(duì)象的成員變量mWindowLeft和mWindowTop中，并且將計(jì)算得到的Activity窗口的寬度和高度保存在ViewRoot類的成員變量mWidth和mHeight中。
? ? ? ? 我們繼續(xù)往下閱讀代碼：
boolean focusChangedDueToTouchMode = ensureTouchModeLocally((relayoutResult&WindowManagerImpl.RELAYOUT_IN_TOUCH_MODE) != 0);if (focusChangedDueToTouchMode || mWidth != host.mMeasuredWidth|| mHeight != host.mMeasuredHeight || contentInsetsChanged) {childWidthMeasureSpec = getRootMeasureSpec(mWidth, lp.width);childHeightMeasureSpec = getRootMeasureSpec(mHeight, lp.height);......// Ask host how big it wants to behost.measure(childWidthMeasureSpec, childHeightMeasureSpec);// Implementation of weights from WindowManager.LayoutParams// We just grow the dimensions as needed and re-measure if// needs beint width = host.mMeasuredWidth;int height = host.mMeasuredHeight;boolean measureAgain = false;if (lp.horizontalWeight > 0.0f) {width += (int) ((mWidth - width) * lp.horizontalWeight);childWidthMeasureSpec = MeasureSpec.makeMeasureSpec(width,MeasureSpec.EXACTLY);measureAgain = true;}if (lp.verticalWeight > 0.0f) {height += (int) ((mHeight - height) * lp.verticalWeight);childHeightMeasureSpec = MeasureSpec.makeMeasureSpec(height,MeasureSpec.EXACTLY);measureAgain = true;}if (measureAgain) {......host.measure(childWidthMeasureSpec, childHeightMeasureSpec);}mLayoutRequested = true;}}? ? ? ? 1. Activity窗口的觸摸模式發(fā)生了變化，并且由此引發(fā)了Activity窗口當(dāng)前獲得焦點(diǎn)的控件發(fā)生了變化，即變量focusChangedDueToTouchMode的值等于true。這個(gè)檢查是通過調(diào)用ViewRoot類的成員函數(shù)ensureTouchModeLocally來實(shí)現(xiàn)的。
? ? ? ? 2. Activity窗口前面測(cè)量出來的寬度host.mMeasuredWidth和高度host.mMeasuredHeight不等于WindowManagerService服務(wù)計(jì)算出來的寬度mWidth和高度mHeight。
? ? ? ? 3.?Activity窗口的內(nèi)容區(qū)域邊襯大小和可見區(qū)域邊襯大小發(fā)生了變化，即前面得到的變量contentInsetsChanged的值等于true。
? ? ? ? 重新計(jì)算了一次之后，如果Activity窗口的屬性lp表明需要對(duì)測(cè)量出來的寬度width和高度height進(jìn)行擴(kuò)展，即變量lp所指向的一個(gè)WindowManager.LayoutParams對(duì)象的成員變量horizontalWeight和verticalWeight的值大于0.0，那么就需要對(duì)Activity窗口的頂層視圖host的最大可用空間進(jìn)行擴(kuò)展后再進(jìn)行一次測(cè)量工作。
? ? ? ? 我們繼續(xù)往下閱讀最后一段代碼：
final boolean didLayout = mLayoutRequested;......if (didLayout) {......host.layout(0, 0, host.mMeasuredWidth, host.mMeasuredHeight);......}if (computesInternalInsets) {ViewTreeObserver.InternalInsetsInfo insets = attachInfo.mGivenInternalInsets;final Rect givenContent = attachInfo.mGivenInternalInsets.contentInsets;final Rect givenVisible = attachInfo.mGivenInternalInsets.visibleInsets;givenContent.left = givenContent.top = givenContent.right= givenContent.bottom = givenVisible.left = givenVisible.top= givenVisible.right = givenVisible.bottom = 0;attachInfo.mTreeObserver.dispatchOnComputeInternalInsets(insets);Rect contentInsets = insets.contentInsets;Rect visibleInsets = insets.visibleInsets;if (mTranslator != null) {contentInsets = mTranslator.getTranslatedContentInsets(contentInsets);visibleInsets = mTranslator.getTranslatedVisbileInsets(visibleInsets);}if (insetsPending || !mLastGivenInsets.equals(insets)) {mLastGivenInsets.set(insets);try {sWindowSession.setInsets(mWindow, insets.mTouchableInsets,contentInsets, visibleInsets);} catch (RemoteException e) {}}}......}......
}? ? ? ? 從前面的描述可以知道，當(dāng)變量computesInternalInsets的值等于true時(shí)，就表示Activity窗口指定有額外的內(nèi)容區(qū)域邊襯和可見區(qū)域邊襯，這時(shí)候就是時(shí)候把它們告訴給WindowManagerService服務(wù)了，以便WindowManagerService服務(wù)下次可以知道Activity窗口的真實(shí)布局。Activity窗口額外指定的內(nèi)容區(qū)域邊襯大小和可見區(qū)域邊襯大小是通過調(diào)用變量attachInfo所指向的一個(gè)AttachInfo對(duì)象的成員變量mTreeObserver所描述的一個(gè)TreeObserver對(duì)象的成員函數(shù)dispatchOnComputeInternalInsets來計(jì)算的。計(jì)算完成之后，就會(huì)保存在變量attachInfo所指向的一個(gè)AttachInfo對(duì)象的成員變量mGivenInternalInsets中，并且會(huì)通過ViewRoot類的靜態(tài)成員變量sWindowSession所指向一個(gè)Binder代理對(duì)象來設(shè)置到WindowManagerService服務(wù)中去。
? ? ? ? 注意，如果ViewRoot類的成員變量mTranslator指向了一個(gè)Translator對(duì)象，那么就說明Activity窗口是運(yùn)行兼容模式中，這時(shí)候就需要將前面計(jì)算得到的內(nèi)容區(qū)域邊襯大小和可見區(qū)域邊襯大小轉(zhuǎn)化到兼容模式下，然后才可以保存在變量attachInfo所指向的一個(gè)AttachInfo對(duì)象的成員變量mGivenInternalInsets中，以及設(shè)置到WindowManagerService服務(wù)中去。
? ? ? ? 另外，只有前面得到的變量insetsPending的值等于true，即Activity窗口正在等待告訴WindowManagerService服務(wù)它有額外指定的內(nèi)容區(qū)域邊襯和可見區(qū)域邊襯，或者Activty窗口額外指定的內(nèi)容區(qū)域邊襯和可見區(qū)域邊襯發(fā)生了變化，即Activty窗口上一次額外指定的內(nèi)容區(qū)域邊襯和可見區(qū)域邊襯mLastGivenInsets不等于當(dāng)前這次指定的內(nèi)容區(qū)域邊襯和可見區(qū)域邊襯insets，Activity窗口額外指定的內(nèi)容區(qū)域邊襯和可見區(qū)域邊襯才會(huì)被設(shè)置到WindowManagerService服務(wù)中去。
? ? ? ? ViewRoot類的成員函數(shù)再接下來的工作就是繪制Activity窗口的UI了，這個(gè)過程同樣可以參考前面Android應(yīng)用程序窗口（Activity）的測(cè)量（Measure）、布局（Layout）和繪制（Draw）過程分析一文。
? ? ? ? 接下來，我們繼續(xù)分析ViewRoot類的成員函數(shù)relayoutWindow的實(shí)現(xiàn)，以便可以了解它是如何請(qǐng)求WindowManagerService服務(wù)計(jì)算Activity窗口的大小的。
? ? ? ? Step 2.?ViewRoot.relayoutWindow
public final class ViewRoot extends Handler implements ViewParent,View.AttachInfo.Callbacks {......private int relayoutWindow(WindowManager.LayoutParams params, int viewVisibility,boolean insetsPending) throws RemoteException {float appScale = mAttachInfo.mApplicationScale;......int relayoutResult = sWindowSession.relayout(mWindow, params,(int) (mView.mMeasuredWidth * appScale + 0.5f),(int) (mView.mMeasuredHeight * appScale + 0.5f),viewVisibility, insetsPending, mWinFrame,mPendingContentInsets, mPendingVisibleInsets,mPendingConfiguration, mSurface);......if (mTranslator != null) {mTranslator.translateRectInScreenToAppWinFrame(mWinFrame);mTranslator.translateRectInScreenToAppWindow(mPendingContentInsets);mTranslator.translateRectInScreenToAppWindow(mPendingVisibleInsets);}return relayoutResult;}......
}? ? ? ?從前面Android應(yīng)用程序窗口（Activity）與WindowManagerService服務(wù)的連接過程分析一文可以知道，ViewRoot類的靜態(tài)成員變量sWindowSession是一個(gè)Binder代理對(duì)象，它引用了運(yùn)行在WindowManagerService服務(wù)這一側(cè)的一個(gè)Session對(duì)象，ViewRoot類的成員函數(shù)relayoutWindow通過調(diào)用這個(gè)Session對(duì)象的成員函數(shù)relayout來請(qǐng)求WindowManagerService服務(wù)計(jì)算Activity窗口的大小，其中，傳遞給WindowManagerService服務(wù)的參數(shù)包括：
? ? ? ?1. ViewRoot類的成員變量mWindow，用來標(biāo)志要計(jì)算的是哪一個(gè)Activity窗口的大小。
? ? ? ?2.?Activity窗口的頂層視圖經(jīng)過測(cè)量后得到的寬度和高度。注意，傳遞給WindowManagerService服務(wù)的寬度和高度是已經(jīng)考慮了Activity窗口所設(shè)置的縮放因子了的。
? ? ? ?3.?Activity窗口的可見狀態(tài)，即參數(shù)viewVisibility。
? ? ? ?4. Activity窗口是否有額外的內(nèi)容區(qū)域邊襯和可見區(qū)域邊襯等待告訴給WindowManagerService服務(wù)，即參數(shù)insetsPending。
? ? ? ?5.?ViewRoot類的成員變量mWinFrame，這是一個(gè)輸出參數(shù)，用來保存WindowManagerService服務(wù)計(jì)算后得到的Activity窗口的大小。
? ? ? ?6.?ViewRoot類的成員變量mPendingContentInsets，這是一個(gè)輸出參數(shù)，用來保存WindowManagerService服務(wù)計(jì)算后得到的Activity窗口的內(nèi)容區(qū)域邊襯大小。
? ? ? ?7.?ViewRoot類的成員變量mPendingVisibleInsets，這是一個(gè)輸出參數(shù)，用來保存WindowManagerService服務(wù)計(jì)算后得到的Activity窗口的可見區(qū)域邊襯大小。
? ? ? ?8.?ViewRoot類的成員變量mPendingConfiguration，這是一個(gè)輸出參數(shù)，用來保存WindowManagerService服務(wù)返回來的Activity窗口的配置信息。
? ? ? ?9. ViewRoot類的成員變量mSurface，這是一個(gè)輸出參數(shù)，用來保存WindowManagerService服務(wù)返回來的Activity窗口的繪圖表面。
? ? ? ?得到了Activity窗口的大小以及內(nèi)容區(qū)域邊襯大小和可見區(qū)域邊襯大小之后，如果Activity窗口是運(yùn)行在兼容模式中，即ViewRoot類的成員變量mTranslator指向了一個(gè)Translator對(duì)象，那么就需要調(diào)用它的成員函數(shù)translateRectInScreenToAppWindow來對(duì)它們進(jìn)行轉(zhuǎn)換。
? ? ? ?接下來，我們繼續(xù)分析Session類的成員函數(shù)relayout，以便可以了解WindowManagerService服務(wù)是如何計(jì)算一個(gè)Activity窗口的大小的。
? ? ? ?Step 3.?Session.relayout
public class WindowManagerService extends IWindowManager.Stubimplements Watchdog.Monitor {......private final class Session extends IWindowSession.Stubimplements IBinder.DeathRecipient {......public int relayout(IWindow window, WindowManager.LayoutParams attrs,int requestedWidth, int requestedHeight, int viewFlags,boolean insetsPending, Rect outFrame, Rect outContentInsets,Rect outVisibleInsets, Configuration outConfig, Surface outSurface) {//Log.d(TAG, ">>>>>> ENTERED relayout from " + Binder.getCallingPid());int res = relayoutWindow(this, window, attrs,requestedWidth, requestedHeight, viewFlags, insetsPending,outFrame, outContentInsets, outVisibleInsets, outConfig, outSurface);//Log.d(TAG, "<<<<<< EXITING relayout to " + Binder.getCallingPid());return res;}......}......
}? ? ? ? Session類的成員函數(shù)relayout的實(shí)現(xiàn)很簡(jiǎn)單，它只是調(diào)用了WindowManagerService類的成員函數(shù)relayoutWindow來進(jìn)一步計(jì)算參數(shù)window所描述的一個(gè)Activity窗品的大小，接下來我們就繼續(xù)分析WindowManagerService類的成員函數(shù)relayoutWindow的實(shí)現(xiàn)。
? ? ? ? Step 4.?WindowManagerService.relayoutWindow
public class WindowManagerService extends IWindowManager.Stubimplements Watchdog.Monitor {......public int relayoutWindow(Session session, IWindow client,WindowManager.LayoutParams attrs, int requestedWidth,int requestedHeight, int viewVisibility, boolean insetsPending,Rect outFrame, Rect outContentInsets, Rect outVisibleInsets,Configuration outConfig, Surface outSurface) {......synchronized(mWindowMap) {WindowState win = windowForClientLocked(session, client, false);......win.mRequestedWidth = requestedWidth;win.mRequestedHeight = requestedHeight;......final boolean scaledWindow =((win.mAttrs.flags & WindowManager.LayoutParams.FLAG_SCALED) != 0);if (scaledWindow) {// requested{Width|Height} Surface's physical size// attrs.{width|height} Size on screenwin.mHScale = (attrs.width != requestedWidth) ?(attrs.width / (float)requestedWidth) : 1.0f;win.mVScale = (attrs.height != requestedHeight) ?(attrs.height / (float)requestedHeight) : 1.0f;} else {win.mHScale = win.mVScale = 1;}......win.mGivenInsetsPending = insetsPending;......performLayoutAndPlaceSurfacesLocked();......outFrame.set(win.mFrame);outContentInsets.set(win.mContentInsets);outVisibleInsets.set(win.mVisibleInsets);......}return (inTouchMode ? WindowManagerImpl.RELAYOUT_IN_TOUCH_MODE : 0)| (displayed ? WindowManagerImpl.RELAYOUT_FIRST_TIME : 0);}......
}? ? ? ??這個(gè)函數(shù)定義在文件frameworks/base/services/java/com/android/server/WindowManagerService.java中。
? ? ? ? 參數(shù)client是一個(gè)Binder代理對(duì)象，它引用了運(yùn)行在應(yīng)用程序進(jìn)程這一側(cè)中的一個(gè)W對(duì)象，用來標(biāo)志一個(gè)Activity窗口。從前面Android應(yīng)用程序窗口（Activity）與WindowManagerService服務(wù)的連接過程分析一文可以知道，在應(yīng)用程序進(jìn)程這一側(cè)的每一個(gè)W對(duì)象，在WindowManagerService服務(wù)這一側(cè)都有一個(gè)對(duì)應(yīng)的WindowState對(duì)象，用來描述一個(gè)Activity窗口的狀態(tài)。因此，WindowManagerService類的成員函數(shù)relayoutWindow首先通過調(diào)用另外一個(gè)成員函數(shù)windowForClientLocked來獲得與參數(shù)client所對(duì)應(yīng)的一個(gè)WindowState對(duì)象win，以便接下來可以對(duì)它進(jìn)行操作。
? ? ? ? 本文我們只關(guān)注WindowManagerService類的成員函數(shù)relayoutWindow中與窗口大小計(jì)算有關(guān)的邏輯，計(jì)算過程如下所示：
? ? ? ? 1. 參數(shù)requestedWidth和requestedHeight描述的是應(yīng)用程序進(jìn)程請(qǐng)求設(shè)置Activity窗口中的寬度和高度，它們會(huì)被記錄在WindowState對(duì)象win的成員變量mRequestedWidth和mRequestedHeight中。
? ? ? ? 2.?WindowState對(duì)象win的成員變量mAttr，它指向的是一個(gè)WindowManager.LayoutParams對(duì)象，用來描述Activity窗口的布局參數(shù)。其中，這個(gè)WindowManager.LayoutParams對(duì)象的成員變量width和height是用來描述Activity窗口的寬度和高度的。當(dāng)這個(gè)WindowManager.LayoutParams對(duì)象的成員變量flags的WindowManager.LayoutParams.FLAG_SCALED位不等于0的時(shí)候，就說明需要給Activity窗口的大小設(shè)置縮放因子。縮放因子分為兩個(gè)維度，分別是寬度縮放因子和高度縮放因子，保存在WindowState對(duì)象win的成員變量HScale和VScale中，計(jì)算方法分別是用應(yīng)用程序進(jìn)程請(qǐng)求設(shè)置Activity窗口中的寬度和高度除以Activity窗口在布局參數(shù)中所設(shè)置的寬度和高度。
? ? ? ? 3. 參數(shù)insetsPending用來描述Activity窗口是否有額外的內(nèi)容區(qū)域邊襯和可見區(qū)域邊襯未設(shè)置，它被記錄在WindowState對(duì)象win的成員變量mGivenInsetsPending中。
? ? ? ? 4. 調(diào)用WindowManagerService類的成員函數(shù)performLayoutAndPlaceSurfacesLocked來計(jì)算Activity窗口的大小。計(jì)算完成之后，參數(shù)client所描述的Activity窗口的大小、內(nèi)容區(qū)域邊襯大小和可見區(qū)域邊邊襯大小就會(huì)分別保存在WindowState對(duì)象win的成員變量mFrame、mContentInsets和mVisibleInsets中。
? ? ? ? 5. 將WindowState對(duì)象win的成員變量mFrame、mContentInsets和mVisibleInsets的值分別拷貝到參數(shù)出數(shù)outFrame、outContentInsets和outVisibleInsets中，以便可以返回給應(yīng)用程序進(jìn)程。
? ? ? ? 經(jīng)過上述五個(gè)操作后，Activity窗口的大小計(jì)算過程就完成了，接下來我們繼續(xù)分析WindowManagerService類的成員函數(shù)performLayoutAndPlaceSurfacesLocked的實(shí)現(xiàn)，以便可以詳細(xì)了解Activity窗口的大小計(jì)算過程。
? ? ? ? Step 5.?WindowManagerService.performLayoutAndPlaceSurfacesLocked
public class WindowManagerService extends IWindowManager.Stubimplements Watchdog.Monitor {......private final void performLayoutAndPlaceSurfacesLocked() {if (mInLayout) {......return;}......boolean recoveringMemory = false;if (mForceRemoves != null) {recoveringMemory = true;// Wait a little it for things to settle down, and off we go.for (int i=0; i<mForceRemoves.size(); i++) {WindowState ws = mForceRemoves.get(i);Slog.i(TAG, "Force removing: " + ws);removeWindowInnerLocked(ws.mSession, ws);}mForceRemoves = null;......}mInLayout = true;try {performLayoutAndPlaceSurfacesLockedInner(recoveringMemory);int i = mPendingRemove.size()-1;if (i >= 0) {while (i >= 0) {WindowState w = mPendingRemove.get(i);removeWindowInnerLocked(w.mSession, w);i--;}mPendingRemove.clear();mInLayout = false;assignLayersLocked();mLayoutNeeded = true;performLayoutAndPlaceSurfacesLocked();} else {mInLayout = false;......}......} catch (RuntimeException e) {mInLayout = false;......}}......
}? ? ? ?從WindowManagerService類的成員函數(shù)performLayoutAndPlaceSurfacesLocked的名稱可以推斷出，它執(zhí)行的操作絕非是計(jì)算窗口大小這么簡(jiǎn)單。計(jì)算窗口大小只是其中的一個(gè)小小功能點(diǎn)，它主要的功能是用來刷新系統(tǒng)的UI。在我們這個(gè)情景中，為什么需要刷新系統(tǒng)的UI呢？Activity窗口在其屬性發(fā)生了變化，例如，可見性、大小發(fā)生了變化，又或者它新增、刪除了子視圖，都需要重新計(jì)算大小，而這些變化都是要求WindowManagerService服務(wù)重新刷新系統(tǒng)的UI的。事實(shí)上，刷新系統(tǒng)的UI是WindowManagerService服務(wù)的主要任務(wù)，在新增和刪除了窗口、窗口動(dòng)畫顯示過程、窗口切換過程中，WindowManagerService服務(wù)都需要不斷地刷新系統(tǒng)的UI。
? ? ? ?WindowManagerService類的成員函數(shù)performLayoutAndPlaceSurfacesLocked主要是通過調(diào)用另外一個(gè)成員函數(shù)performLayoutAndPlaceSurfacesLockedInner來刷新系統(tǒng)的UI的，而在刷新的過程中，就會(huì)對(duì)系統(tǒng)中的各個(gè)窗口的大小進(jìn)行計(jì)算。
? ? ? ?在調(diào)用成員函數(shù)performLayoutAndPlaceSurfacesLockedInner來刷新系統(tǒng)UI的前后，WindowManagerService類的成員函數(shù)performLayoutAndPlaceSurfacesLocked還會(huì)執(zhí)行以下兩個(gè)操作：
? ? ? ?1. 調(diào)用前，檢查系統(tǒng)中是否存在強(qiáng)制刪除的窗口。有內(nèi)存不足的情況下，有一些窗口就會(huì)被回收，即要從系統(tǒng)中刪除，這些窗口會(huì)保存在WindowManagerService類的成員變量mForceRemoves所描述的一個(gè)ArrayList中。如果存在這些窗口，那么WindowManagerService類的成員函數(shù)performLayoutAndPlaceSurfacesLocked就會(huì)調(diào)用另外一個(gè)成員函數(shù)removeWindowInnerLocked來刪除它們，以便可以回收它們所占用的內(nèi)存。
? ? ? ?2. 調(diào)用后，檢查系統(tǒng)中是否有窗口需要移除。如果有的話，那么WindowManagerService類的成員變量mPendingRemove所描述的一個(gè)ArrayList的大小就會(huì)大于0。這種情況下，WindowManagerService類的成員函數(shù)performLayoutAndPlaceSurfacesLocked就會(huì)調(diào)用另外一個(gè)成員函數(shù)removeWindowInnerLocked來移除這些窗口。注意，WindowManagerService類的成員函數(shù)removeWindowInnerLocked只是用來移除窗口，但是并沒有回收這些窗口所占用的內(nèi)存。等到合適的時(shí)候，例如，內(nèi)存不足時(shí)，才會(huì)考慮回收這些窗口所占用的內(nèi)存。移除一個(gè)窗口的操作也是很復(fù)雜的，除了要將窗口從WindowManagerService類的相關(guān)成員變量中移除之外，還要考慮重新調(diào)整輸入法窗口和壁紙窗口，因?yàn)楸灰瞥拇翱诳赡芤箫@示壁紙和輸入法窗口，當(dāng)它被移除之后，就要將壁紙窗口和輸入法窗口調(diào)整到合適的Z軸位置上去，以便可以交給下一個(gè)需要顯示壁紙和輸入法窗口的窗口使用。此外，在移除了窗口之后，WindowManagerService服務(wù)還需要重新計(jì)算現(xiàn)存的其它窗口的Z軸位置，以便可以正確地反映系統(tǒng)當(dāng)前的UI狀態(tài)，這是通過調(diào)用WindowManagerService類的成員函數(shù)assignLayersLocked來實(shí)現(xiàn)的。重新計(jì)算了現(xiàn)存的其它窗口的Z軸位置之后，又需要再次刷新系統(tǒng)的UI，即要對(duì)WindowManagerService類的成員函數(shù)performLayoutAndPlaceSurfacesLocked進(jìn)行遞歸調(diào)用，并且在調(diào)用前，將WindowManagerService類的成員變量mLayoutNeeded的值設(shè)置為true。由此就可見，系統(tǒng)UI的刷新過程是非常復(fù)雜的。
? ? ? ?注意，為了防止在刷新系統(tǒng)UI的過程中被重復(fù)調(diào)用，WindowManagerService類的成員函數(shù)performLayoutAndPlaceSurfacesLocked在刷新系統(tǒng)UI之前，即調(diào)用成員函數(shù)performLayoutAndPlaceSurfacesLockedInner之前，會(huì)將WindowManagerService類的成員變量mInLayout的值設(shè)置為true，并且在調(diào)用之后，重新將這個(gè)成員變量的值設(shè)置為false。這樣，WindowManagerService類的成員函數(shù)performLayoutAndPlaceSurfacesLocked就可以在一開始的時(shí)候檢查成員變量mInLayout的值是否等于true，如果等于的話，那么就說明WindowManagerService服務(wù)正在刷新系統(tǒng)UI的過程中，于是就不用往下執(zhí)行了。
? ? ? ?接下來，我們就繼續(xù)分析WindowManagerService類的成員函數(shù)performLayoutAndPlaceSurfacesLockedInner的實(shí)現(xiàn)，以便可以了解Activity窗口的大小計(jì)算過程。
? ? ? ?Step 6.?WindowManagerService.performLayoutAndPlaceSurfacesLockedInner
public class WindowManagerService extends IWindowManager.Stubimplements Watchdog.Monitor {......private final void performLayoutAndPlaceSurfacesLockedInner(boolean recoveringMemory) {......Surface.openTransaction();......try {......int repeats = 0;int changes = 0;do {repeats++;if (repeats > 6) {......break;}// FIRST LOOP: Perform a layout, if needed.if (repeats < 4) {changes = performLayoutLockedInner();if (changes != 0) {continue;}} else {Slog.w(TAG, "Layout repeat skipped after too many iterations");changes = 0;}// SECOND LOOP: Execute animations and update visibility of windows.......} while (changes != 0);// THIRD LOOP: Update the surfaces of all windows.......} catch (RuntimeException e) {......}......Surface.closeTransaction();......// Destroy the surface of any windows that are no longer visible.......// Time to remove any exiting tokens?......// Time to remove any exiting applications?......}......
}? ? ? ??WindowManagerService類的成員函數(shù)performLayoutAndPlaceSurfacesLockedInner是一個(gè)巨無霸的函數(shù)，它一共有1200+行代碼，承載了WindowManagerService服務(wù)的核心功能。對(duì)于這樣一個(gè)巨無霸函數(shù)，要逐行地分析它的實(shí)現(xiàn)是很困難的，因?yàn)橐斫飧鞣N上下文信息，才可以清楚地知道它的執(zhí)行過程。這里我們就大概地分析它的實(shí)現(xiàn)框架，以后再逐步地分析它的具體實(shí)現(xiàn)：
? ? ? ? 1. 在一個(gè)最多執(zhí)行7次的while循環(huán)中，做兩件事情：第一件事情是計(jì)算各個(gè)窗品的大小，這是通過調(diào)用另外一個(gè)成員函數(shù)performLayoutLockedInner來實(shí)現(xiàn)的；第二件事情是執(zhí)行窗口的動(dòng)畫，主要是處理窗口的啟動(dòng)窗口顯示動(dòng)畫和窗口切換過程中的動(dòng)畫，以及更新各個(gè)窗口的可見性。注意，每一次while循環(huán)執(zhí)行之后，如果發(fā)現(xiàn)系統(tǒng)中的各個(gè)窗口的相應(yīng)布局屬性不再發(fā)生變化，那么就不行執(zhí)行下一次的while循環(huán)了，即該while循環(huán)可能不用執(zhí)行7次就結(jié)束了。窗口的動(dòng)畫顯示過程和窗口的可見性更新過程是相當(dāng)復(fù)雜的，它們也是WindowManagerService服務(wù)最為核的地方，在后面的文章中，我們?cè)僭敿?xì)分析。
? ? ? ? 2. 經(jīng)過第1點(diǎn)的操作之后，接下來就可以將各個(gè)窗口的屬性，例如，大小、位置等屬性，通知SurfaceFlinger服務(wù)了，也就是讓SurfaceFlinger服務(wù)更新它里面的各個(gè)Layer的屬性值，以便可以對(duì)這些Layer執(zhí)行可見性計(jì)算、合成等操作，最后渲染到硬件幀緩沖區(qū)中去。SurfaceFlinger服務(wù)計(jì)算系統(tǒng)中各個(gè)窗口，即各個(gè)Layer的可見性，以便將它們合成、渲染到硬件幀緩沖區(qū)的過程可以參考前面Android系統(tǒng)Surface機(jī)制的SurfaceFlinger服務(wù)渲染應(yīng)用程序UI的過程分析一文。注意，各個(gè)窗口的屬性更新操作是被包含在SurfaceFlinger服務(wù)的一個(gè)事務(wù)中的，即一個(gè)Transaction中，這樣做是為了避免每更新一個(gè)窗口的一個(gè)屬性就觸發(fā)SurfaceFlinger服務(wù)重新計(jì)算各個(gè)Layer的可見性，以及對(duì)各個(gè)Layer進(jìn)行合并和渲染的操作。啟動(dòng)SurfaceFlinger服務(wù)的一個(gè)事務(wù)可以通過調(diào)用Surface類的靜態(tài)成員函數(shù)openTransaction來實(shí)現(xiàn)，而關(guān)閉SurfaceFlinger服務(wù)的一個(gè)事務(wù)可以通過調(diào)用Surface類的靜態(tài)成員函數(shù)closeTransaction來實(shí)現(xiàn)。
? ? ? ?3. 經(jīng)過第1點(diǎn)和第2點(diǎn)的操作之后，一次系統(tǒng)UI的刷新過程就完成了，這時(shí)候就會(huì)將系統(tǒng)中的那些不會(huì)再顯示的窗口的繪圖表面銷毀掉，并且將那些已經(jīng)完成退出了的窗口令牌，即將我們?cè)谇懊鍭ndroid應(yīng)用程序窗口（Activity）與WindowManagerService服務(wù)的連接過程分析一文中所提到的WindowToken移除掉，以及將那些已經(jīng)退出了的Activity窗口令牌，即將我們?cè)谇懊鍭ndroid應(yīng)用程序窗口（Activity）與WindowManagerService服務(wù)的連接過程分析一文中所提到的AppWindowToken也移除掉。這一步實(shí)際執(zhí)行的是窗口清理操作。
? ? ? ?上述三個(gè)操作是WindowManagerService類的成員函數(shù)performLayoutAndPlaceSurfacesLockedInner的實(shí)現(xiàn)關(guān)鍵所在，理解了這三個(gè)操作，基本也就可以理解WindowManagerService服務(wù)刷新系統(tǒng)UI的過程了。
? ? ? ?接下來，我們繼續(xù)分析WindowManagerService類的成員函數(shù)performLayoutLockedInner的實(shí)現(xiàn)，以便可以繼續(xù)了解Activity窗口的大小計(jì)算過程。
? ? ? ?Step 7.?WindowManagerService.performLayoutLockedInner
public class WindowManagerService extends IWindowManager.Stubimplements Watchdog.Monitor {......final WindowManagerPolicy mPolicy = PolicyManager.makeNewWindowManager();....../*** Z-ordered (bottom-most first) list of all Window objects.*/final ArrayList<WindowState> mWindows = new ArrayList<WindowState>();......private final int performLayoutLockedInner() {......final int dw = mDisplay.getWidth();final int dh = mDisplay.getHeight();final int N = mWindows.size();int i;......mPolicy.beginLayoutLw(dw, dh);int seq = mLayoutSeq+1;if (seq < 0) seq = 0;mLayoutSeq = seq;// First perform layout of any root windows (not attached// to another window).int topAttached = -1;for (i = N-1; i >= 0; i--) {WindowState win = mWindows.get(i);......final AppWindowToken atoken = win.mAppToken;final boolean gone = win.mViewVisibility == View.GONE|| !win.mRelayoutCalled|| win.mRootToken.hidden|| (atoken != null && atoken.hiddenRequested)|| win.mAttachedHidden|| win.mExiting || win.mDestroying;......if (!gone || !win.mHaveFrame) {if (!win.mLayoutAttached) {mPolicy.layoutWindowLw(win, win.mAttrs, null);win.mLayoutSeq = seq;......} else {if (topAttached < 0) topAttached = i;}}}......for (i = topAttached; i >= 0; i--) {WindowState win = mWindows.get(i);// If this view is GONE, then skip it -- keep the current// frame, and let the caller know so they can ignore it// if they want. (We do the normal layout for INVISIBLE// windows, since that means "perform layout as normal,// just don't display").if (win.mLayoutAttached) {......if ((win.mViewVisibility != View.GONE && win.mRelayoutCalled)|| !win.mHaveFrame) {mPolicy.layoutWindowLw(win, win.mAttrs, win.mAttachedWindow);win.mLayoutSeq = seq;......}}}......return mPolicy.finishLayoutLw();}......
}? ? ? ??這個(gè)函數(shù)定義在文件frameworks/base/services/java/com/android/server/WindowManagerService.java中。
? ? ? ? 在分析WindowManagerService類的成員函數(shù)performLayoutLockedInner的實(shí)現(xiàn)之前，我們首先介紹WindowManagerService類的兩個(gè)成員變量mPolicy和mWindows：
? ? ? ? 1. mPolicy指向的是一個(gè)窗口管理策略類，它是通過調(diào)用PolicyManager類的靜態(tài)成員函數(shù)makeNewWindowManager來初始化的，在Phone平臺(tái)中，它指向的是便是一個(gè)PhoneWindowManager對(duì)象，主要是用來制定窗口的大小計(jì)算策略。
? ? ? ? 2.?mWindows指向的是一個(gè)類型為WindowState的ArrayList，它里面保存的就是系統(tǒng)中的所有窗口，這些窗口是按照Z軸位置從小到大的順序保存在這個(gè)ArrayList中的，也就是說，第i個(gè)窗口位于第i-1個(gè)窗口的上面，其中，i > 0。
? ? ? ? 理解了這兩個(gè)成員變量的含義之后，我們就分析WindowManagerService類的成員函數(shù)performLayoutLockedInner的執(zhí)行過程，主要是分三個(gè)階段：
? ? ? ? 1. 準(zhǔn)備階段：調(diào)用PhoneWindowManager類的成員函數(shù)beginLayoutLw來設(shè)置屏幕的大小。屏幕的大小可以通過調(diào)用WindowManagerService類的成員變量mDisplay所描述的一個(gè)Display對(duì)象的成員函數(shù)getWidth和getHeight來獲得。
? ? ? ? 2. 計(jì)算階段：調(diào)用PhoneWindowManager類的成員函數(shù)layoutWindowLw來計(jì)算各個(gè)窗口的大小、內(nèi)容區(qū)域邊襯大小以及可見區(qū)域邊襯大小。
? ? ? ? 3. 結(jié)束階段：調(diào)用PhoneWindowManager類的成員函數(shù)finishLayoutLw來執(zhí)行一些清理工作。
? ? ? ? 按照父子關(guān)系來劃分，系統(tǒng)中的窗口可以分為父窗口和子窗口兩種。如果一個(gè)WindowState對(duì)象的成員變量mLayoutAttached的值等于false，那么它所描述的窗口就可以作為一個(gè)父窗口，否則的話，它所描述的窗口就是一個(gè)子窗口。由于子窗口的大小計(jì)算是依賴于其父窗口的，因此，在計(jì)算各個(gè)窗口的大小的過程中，即在上述的第2階段中，按照以下方式來進(jìn)行：
? ? ? ? 1. ?先計(jì)算父窗口的大小。一般來說，能夠作為父窗口的，是那些Activity窗口。從前面Android應(yīng)用程序窗口（Activity）與WindowManagerService服務(wù)的連接過程分析一文可以知道，如果一個(gè)窗口是Activity窗口，那么用來描述它的一個(gè)WindowState對(duì)象的成員變量mAppToken就不等于null，并且指向的是一個(gè)AppWindowToken對(duì)象。這個(gè)AppWindowToken對(duì)象主要是用來描述一個(gè)Activity，即與ActivityManagerService服務(wù)中的一個(gè)ActivityRecord對(duì)象對(duì)應(yīng)。一個(gè)Activity窗口只有在兩種情況下才會(huì)被計(jì)算大小：第一種情況是窗口不是處于不可見狀態(tài)的；第二種情況是窗口從來還沒有被計(jì)算過大小，即用來描述該Activity窗口的WindowState對(duì)象的成員變量mHaveFrame的值等于false，這種情況一般發(fā)生在窗口剛剛被添加到WindowManagerService的過程中。一個(gè)Activity窗口的不可見狀態(tài)由它本身的狀態(tài)、它所在的窗口結(jié)構(gòu)樹狀態(tài)以及它所屬的Activity的狀態(tài)有關(guān)，也就是說，如果一個(gè)Activity窗口本身是可見的，但是由于它的父窗口、它所在的窗口組的根窗口或者它所屬的Activity是不可見的，那么該Activity窗口也是不可見的。一個(gè)Activity窗口的不可見狀態(tài)由以下因素決定：
? ? ? ? 1). 它本身處于不可見狀態(tài)，即對(duì)應(yīng)的WindowState對(duì)象的成員變量mViewVisibility的值等于View.GONE；
? ? ? ? 2). 它本身處于正在退出的狀態(tài)，即對(duì)應(yīng)的WindowState對(duì)象的成員變量mExiting的值等于true；
? ? ? ? 3).?它本身處于正在銷毀的狀態(tài)，即對(duì)應(yīng)的WindowState對(duì)象的成員變量mDestroying的值等于true；
? ? ? ? 4). 它的父窗口處于不可見狀態(tài)，即對(duì)應(yīng)的WindowState對(duì)象的成員變量mAttachedHidden的值等于true；
? ? ? ? 5). 它所在窗口結(jié)構(gòu)樹中的根窗口處于不可見狀態(tài)，即對(duì)應(yīng)的WindowState對(duì)象的成員變量mRootToken所描述的一個(gè)WindowToken對(duì)象的成員變量hidden的值等于true；
? ? ? ? 6). 它所屬的Activity處于不可見狀態(tài)，即對(duì)應(yīng)的WindowState對(duì)象的成員變量mAppToken所描述的一個(gè)AppWindowToken對(duì)象的成員變量hiddenRequested的值等于true。
? ? ? ? 除了上述六個(gè)因素之外，如果一個(gè)Activity窗口沒有被它所運(yùn)行在的應(yīng)用程序進(jìn)程主動(dòng)請(qǐng)求WindowManagerService服務(wù)對(duì)它進(jìn)行布局，即對(duì)應(yīng)的WindowState對(duì)象的成員變量mRelayoutCalled的值等于false，那么此時(shí)也是不需要計(jì)算Activity窗口的大小的。
? ? ? ?一個(gè)Activity窗口的大小一旦確定是需要計(jì)算大小之后，PhoneWindowManager類的成員函數(shù)layoutWindowLw就被調(diào)用來計(jì)算它的大小。
? ? ? ?2. 接著計(jì)算子窗口的大小。前面在計(jì)算父窗口的大小過程中，會(huì)記錄位于系統(tǒng)最上面的一個(gè)子窗口在mWindows所描述的一個(gè)ArrayList的位置topAttached，接下來就可以從這個(gè)位置開始向下計(jì)算每一個(gè)子窗口的大小。一個(gè)子窗口在以下兩種情況下，才會(huì)被計(jì)算大小：
? ? ? ?1).?它本身處于可見狀態(tài)，即對(duì)應(yīng)的WindowState對(duì)象的成員變量mViewVisibility的值不等于View.GONE，并且它所運(yùn)行在的應(yīng)用程序進(jìn)程主動(dòng)請(qǐng)求WindowManagerService服務(wù)對(duì)它進(jìn)行布局，即對(duì)應(yīng)的WindowState對(duì)象的成員變量mRelayoutCalled的值等于true。
? ? ? ?2). 它從來還沒有被計(jì)算過大小，即用來描述該子窗口的WindowState對(duì)象的成員變量mHaveFrame的值等于false，這種情況一般發(fā)生在子窗口剛剛被添加到WindowManagerService的過程中。
? ? ? ?接下來，我們就分別分析PhoneWindowManager類的成員函數(shù)beginLayoutLw、layoutWindowLw和finishLayoutLw的實(shí)現(xiàn)，以便可以了解Activity窗口的大小計(jì)算過程。
? ? ? ?Step 8.?PhoneWindowManager.beginLayoutLw
public class PhoneWindowManager implements WindowManagerPolicy {......WindowState mStatusBar = null;......// The current size of the screen.int mW, mH;// During layout, the current screen borders with all outer decoration// (status bar, input method dock) accounted for.int mCurLeft, mCurTop, mCurRight, mCurBottom;// During layout, the frame in which content should be displayed// to the user, accounting for all screen decoration except for any// space they deem as available for other content. This is usually// the same as mCur*, but may be larger if the screen decor has supplied// content insets.int mContentLeft, mContentTop, mContentRight, mContentBottom;// During layout, the current screen borders along with input method// windows are placed.int mDockLeft, mDockTop, mDockRight, mDockBottom;// During layout, the layer at which the doc window is placed.int mDockLayer;static final Rect mTmpParentFrame = new Rect();static final Rect mTmpDisplayFrame = new Rect();static final Rect mTmpContentFrame = new Rect();static final Rect mTmpVisibleFrame = new Rect();......public void beginLayoutLw(int displayWidth, int displayHeight) {mW = displayWidth;mH = displayHeight;mDockLeft = mContentLeft = mCurLeft = 0;mDockTop = mContentTop = mCurTop = 0;mDockRight = mContentRight = mCurRight = displayWidth;mDockBottom = mContentBottom = mCurBottom = displayHeight;mDockLayer = 0x10000000;// decide where the status bar goes ahead of timeif (mStatusBar != null) {final Rect pf = mTmpParentFrame;final Rect df = mTmpDisplayFrame;final Rect vf = mTmpVisibleFrame;pf.left = df.left = vf.left = 0;pf.top = df.top = vf.top = 0;pf.right = df.right = vf.right = displayWidth;pf.bottom = df.bottom = vf.bottom = displayHeight;mStatusBar.computeFrameLw(pf, df, vf, vf);if (mStatusBar.isVisibleLw()) {// If the status bar is hidden, we don't want to cause// windows behind it to scroll.mDockTop = mContentTop = mCurTop = mStatusBar.getFrameLw().bottom;......}}}......
}? ? ? ? 這個(gè)函數(shù)定義在文件frameworks/base/policy/src/com/android/internal/policy/impl/PhoneWindowManager.java中。
? ? ? ? 在分析PhoneWindowManager類的成員函數(shù)beginLayoutLw的實(shí)現(xiàn)之前，我們首先介紹PhoneWindowManager類的五組成員變量。
? ? ? ? 第一組成員變量是mW和mH，它們分別用來描述當(dāng)前這輪窗口大小計(jì)算過程的屏幕寬度和高度。
? ? ? ? 第二組成員變量是mCurLeft、mCurTop、mCurRight和mCurBottom，它們組成一個(gè)四元組（mCurLeft, mCurTop, mCurRight, mCurBottom），用來描述當(dāng)前這輪窗口大小計(jì)算過程的屏幕裝飾區(qū)，它對(duì)應(yīng)于前面所提到的Activity窗口的可見區(qū)域邊襯。
? ? ? ? 第三組成員變量是mContentLeft、mContentTop、mContentRight和mContentBottom，它們組成一個(gè)四元組（mContentLeft, mContentTop, mContentRight, mContentBottom），也是用來描述當(dāng)前這輪窗口大小計(jì)算過程的屏幕裝飾區(qū)，不過它對(duì)應(yīng)的是前面所提到的Activity窗口的內(nèi)容區(qū)域邊襯。
? ? ? ? 第四組成員變量是mDockLeft、mDockTop、mDockRight、mDockBottom和mDockLayer，其中，前四個(gè)成員變量組成一個(gè)四元組（mDockLeft, mDockTop, mDockRight, mDockBottom），用來描述當(dāng)前這輪窗口大小計(jì)算過程中的輸入法窗口所占據(jù)的位置，后一個(gè)成員變量mDockLayer用來描述輸入法窗品的Z軸位置。
? ? ? ? 第五組成員變量是mTmpParentFrame、mTmpDisplayFrame、mTmpContentFrame和mTmpVisibleFrame，它們是一組臨時(shí)Rect區(qū)域，用來作為參數(shù)傳遞給具體的窗口計(jì)算大小的，避免每次都創(chuàng)建一組新的Rect區(qū)域來作來參數(shù)傳遞窗口。
? ? ? ? 除了這五組成員變量之外，PhoneWindowManager類還有一個(gè)成員變量mStatusBar，它的類型為WindowState，用來描述系統(tǒng)的狀態(tài)欄。
? ? ? ? 理解了這些成員變量的含義之后，PhoneWindowManager類的成員函數(shù)beginLayoutLw的實(shí)現(xiàn)就容易理解了，它主要做了以下兩件事情：
? ? ? ? 1. 初始化前面所提到的四組成員變量，其中，mW和mH設(shè)置為參數(shù)displayWidth和displayHeight所指定的屏幕寬度和高度，并且使得（mCurLeft, mCurTop, mCurRight, mCurBottom）、（mContentLeft, mContentTop, mContentRight, mContentBottom）和（mDockLeft, mDockTop, mDockRight, mDockBottom）這三個(gè)區(qū)域的大小等于屏幕的大小。
? ? ? ? 2. 計(jì)算狀態(tài)欄的大小。狀態(tài)欄的大小一經(jīng)確定，并且它是可見的，那么就會(huì)修改成員變量mCurLeft、mContentLeft和mDockLeft的值為狀態(tài)欄的所占據(jù)的區(qū)域的下邊界位置，這樣就可以將（mCurLeft, mCurTop, mCurRight, mCurBottom）、（mContentLeft, mContentTop, mContentRight, mContentBottom）和（mDockLeft, mDockTop, mDockRight, mDockBottom）這三個(gè)區(qū)域限制為剔除狀態(tài)欄區(qū)域之后所得到的屏幕區(qū)域。
? ? ? ? 還有另外一個(gè)地方需要注意的是，輸入法窗口的Z軸被初始化為0x10000000，這個(gè)值是相當(dāng)大的了，可以保證輸入法窗口作為頂層窗口出現(xiàn)。
? ? ? ? 這一步執(zhí)行完成之后，返回到前面的Step 7中，即WindowManagerService類的成員函數(shù)performLayoutLockedInner，接下來就會(huì)調(diào)用PhoneWindowManager類的成員函數(shù)layoutWindowLw來計(jì)算系統(tǒng)中各個(gè)可見窗口的大小。
? ? ? ? Step 9.?PhoneWindowManager.layoutWindowLw
public class PhoneWindowManager implements WindowManagerPolicy {......public void layoutWindowLw(WindowState win, WindowManager.LayoutParams attrs,WindowState attached) {// we've already done the status barif (win == mStatusBar) {return;}......final int fl = attrs.flags;final int sim = attrs.softInputMode;final Rect pf = mTmpParentFrame;final Rect df = mTmpDisplayFrame;final Rect cf = mTmpContentFrame;final Rect vf = mTmpVisibleFrame;if (attrs.type == TYPE_INPUT_METHOD) {pf.left = df.left = cf.left = vf.left = mDockLeft;pf.top = df.top = cf.top = vf.top = mDockTop;pf.right = df.right = cf.right = vf.right = mDockRight;pf.bottom = df.bottom = cf.bottom = vf.bottom = mDockBottom;// IM dock windows always go to the bottom of the screen.attrs.gravity = Gravity.BOTTOM;mDockLayer = win.getSurfaceLayer();} else {if ((fl &(FLAG_LAYOUT_IN_SCREEN | FLAG_FULLSCREEN | FLAG_LAYOUT_INSET_DECOR))== (FLAG_LAYOUT_IN_SCREEN | FLAG_LAYOUT_INSET_DECOR)) {// This is the case for a normal activity window: we want it// to cover all of the screen space, and it can take care of// moving its contents to account for screen decorations that// intrude into that space.if (attached != null) {// If this window is attached to another, our display// frame is the same as the one we are attached to.setAttachedWindowFrames(win, fl, sim, attached, true, pf, df, cf, vf);} else {pf.left = df.left = 0;pf.top = df.top = 0;pf.right = df.right = mW;pf.bottom = df.bottom = mH;if ((sim & SOFT_INPUT_MASK_ADJUST) != SOFT_INPUT_ADJUST_RESIZE) {cf.left = mDockLeft;cf.top = mDockTop;cf.right = mDockRight;cf.bottom = mDockBottom;} else {cf.left = mContentLeft;cf.top = mContentTop;cf.right = mContentRight;cf.bottom = mContentBottom;}vf.left = mCurLeft;vf.top = mCurTop;vf.right = mCurRight;vf.bottom = mCurBottom;}}......}win.computeFrameLw(pf, df, cf, vf);// Dock windows carve out the bottom of the screen, so normal windows// can't appear underneath them.if (attrs.type == TYPE_INPUT_METHOD && !win.getGivenInsetsPendingLw()) {int top = win.getContentFrameLw().top;top += win.getGivenContentInsetsLw().top;if (mContentBottom > top) {mContentBottom = top;}top = win.getVisibleFrameLw().top;top += win.getGivenVisibleInsetsLw().top;if (mCurBottom > top) {mCurBottom = top;}......}}......
}? ? ? ? 第一個(gè)參數(shù)win描述的是當(dāng)前要計(jì)算大小的窗口，第二個(gè)參數(shù)attrs描述的是窗口win的布局參數(shù)，第三個(gè)參數(shù)attached描述的是窗口win的父窗口，如果它的值等于null，就表示窗口win沒有父窗口。
? ? ? ? PhoneWindowManager類的成員函數(shù)layoutWindowLw會(huì)根據(jù)窗口win的是子窗口還是全屏窗口及其軟鍵盤顯示模式來決定它的大小如何計(jì)算。這里我們只關(guān)注輸入法窗口和非全屏的Activity窗口的大小計(jì)算方式，其它類型的窗口大小計(jì)算方式是差不多的。
? ? ? ? 從前面的Step 8可以知道，系統(tǒng)的狀態(tài)欄大小已經(jīng)計(jì)算過了，因此，PhoneWindowManager類的成員函數(shù)layoutWindowLw如果發(fā)現(xiàn)參數(shù)win描述的正好是狀態(tài)欄的話，它就什么也不做就返回了。
? ? ? ? 在計(jì)算一個(gè)窗口的大小的時(shí)候，我們需要四個(gè)參數(shù)。第一個(gè)參數(shù)是父窗口的大小pf，第二個(gè)參數(shù)是屏幕的大小df，第三個(gè)參數(shù)是內(nèi)容區(qū)域邊襯大小cf，第四個(gè)參數(shù)是可見區(qū)域邊襯大小vf。?
? ? ? ? 如果參數(shù)win描述的是輸入法窗口，即參數(shù)attrs所描述的一個(gè)WindowManager.LayoutParams對(duì)象的成員變量type的值等于TYPE_INPUT_METHOD，那么上述四個(gè)用來計(jì)算窗口大小的區(qū)域pf、df、cf和vf就等于PhoneWindowManager類的成員變量mDockLeft、mDockTop、mDockRight和mDockBottom所組成的區(qū)域的大小。
? ? ? ? 如果參數(shù)win描述的是一個(gè)非全屏的Activity窗口，即參數(shù)attrs所描述的一個(gè)WindowManager.LayoutParams對(duì)象的成員變量flags的FLAG_LAYOUT_IN_SCREEN位和FLAG_LAYOUT_INSET_DECOR位等于1，那么PhoneWindowManager類的成員函數(shù)layoutWindowLw就會(huì)繼續(xù)檢查參數(shù)attached的值是否不等于null。如果不等于null的話，那么就說明參數(shù)win所描述的一個(gè)非全屏的Activity窗口附加在其它窗口上，即它具有一個(gè)父窗口，這時(shí)候就會(huì)調(diào)用另外一個(gè)成員函數(shù)setAttachedWindowFrames來計(jì)算它的大小。?
? ? ? ? 接下來我們就只關(guān)注參數(shù)win描述的是一個(gè)非全屏的、并且沒有附加到其它窗口的Activity窗口的大小計(jì)算過程。
? ? ? ? 首先，父窗口大小pf和屏幕大小df都會(huì)被設(shè)置為整個(gè)屏幕區(qū)域的大小。
? ? ? ? 其次，可見區(qū)域邊襯大小vf被設(shè)置為PhoneWindowManager類的成員變量mCurLeft、mCurTop、mCurRight和mCurBottom所組成的區(qū)域的大小。
? ? ? ? 第三，內(nèi)容區(qū)域邊襯大小cf的計(jì)算相對(duì)復(fù)雜一些，需要考慮窗口win的軟鍵盤顯示模式sim的值。如果變量sim的SOFT_INPUT_ADJUST_RESIZE位等于1，那么就意味著窗口win在出向輸入法窗口的時(shí)候，它的內(nèi)容要重新進(jìn)行排布，避免被輸入法窗口擋住，因此，這時(shí)候窗口win的內(nèi)容區(qū)域大小就會(huì)等于PhoneWindowManager類的成員變量mContentLeft、mContentTop、mContentRight和mContentBottom所組成的區(qū)域的大小。另一方面，如果變量sim的SOFT_INPUT_ADJUST_RESIZE位等于0，那么就意味著窗口win在出向輸入法窗口的時(shí)候，它的內(nèi)容不需要重新進(jìn)行排布，這時(shí)候它的內(nèi)容區(qū)域大小就會(huì)等于PhoneWindowManager類的成員變量mDockLeft、mDockTop、mDockRight和mDockBottom所組成的區(qū)域的大小。注意，PhoneWindowManager類的成員變量mDockLeft、mDockTop、mDockRight和mDockBottom所組成的區(qū)域的大小并不是等于輸入法窗口的大小的，而是包含了輸入法窗口所占據(jù)的區(qū)域的大小，這就意味著輸入法窗口與窗口win會(huì)有重疊的部分，或者說輸入法窗口覆蓋了窗口win的一部分。
? ? ? ? 得到了用來計(jì)算窗口win四個(gè)參數(shù)pf、 df、cf和vf之后，就可以調(diào)用參數(shù)win所描述的一個(gè)WindowState對(duì)象的成員函數(shù)computeFrameLw來計(jì)算窗口win的具體大小了。計(jì)算的結(jié)果便得到了窗口win的大小，以及它的內(nèi)容區(qū)域邊襯大小和可見區(qū)域邊襯大小。注意，窗口經(jīng)過計(jì)算后得到的內(nèi)容區(qū)域邊襯大小和可見區(qū)域邊襯大小并不一定是等于參數(shù)cf和vf所指定的大小的。
? ? ? ? 計(jì)算完成窗口win的大小之后，PhoneWindowManager類的成員函數(shù)layoutWindowLw還會(huì)檢查窗口win是否是一個(gè)輸入法窗口，并且它是否指定了額外的內(nèi)容區(qū)域邊襯和可見區(qū)域邊襯。如果這兩個(gè)條件都成立的話，那么就需要相應(yīng)地調(diào)整PhoneWindowManager類的成員變量mContentBottom和mCurBottom的值，以便使得PhoneWindowManager類的成員變量是mContentLeft、mContentTop、mContentRight和mContentBottom所圍成的內(nèi)容區(qū)域和成員變量mCurLeft、mCurTop、mCurRight和mCurBottom所圍成的可見區(qū)域不會(huì)覆蓋到輸入法窗口額外指定的內(nèi)容區(qū)域邊襯和可見區(qū)域邊襯。
? ? ? ? 接下來，我們就繼續(xù)分析WindowState類的成員函數(shù)computeFrameLw的實(shí)現(xiàn)，以便可以了解Activity窗口的大小計(jì)算的具體過程。
? ? ? ? Step 10.?WindowState.computeFrameLw
public class WindowManagerService extends IWindowManager.Stubimplements Watchdog.Monitor {......private final class WindowState implements WindowManagerPolicy.WindowState {......boolean mHaveFrame;......// "Real" frame that the application sees.final Rect mFrame = new Rect();......final Rect mContainingFrame = new Rect();final Rect mDisplayFrame = new Rect();final Rect mContentFrame = new Rect();final Rect mVisibleFrame = new Rect();public void computeFrameLw(Rect pf, Rect df, Rect cf, Rect vf) {mHaveFrame = true;final Rect container = mContainingFrame;container.set(pf);final Rect display = mDisplayFrame;display.set(df);if ((mAttrs.flags & FLAG_COMPATIBLE_WINDOW) != 0) {container.intersect(mCompatibleScreenFrame);if ((mAttrs.flags & FLAG_LAYOUT_NO_LIMITS) == 0) {display.intersect(mCompatibleScreenFrame);}}final int pw = container.right - container.left;final int ph = container.bottom - container.top;int w,h;if ((mAttrs.flags & mAttrs.FLAG_SCALED) != 0) {w = mAttrs.width < 0 ? pw : mAttrs.width;h = mAttrs.height< 0 ? ph : mAttrs.height;} else {w = mAttrs.width == mAttrs.MATCH_PARENT ? pw : mRequestedWidth;h = mAttrs.height== mAttrs.MATCH_PARENT ? ph : mRequestedHeight;}final Rect content = mContentFrame;content.set(cf);final Rect visible = mVisibleFrame;visible.set(vf);final Rect frame = mFrame;final int fw = frame.width();final int fh = frame.height();......Gravity.apply(mAttrs.gravity, w, h, container,(int) (mAttrs.x + mAttrs.horizontalMargin * pw),(int) (mAttrs.y + mAttrs.verticalMargin * ph), frame);......// Now make sure the window fits in the overall display.Gravity.applyDisplay(mAttrs.gravity, df, frame);// Make sure the content and visible frames are inside of the// final window frame.if (content.left < frame.left) content.left = frame.left;if (content.top < frame.top) content.top = frame.top;if (content.right > frame.right) content.right = frame.right;if (content.bottom > frame.bottom) content.bottom = frame.bottom;if (visible.left < frame.left) visible.left = frame.left;if (visible.top < frame.top) visible.top = frame.top;if (visible.right > frame.right) visible.right = frame.right;if (visible.bottom > frame.bottom) visible.bottom = frame.bottom;final Rect contentInsets = mContentInsets;contentInsets.left = content.left-frame.left;contentInsets.top = content.top-frame.top;contentInsets.right = frame.right-content.right;contentInsets.bottom = frame.bottom-content.bottom;final Rect visibleInsets = mVisibleInsets;visibleInsets.left = visible.left-frame.left;visibleInsets.top = visible.top-frame.top;visibleInsets.right = frame.right-visible.right;visibleInsets.bottom = frame.bottom-visible.bottom;if (mIsWallpaper && (fw != frame.width() || fh != frame.height())) {updateWallpaperOffsetLocked(this, mDisplay.getWidth(),mDisplay.getHeight(), false);}......}......}......
}? ? ? ? WindowState類的成員變量mHaveFrame用來描述一個(gè)窗口的大小是否計(jì)算過了。當(dāng)WindowState類的成員函數(shù)computeFrameLw被調(diào)用的時(shí)候，就說明一個(gè)相應(yīng)的窗口的大小得到計(jì)算了，因此，WindowState類的成員函數(shù)computeFrameLw一開始就會(huì)將成員變量mHaveFrame的值設(shè)置為true。
? ? ? ? 回憶一下，在前面的Step 9中提到，參數(shù)pf描述的是父窗口的大小，參數(shù)df描述的是屏幕的大小，參數(shù)cf描述的內(nèi)容區(qū)域大小，參數(shù)vf描述的是可見區(qū)域大小，接下來我們就分析WindowState類的成員函數(shù)computeFrameLw是如何利用這些參數(shù)來計(jì)算一個(gè)窗口的大小的。
? ? ? ??WindowState類的成員變量mContainingFrame和mDisplayFrame描述的是當(dāng)前正在處理的窗口的父窗口和屏幕的大小，它們剛好就分別等于參數(shù)pf和df的大小，因此，函數(shù)就直接將參數(shù)pf和df的值分別保存在WindowState類的成員變量mContainingFrame和mDisplayFrame中。如果當(dāng)前正在處理的窗口運(yùn)行在兼容模式，即WindowState類的成員變量mAttrs所指向的一個(gè)WindowManager.LayoutParams對(duì)象的成員變量flags的FLAG_COMPATIBLE_WINDOW位等于1，那么就需要將其父窗口的大小限制mContainingFrame在兼容模式下的屏幕區(qū)域中。兼容模式下的屏幕區(qū)域保存在WindowManagerService類的成員變量mCompatibleScreenFrame中，將父窗口的大小mContainingFrame與它執(zhí)行一個(gè)相交操作，就可以將父窗品的大小限制兼容模式下的屏幕區(qū)域中。在當(dāng)前正在處理的窗口運(yùn)行在兼容模式的情況下，如果它的大小被限制在了兼容模式下的屏幕區(qū)域之中，即WindowState類的成員變量mAttrs所指向的一個(gè)WindowManager.LayoutParams對(duì)象的成員變量flags的FLAG_LAYOUT_NO_LIMITS位等于0，那么同樣需要將屏幕大小mDisplayFrame限制在兼容模式下的屏幕區(qū)域mCompatibleScreenFrame，這也是通過執(zhí)行一個(gè)相交操作來完成的。
? ? ? ??WindowState類的成員變量mContentFrame和mVisibleFrame描述的是當(dāng)前正在處理的窗口的內(nèi)容區(qū)域和可見區(qū)域大小，它們剛好就分別等于參數(shù)cf和vf的大小，因此，函數(shù)就直接將參數(shù)cf和vf的值分別保存在WindowState類的成員變量mContainingFrame和mDisplayFrame中。現(xiàn)在，就剩下窗口的大小還沒有計(jì)算。一旦窗口大小確定下來之后，就可以繼續(xù)計(jì)算窗口的內(nèi)容區(qū)域邊襯和可見區(qū)域邊襯大小了。接下來我們就繼續(xù)分析窗口大小的計(jì)算過程。
? ? ? ???WindowState類的成員變量mFrame描述的就是當(dāng)前正在處理的窗品的大小，我們的目標(biāo)就是計(jì)算它的值。一個(gè)窗口的大小是受以下因素影響的：
? ? ? ? ?1. 是否指定了縮放因子。如果一個(gè)窗口的大小被指定了縮放因子，即WindowState類的成員變量mAttrs所指向的一個(gè)WindowManager.LayoutParams對(duì)象的成員變量flags的FLAG_SCALED位等于1，那么該窗口的大小就是在它的布局參數(shù)中指定的，即是由WindowState類的成員變量mAttrs所指向的一個(gè)WindowManager.LayoutParams對(duì)象的成員變量width和height所指定的。但是，如果在布局參數(shù)中指定的窗口寬度或者高度小于0，那么就會(huì)使用其父窗口的大小來作為當(dāng)前窗口的大小。當(dāng)前窗口的父窗口的寬度和高度分別保存在變量pw和ph中。
? ? ? ? ?2. 是否指定了等于父窗口的大小。如果一個(gè)窗口的大小被指定為其父窗口的大小，即WindowState類的成員變量mAttrs所指向的一個(gè)WindowManager.LayoutParams對(duì)象的成員變量width和height的值等于mAttrs.MATCH_PARENT，那么該窗口的大小就會(huì)等于其父窗口的大小，即等于變量pw和ph所描述的寬度和高度。另一方面，如果一個(gè)窗口的大小沒有指定為其父窗口的大小的話，那么它的大小就會(huì)等于應(yīng)用程序進(jìn)程請(qǐng)求WindowManagerService所設(shè)置的大小，即等于WindowState類的成員變量mRequestedWidth和mRequestedHeight所描述的寬度和高度。
? ? ? ? ?經(jīng)過上述2個(gè)操作之后，我們就初步地得到了窗口的寬度w和高度h，但是，它們還不是最終的窗口大小，還要進(jìn)一步地根據(jù)窗口的Gravity屬性來作調(diào)整，這個(gè)調(diào)整分兩步進(jìn)行：
? ? ? ? 1. 根據(jù)窗口的Gravity值，以及位置、初始大小和父窗口大小，來計(jì)算窗口的大小，并且保存在變量frame中，即保存在WindowState類的成員變量mFrame中，這是通過調(diào)用Gravity類的靜態(tài)成員函數(shù)apply來實(shí)現(xiàn)的。其中，窗口的初始大小保存在變量w和h中，父窗口大小保存在變量container中，即WindowState類的成員變量mContainingFrame中，位置保存在WindowState類的成員變量mAttrs所指向的一個(gè)WindowManager.LayoutParams對(duì)象的成員變量x和y中。注意，如果窗口指定了相對(duì)父窗口的margin值，那么還需要相應(yīng)的調(diào)整其位置值，即要在指定的位置值的基礎(chǔ)上，再加上相對(duì)父窗口的margin值。一個(gè)窗口相對(duì)父窗口的margion是通過一個(gè)百分比來表示的，用這個(gè)百分比乘以父窗口的大小就可以得到絕對(duì)值。這個(gè)百分比又分為在水平方向和垂直方向兩個(gè)值，分別保存在WindowState類的成員變量mAttrs所指向的一個(gè)WindowManager.LayoutParams對(duì)象的成員變量horizontalMargin和verticalMargin中。
? ? ? ? 2. 前面計(jì)算得到的窗口大小沒有考慮在屏幕的大小，因此，接下來還需要繼續(xù)調(diào)用Gravity類的靜態(tài)成員函數(shù)applyDisplay來將前面計(jì)算得到的窗口大小限制在屏幕區(qū)域df中，即限制在WindowState類的成員變量mDisplayFrame所描述的區(qū)域中。
? ? ? ? 經(jīng)過上述2個(gè)操作之后，窗口的最終大小就保存在變量frame中了，即WindowState類的成員變量mFrame中，接下來就可以計(jì)算窗品的內(nèi)容區(qū)域邊襯和可見區(qū)域邊襯大小了。
? ? ? ??內(nèi)容區(qū)域邊襯和可見區(qū)域邊襯大小的計(jì)算很簡(jiǎn)單的，只要將窗口的大小frame，即WindowState類的成員變量mFrame所描述的區(qū)域，分別減去變量content和visible，即WindowState類的成員變量mContentFrame和mVisibleFrame所描述的區(qū)域，就可以得到窗口的內(nèi)容區(qū)域邊襯和可見區(qū)域邊襯大小，它們分別保存在WindowState類的成員變量mContentInsets和mVisibleInsets中。注意，在計(jì)算窗口的內(nèi)容區(qū)域邊襯和可見區(qū)域邊襯大小之前，首先要保證窗口的內(nèi)容區(qū)域和可見區(qū)域包含在整個(gè)窗口區(qū)域中，這一點(diǎn)是由中間的8個(gè)if語句來保證的。
? ? ? ? 窗口上一次的大小保存在變量fw和fh中。如果當(dāng)前正在處理的窗口是一個(gè)壁紙窗口，即WindowState類的成員變量mIsWallpaper的值等于true，并且該窗口的大小發(fā)生了變化，即變量fw和fh的所描述的窗口大小不等于變量frame描述的窗口大小，那么就需要調(diào)用WindowManagerService類的成員函數(shù)updateWallpaperOffsetLocked來更新壁紙的位置。在后面的文章中，我們?cè)僭敿?xì)描述系統(tǒng)的壁紙窗口的位置是如何計(jì)算的。
? ? ? ? 這一步執(zhí)行完成之后，一個(gè)窗口的大小就計(jì)算完成了。從計(jì)算的過程可以知道，整個(gè)窗口大小保存在WindowState類的成員變量mFrame中，而窗品的內(nèi)容區(qū)域邊襯大小和可見區(qū)域邊襯大小分別保在WindowState類的成員變量mContentInsets和mVisibleInsets中。這些值最終會(huì)通過前面的Step 4返回給應(yīng)用程序進(jìn)程。
? ? ? ? 返回到前面的Step 7中，即WindowManagerService類的成員函數(shù)performLayoutLockedInner，接下來就會(huì)調(diào)用PhoneWindowManager類的成員函數(shù)finishLayoutLw來結(jié)束當(dāng)前這輪窗口大小的計(jì)算工作。
? ? ? ? Step 11.?PhoneWindowManager.finishLayoutLw
public class PhoneWindowManager implements WindowManagerPolicy {......public int finishLayoutLw() {return 0;}......
}? ? ? ??PhoneWindowManager類的成員函數(shù)finishLayoutLw是設(shè)計(jì)來結(jié)束一輪窗口大小的計(jì)算過程中，不過目前它什么也不做，只是一個(gè)空實(shí)現(xiàn)。
? ? ? ? 至此，我們就分析完成Activity窗口的大小計(jì)算過程了。從這個(gè)計(jì)算過程中，我們就可以知道一個(gè)Activity窗口除了有一個(gè)整體大小之外，還有一個(gè)內(nèi)容區(qū)域邊襯大小和一個(gè)可見區(qū)域邊襯大小。此外，我們還知道，一個(gè)Activity窗口的內(nèi)容區(qū)域邊襯大小和可見區(qū)域邊襯大小是可能會(huì)受到與其所關(guān)聯(lián)的輸入法窗口的影響的，因?yàn)檩斎敕ù翱跁?huì)疊加在該Activity窗口上面，這就涉及到了系統(tǒng)中的窗口的組織方式。在接下來的一篇文章中，我們就將繼續(xù)分析WindowManagerService服務(wù)是如何組織系統(tǒng)中的窗口的。敬請(qǐng)關(guān)注！
老羅的新浪微博：http://weibo.com/shengyangluo，歡迎關(guān)注！
轉(zhuǎn)載于:https://www.cnblogs.com/wuyida/archive/2013/01/14/6300525.html
總結(jié)
以上是生活随笔為你收集整理的Android窗口管理服务WindowManagerService计算Activity窗口大小的过程分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 问价....
- 下一篇： CentOS 6.3 安装 samba