前言
在Activity顯示View
的過程中,有一些重要的角色總讓人理不清,比如PhoneWindow、DecorView、ViewRootImpl
。
也常常有面試題會問到,他們四者之間的關系?創建的時機?View第一次繪制的時機?等問題。
那么今天,就和大家一起從Activity
啟動開始 看看 到展示出View整個過程中,到底會經過哪些步驟,這之間各角色的關系又如何。
動畫展示
為了方便大家理解,先通過動畫的形式給大家展示這幾位的關系:
源碼解析
從小愛誕生說起
在Activity
界面展示之前,它還是個我們看不到的Activity,我給它起了個愛稱——小愛
.
小愛是怎么誕生的呢?熟悉Activity啟動流程的都知道,小愛的創建發生在performLaunchActivity
中:
//ActivityThread.java
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
//創建ContextImpl
ContextImpl appContext = createBaseContextForActivity(r);
Activity activity = null;
try {
java.lang.ClassLoader cl = appContext.getClassLoader();
//創建Activity
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent);
}
try {
if (activity != null) {
//完成activity的一些重要數據的初始化
activity.attach(appContext, this, getInstrumentation(), r.token,
r.ident, app, r.intent, r.activityInfo, title, r.parent,
r.embeddedID, r.lastNonConfigurationInstances, config,
r.referrer, r.voiceInteractor, window, r.configCallback,
r.assistToken);
//調用activity的onCreate方法
if (r.isPersistable()) {
mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
} else {
mInstrumentation.callActivityOnCreate(activity, r.state);
}
}
}
return activity;
}
這個過程中,主要做了三件事:
Activity
被實例化出來- 調用了
attach
方法進行初始化 - 調用
onCreate
方法開始從布局文件加載布局,做View顯示的准備工作。
給小愛找個和View交互的幫手(PhoneWindow)
大家也都知道,小愛
在被創建后,事務繁忙,肯定不能親力親為得管理每個View
,所以他就找了一個幫手,幫助她和View交互,管理View。
(Activity和View的解耦)
這個幫手是啥呢?就是窗口Window,也就是實現類PhoneWindow
了。
這個過程發生在attach
方法中:
//Activity.java
final void attach() {
//創建PhoneWindow
mWindow = new PhoneWindow(this, window, activityConfigCallback);
mWindow.setCallback(this);
mWindow.setWindowManager(
(WindowManager)context.getSystemService(Context.WINDOW_SERVICE),
mToken, mComponent.flattenToString(),
(info.flags & ActivityInfo.FLAG_HARDWARE_ACCELERATED) != 0);
}
為了方便記憶,我們管這個PhoneWindow
管家叫做 窗管家
。
加載布局文件(DecorView)
有了窗管家之后,就可以繼續onCreate
方法了,在onCreate方法中最重要的就是這個setContentView
了。
通過setContentView
可以加載布局文件里的View。
之前說了,View相關的管理工作就交給窗管家,所以就直接調用到PhoneWindow
的setContentView
方法:
//Activity.java
public void setContentView(@LayoutRes int layoutResID) {
getWindow().setContentView(layoutResID);
initWindowDecorActionBar();
}
然后就開始加載布局文件的工作了。
但是考慮到一點,Activity
是有不同的主題的,不同主題就有不同的布局結構。所以得在加載我們自己設置的布局文件之前,設置一個最頂級的View
,作為所有View的老大。
而這個頂層的View就是DecorView
,為了方便,我管他叫做 最頂的小弟,簡稱小弟
。
看看小弟DecorView
是怎么被創建的:
//PhoneWindow.java
@Override
public void setContentView(int layoutResID) {
if (mContentParent == null) {
installDecor();
}
if (!hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
mLayoutInflater.inflate(layoutResID, mContentParent);
}
}
private void installDecor() {
if (mDecor == null) {
mDecor = generateDecor(-1);
} else {
mDecor.setWindow(this);
}
if (mContentParent == null) {
mContentParent = generateLayout(mDecor);
}
}
protected DecorView generateDecor(int featureId) {
return new DecorView(context, featureId, this, getAttributes());
}
就是這樣,小弟DecorView
就被創建出來了,然后就該小弟工作了。
上文說過,小弟DecorView
被創建出來是要干啥的?
要根據不同的主題設置不同的布局結構,這個工作就發生在generateLayout
方法中了,具體咱今天就不分析了。
看似小弟的工作也完成了?
等等,應用自己的布局還沒加載呢嘛,重要的事情還沒開始做呢。
再回到上面的setContentView
方法中,在調用installDecor
方法創建了小弟之后,還做了一件事:
//加載xml布局文件
mLayoutInflater.inflate(layoutResID, mContentParent);
public View inflate(@LayoutRes int resource, @Nullable ViewGroup root, boolean attachToRoot) {
final Resources res = getContext().getResources();
final XmlResourceParser parser = res.getLayout(resource);
try {
return inflate(parser, root, attachToRoot);
} finally {
parser.close();
}
}
而這個inflate
就是我們熟知的加載布局文件的方法。傳入xml布局文件,解析並結合我們傳入的父view——mContentParent
,將其轉化為一個完整的樹結構,最后返回頂層的View。
到這里,setContentView
的工作算是完成了,
簡單的說,就是創建了小弟DecorView
,並且結合這個頂層的view
和我們傳入的xml布局文件
,生成了一個多層結構的View
。
顯示出這個View(ViewRootImpl)
View
有了,結構也定下來了。接下來就是怎么顯示出這個View結構
,讓我們的手機展示出畫面?
沒錯,就是繪制
。
關於View的繪制工作交給誰做比較好呢?回憶下現在的成員:
小愛Activity
:大老板,負責統籌即可。窗管家PhoneWindow
:負責管理各個View。小弟DecorView
:最頂層的View,負責展示主題布局。
好像沒有人選可以負責View
繪制了?繪制這么重要,那就要再招一個朋友來了。
ViewRootImpl
閃亮✨登場,為了方便,我管他叫做 小薇
。
小薇是什么時候創建的呢?
接着看Activity
的調用過程,在onCreate調用完后,就會調用onResume
方法,這又要從handleResumeActivity
方法說起了。
@Override
public void handleResumeActivity() {
//onResume
final ActivityClientRecord r = performResumeActivity(token, finalStateRequest, reason);
//addView
if (r.window == null && !a.mFinished && willBeVisible) {
r.window = r.activity.getWindow();
View decor = r.window.getDecorView();
ViewManager wm = a.getWindowManager();
WindowManager.LayoutParams l = r.window.getAttributes()
wm.addView(decor, l);
}
該方法主要做了兩件事:
- 調用
onResume
方法 - 調用WM的
addView
方法。
小薇好像還沒出來?
繼續看addView方法:
//WindowManagerGlobal.java
public void addView() {
synchronized (mLock) {
root = new ViewRootImpl(view.getContext(), display);
view.setLayoutParams(wparams);
mViews.add(view);
mRoots.add(root);
mParams.add(wparams);
try {
root.setView(view, wparams, panelParentView);
}
}
}
public ViewRootImpl(Context context, Display display) {
mContext = context;
mWindowSession = WindowManagerGlobal.getWindowSession();
mThread = Thread.currentThread();
}
終於,小薇ViewRootImpl
也被創建出來了,而這個ViewRootImpl中,有兩個變量值得關注一下:
mWindowSession
。類型為IWindowSession,是一個Binder對象,用於進程間通信。其在服務器端的實現為Session,可以通過它來完成WMS相關的工作。mThread
。設置了線程變量為當前線程,也就是實例化ViewRootImpl時候的線程。一般進行不同線程更新UI的時候,就會判斷當前線程和mThread是否相等,如果不同,則會拋出異常。
接下來,就是調用ViewRootImpl
的setView
方法,這個方法自然就是小薇ViewRootImpl做事的方法了:
//ViewRootImpl.java
public void setView() {
synchronized (this) {
//繪制
requestLayout();
//調用WMS的addWindow方法
res = mWindowSession.addToDisplay(mWindow, mSeq, mWindowAttributes,
getHostVisibility(), mDisplay.getDisplayId(), mWinFrame,
mAttachInfo.mContentInsets, mAttachInfo.mStableInsets,
mAttachInfo.mOutsets, mAttachInfo.mDisplayCutout, mInputChannel);
//設置this(ViewRootImpl)為view(decorView)的parent
view.assignParent(this);
}
}
主要有三個功能:
- 觸發繪制(具體包括測量、布局、繪制)
//ViewRootImpl.java
@Override
public void requestLayout() {
if (!mHandlingLayoutInLayoutRequest) {
checkThread();
mLayoutRequested = true;
scheduleTraversals();
}
}
->scheduleTraversals()
->performMeasure() performLayout() performDraw()
->measure、layout、draw方法
- 通過Binder調用WMS的addWindow方法
addToDisplay方法最終會WMS所在進程的addWindow方法,為窗口分配Surface,而這個Surface
就是負責顯示最終的界面了,並最終會繪制到屏幕上。
- 設置ViewRootImpl為decorView的parent
這樣設置之后,子view請求繪制的時候(requestLayout),就能一直通過parent最終找到ViewRootImpl,然后由ViewRootImpl
來負責所有View的繪制工作。
整個調用過程是:
View.requestLayout -> DecorView.requestLayout -> ViewRootImpl.requestLayout
//View.java
public void requestLayout() {
if (mParent != null && !mParent.isLayoutRequested()) {
mParent.requestLayout();
}
}
小結
到此,Activity
終於完成了他的啟動生命周期,界面也顯示出來了,小愛也變為了成型的Activity
。
雖然這中間角色比較多,但是每個角色又不可或缺:
因為需要管理View,創建出了 PhoneWindow
;
因為需要根據主題顯示不同的布局結構,創建出了根View DecorView
;
因為需要處理View的各種事件,包括繪制、事件分發,創建出了ViewRootImpl
。
大家各忙各的,並聽命於Activity
。
習題
以前上課的時候,總喜歡學習完知識后做幾個習題,今天也給大家帶來幾個問題,鞏固下知識。
Activity、PhoneWindow、DecorView、ViewRootImpl 之間的關系?
PhoneWindow
:是Activity和View交互的中間層,幫助Activity管理View。DecorView
:是所有View的最頂層View,是所有View的parent。ViewRootImpl
:用於處理View相關的事件,比如繪制,事件分發,也是DecorView的parent。
四者的創建時機?
Activity
創建於performLaunchActivity方法中,在startActivity時候觸發。PhoneWindow
,同樣創建於performLaunchActivity方法中,再具體點就是Activity的attach方法。DecorView
,創建於setContentView->PhoneWindow.installDecor。ViewRootImpl
,創建於handleResumeActivity方法中,最后通過addView被創建。
View的第一次繪制發生在什么時候?
第一次繪制就是發生在handleResumeActivity
方法中,通過addView方法,創建了ViewRootImpl
,並調用了其setView
方法。
最后調用到requestLayout方法開始了布局、測量、繪制的流程。
線程更新UI導致崩潰的原因?
在觸發繪制方法requestLayout中,有個checkThread方法:
void checkThread() {
if (mThread != Thread.currentThread()) {
throw new CalledFromWrongThreadException(
"Only the original thread that created a view hierarchy can touch its views.");
}
}
其中對mThread和當前線程進行了比較。而mThread是在ViewRootImpl
實例化的時候賦值的。
所以崩潰的原因就是 view被繪制到界面時候的線程(也就是ViewRootImpl被創建時候的線程)和進行UI更新時候的線程不是同一個線程。
參考
《Android進階解密》
View這12問
拜拜
感謝大家的閱讀,有一起學習的小伙伴可以關注下我的公眾號——碼上積木❤️❤️
每日一個知識點,積少成多,建立知識體系架構。
這里有一群很好的Android小伙伴,歡迎大家加入~