關于Window，PhoneWindow和WindowManager三者的關系是：
Window是一個抽象類，他的具體實現(xiàn)是PhoneWindow
我們通過WindowManager來管理Window。
我們的所有的界面，例如Activity，Toast，Dialog等都是靠Window來呈現(xiàn)，因此他是View的管理者咯。
很久前用過他的一個功能就是拿來做消息提醒，當有用戶發(fā)來特定消息時候，就跑出來一個小懸浮窗來提示用戶。現(xiàn)在看得多的就是各種管家關于內存的提示！這真的很讓人糾結的安卓機啊！特別是某米的手機，當年發(fā)現(xiàn)他不支持這個功能！搞到得單獨為他開發(fā)一個別的方式....
好了，說這么多，我們該從哪里開始說起呢？
起航
API：23
我們先挑WindowManager 開始吧。
public interface WindowManager extends ViewManager
我們的WiddowManger是一個接口，不是實際干活的人，看下他繼承的ViewManager
public interface ViewManager{
public void addView(View view, ViewGroup.LayoutParams params);
public void updateViewLayout(View view, ViewGroup.LayoutParams params);
public void removeView(View view);
}
定義了我們使用到的三個操作。增加，更新，移除。
那么背后到底誰在干活呢，是WindowManagerImpl
不過很有意思的是，他也是一個殼，實際干活的都交給了WindowManagerGlobal去干了。
public final class WindowManagerImpl implements WindowManager {
private final WindowManagerGlobal mGlobal = WindowManagerGlobal.getInstance();
@Override
public void addView(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {
applyDefaultToken(params);
mGlobal.addView(view, params, mDisplay, mParentWindow);
}
@Override
public void removeView(View view) {
mGlobal.removeView(view, false);
}
@Override
public void updateViewLayout(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {
applyDefaultToken(params);
mGlobal.updateViewLayout(view, params);
}
...
}
addView
我們繼續(xù)跟下，看在addView背后做了什么
public void addView(View view, ViewGroup.LayoutParams params,
Display display, Window parentWindow) {
...
final WindowManager.LayoutParams wparams = (WindowManager.LayoutParams) params;
ViewRootImpl root;
View panelParentView = null;
synchronized (mLock) {
...
root = new ViewRootImpl(view.getContext(), display);
view.setLayoutParams(wparams);
mViews.add(view);
mRoots.add(root);
mParams.add(wparams);
}
// do this last because it fires off messages to start doing things
try {
root.setView(view, wparams, panelParentView);
} catch (RuntimeException e) {
...
}
}
private final ArrayList<View> mViews = new ArrayList<View>();
private final ArrayList<ViewRootImpl> mRoots = new ArrayList<ViewRootImpl>();
private final ArrayList<WindowManager.LayoutParams> mParams =
new ArrayList<WindowManager.LayoutParams>();
我們看到他主要是創(chuàng)建了新的ViewRootImpl，然后將View，ViewRootImpl和params保存起來，最后將View添加進去ViewRootImpl里面去。這里有種感覺，removeView做的就可能和上面的相反，從數(shù)組移除，然后調用root.removeView()的類似函數(shù)去移除。這是猜測，我們先留著，看完我們的主線
我們來看下這個setView里面做了什么
public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
synchronized (this) {
if (mView == null) {
mView = view;
...
requestLayout();
...
try {
mOrigWindowType = mWindowAttributes.type;
mAttachInfo.mRecomputeGlobalAttributes = true;
collectViewAttributes();
res = mWindowSession.addToDisplay(mWindow, mSeq, mWindowAttributes,
getHostVisibility(), mDisplay.getDisplayId(),
mAttachInfo.mContentInsets, mAttachInfo.mStableInsets,
mAttachInfo.mOutsets, mInputChannel);
} catch (RemoteException e) {
...
} finally {
if (restore) {
attrs.restore();
}
}
}
}
}
通過requestLayout，然后去更新界面。
@Override
public void requestLayout() {
if (!mHandlingLayoutInLayoutRequest) {
checkThread();
mLayoutRequested = true;
scheduleTraversals();
}
}
void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
if (!mUnbufferedInputDispatch) {
scheduleConsumeBatchedInput();
}
notifyRendererOfFramePending();
pokeDrawLockIfNeeded();
}
}
那個mTraversalRunnable最后回去調用 performTraversals()，執(zhí)行對界面的更新。
final class TraversalRunnable implements Runnable {
@Override
public void run() {
doTraversal();
}
}
void doTraversal() {
if (mTraversalScheduled) {
...
performTraversals();
..
}
}
關于這個函數(shù)，我們前面在講View的繪制的時候有說到，他最終去調用我們View的measure，layout，draw等方法，在這里就不深入說了。
繼續(xù)回主線
res = mWindowSession.addToDisplay(mWindow, mSeq, mWindowAttributes,
getHostVisibility(), mDisplay.getDisplayId(),
mAttachInfo.mContentInsets, mAttachInfo.mStableInsets,
mAttachInfo.mOutsets, mInputChannel);
這mWindowSession是一個IWindowSession類，就一個Bidner，具體干活的是Session類。
@Override
public int addToDisplay(IWindow window, int seq, WindowManager.LayoutParams attrs,
int viewVisibility, int displayId, Rect outContentInsets, Rect outStableInsets,
Rect outOutsets, InputChannel outInputChannel) {
return mService.addWindow(this, window, seq, attrs, viewVisibility, displayId,
outContentInsets, outStableInsets, outOutsets, outInputChannel);
}
這里看到他最終是用WindowManagerService去添加Window的。這個WMS深似海和AMS一樣的坑啊.每個函數(shù)都是些幾百號才能結束的.我們下次有空再深入看下，還有PW很多內容沒說呢，已經寫了很長了。。
removeView
和原來的套路一樣，我們到WMG去看下，驗證下和一開始的想法是不是一樣的
@Override
public void removeView(View view) {
mGlobal.removeView(view, false);
}
public void removeView(View view, boolean immediate) {
...
synchronized (mLock) {
int index = findViewLocked(view, true);
View curView = mRoots.get(index).getView();
removeViewLocked(index, immediate);
if (curView == view) {
return;
}
}
}
根據(jù)索引去移除View，沒什么好說的，繼續(xù)
private void removeViewLocked(int index, boolean immediate) {
ViewRootImpl root = mRoots.get(index);
View view = root.getView();
if (view != null) {
InputMethodManager imm = InputMethodManager.getInstance();
if (imm != null) {
imm.windowDismissed(mViews.get(index).getWindowToken());
}
}
boolean deferred = root.die(immediate);
if (view != null) {
view.assignParent(null);
if (deferred) {
mDyingViews.add(view);
}
}
}
關于這個InputMethodManager，在前面的添加Window的時候就一直出現(xiàn)，這里沒把它去掉，是因為想說件事，在整個建立的過程中，是涉及到了Input子系統(tǒng)事件分發(fā)流程，建立一個通訊的過程，這個也是一匹布那么長，我們忽略跳過他。。我們繼續(xù)看下那個ViewRootImpl的die()方法。
boolean die(boolean immediate) {
// Make sure we do execute immediately
//if we are in the middle of a traversal or the damage
// done by dispatchDetachedFromWindow will cause havoc on return.
if (immediate && !mIsInTraversal) {
doDie();
return false;
}
if (!mIsDrawing) {
destroyHardwareRenderer();
}
mHandler.sendEmptyMessage(MSG_DIE);
return true;
}
我們的immediate是一個false，所以執(zhí)行的只是下面的用handler去發(fā)送一個消息就結束了 ，然后返回。
這里我們回去看下那個windowMangerImpl的函數(shù)，他有兩個remove方法
@Override
public void removeView(View view) {
mGlobal.removeView(view, false);
}
@Override
public void removeViewImmediate(View view) {
mGlobal.removeView(view, true);
}
結合上面的函數(shù)，我們的出結論，實際移除有同步和異步的方式，同步的方法可能帶來一些問題。
異步方式是發(fā)送消息返回true，而removeViewLocked還把View加入mDyingViews.add(view)死亡數(shù)組去。呵呵，我們繼續(xù)看下去
case MSG_DIE:
doDie();
break;
這個消息執(zhí)行的也是doDie方法啊。。
void doDie() {
...
dispatchDetachedFromWindow();
WindowManagerGlobal.getInstance().doRemoveView(this);
...
}
看下dispatchDetachedFromWindow去做了什么
void dispatchDetachedFromWindow() {
if (mView != null && mView.mAttachInfo != null) {
mAttachInfo.mTreeObserver.dispatchOnWindowAttachedChange(false);
mView.dispatchDetachedFromWindow();
}
mAccessibilityInteractionConnectionManager.ensureNoConnection();
mAccessibilityManager.removeAccessibilityStateChangeListener(
mAccessibilityInteractionConnectionManager);
mAccessibilityManager.removeHighTextContrastStateChangeListener(
mHighContrastTextManager);
removeSendWindowContentChangedCallback();
destroyHardwareRenderer();
setAccessibilityFocus(null, null);
mView.assignParent(null);
mView = null;
mAttachInfo.mRootView = null;
mSurface.release();
...
try {
mWindowSession.remove(mWindow);
} catch (RemoteException e) {
}
mDisplayManager.unregisterDisplayListener(mDisplayListener);
unscheduleTraversals();
}
整個過程先調用View的dispatchDetachedFromWindow()，然后去一堆變量，接著是Session去remove()。
public void remove(IWindow window) {
mService.removeWindow(this, window);
}
好了，我們看到他去調用了AMS的removeWindow方法，和一開添加的時候的設想一直。
最后在我們的doDie（）里面是用WindowManagerGlobal.getInstance().doRemoveView(this);移除
void doRemoveView(ViewRootImpl root) {
synchronized (mLock) {
final int index = mRoots.indexOf(root);
if (index >= 0) {
mRoots.remove(index);
mParams.remove(index);
final View view = mViews.remove(index);
mDyingViews.remove(view);
}
}
if (HardwareRenderer.sTrimForeground && HardwareRenderer.isAvailable()) {
doTrimForeground();
}
}
這部分工作和我們一開始的設想的內容一致啦。
好了，大致的過程我們基本就看完了，最后的update部分類似，就不細寫了。
前進
看完了Window的增加，我們來看下我們的Window吧。
關于Window和Activity的建立過程，查了下資料，背后還是挺復雜的，我們就從一個我們屬性的方法入手
setContentView(R.layout.activity_main);
public void setContentView(int layoutResID) {
getWindow().setContentView(layoutResID);
initWindowDecorActionBar();
}
這里的getWindow函數(shù)就是我們的Window，他的具體實現(xiàn)是PhoneWindow，我們跳過去看下
@Override
public void setContentView(int layoutResID) {
if (mContentParent == null) {
installDecor();
} else if (!hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
mContentParent.removeAllViews();
}
if (hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
final Scene newScene = Scene.getSceneForLayout(mContentParent, layoutResID,
getContext());
transitionTo(newScene);
} else {
mLayoutInflater.inflate(layoutResID, mContentParent);
}
mContentParent.requestApplyInsets();
...
}
先初始化decorView，然后有句熟悉的mLayoutInflater.inflate(layoutResID, mContentParent)
傳遞了mContentParent去inflate，我們需要去看installDecor()里面做了什么。
private void installDecor() {
if (mDecor == null) {
mDecor = generateDecor();
mDecor.setIsRootNamespace(true);
...
}
if (mContentParent == null) {
mContentParent = generateLayout(mDecor);
...
}
}
我們看到的是，這個新生成了一個DecorView，最后通過這個mDecor去生成一個mContentParent。
protected ViewGroup generateLayout(DecorView decor) {
...
View in = mLayoutInflater.inflate(layoutResource, null);
decor.addView(in, new ViewGroup.LayoutParams(MATCH_PARENT, MATCH_PARENT));
mContentRoot = (ViewGroup) in;
ViewGroup contentParent = (ViewGroup)findViewById(ID_ANDROID_CONTENT);
...
return contentParent;
}
這里我們看這里會去inflate我們的View，然后將它賦值給我們的decor，需要補充說下這個inflate的內容就是我們的整個手機界面，前面會根據(jù)不同的選擇判斷來確定是要那個layoutResource的。
所以我們每次例如要求請求全屏等，就需要在這個setContentView前面先調用就是這個原因！
最后這個contentParent似乎看起來和我們的DecorView沒什么關系，我們繼續(xù)看下。
public View findViewById(@IdRes int id) {
return getDecorView().findViewById(id);
}
這個getDecorView（）返回的就是我們的DecorView類的mDecor，我們已經說過他就是PhoneWindow的一個內部類。通過給他一個ID來獲取我們的ContentParent，直覺就是說這個是在DecorView里面的一個childView咯？當然是的，因為前面我們通過inflate得到的view加到我們的decor的時候，那個布局文件里面就有了這個ID了。
@Override
public final View getDecorView() {
if (mDecor == null) {
installDecor();
}
return mDecor;
}
到這里我們重新建立了我們的decor和我們的mContentParent的關系，即后者是前者的一個子View。
這樣我們看完了installDecor()繼續(xù)回到主線，他的下一句
mLayoutInflater.inflate(layoutResID, mContentParent);
我們看到他是根據(jù)傳過來的我們寫的布局ID文件，然后加到我們的mContentParent里面去的。
在繼續(xù)看下去之前，我們補充一張圖片，這里可以解釋下，就是我們的DecorView里面包著我們的界面。
我們的ActionBar和我們的自定義的布局文件。
有了這個概念，我們繼續(xù)下面關于inflate部分的介紹:
public View inflate(int resource, ViewGroup root) {
return inflate(resource, root, root != null);
}
public View inflate(int resource, ViewGroup root, boolean attachToRoot) {
final Resources res = getContext().getResources();
final XmlResourceParser parser = res.getLayout(resource);
try {
return inflate(parser, root, attachToRoot);
} finally {
parser.close();
}
}
public View inflate(XmlPullParser parser, ViewGroup root, boolean attachToRoot) {
synchronized (mConstructorArgs) {
final AttributeSet attrs = Xml.asAttributeSet(parser);
Context lastContext = (Context)mConstructorArgs[0];
mConstructorArgs[0] = mContext;
View result = root;
final String name = parser.getName();
// Temp is the root view that was found in the xml
final View temp = createViewFromTag(root, name, attrs, false);
ViewGroup.LayoutParams params = null;
...
// Inflate all children under temp
rInflate(parser, temp, attrs, true, true);
...
if (root != null && attachToRoot) {
root.addView(temp, params);
}
...
return result;
}
整個過程就成功的根據(jù)我們給的id去找到view，然后加到我們的root里面去。
這樣我們的整個界面的過程是完成了。
另外對于這個PhoneWindow的內容還有很多沒說，其余的設計到了界面的一些設置等等的內容。
public void setStatusBarColor(int color)
public void setNavigationBarColor(int color)
public void setTitle(CharSequence title)
public void setLogo(int resId)
public void setLogo(int resId)
后記
橋接模式
這次看了下還是有點收獲的，例如我們在WindowManger與windowGloabl里面看到了橋接模式的使用-
設置屏幕屬性需要在
setContentView前requestWindowFeature(Window.FEATURE_NO_TITLE); //設置無標題 getWindow().setFlags(WindowManager.LayoutParams.FILL_PARENT, WindowManager.LayoutParams.FILL_PARENT); //設置全屏 setContentView(R.layout.activity_main );
以前可以這么寫全屏，但需要在 setContentView(）函數(shù)前，原因我的Window的創(chuàng)建是在他里面。
