一篇文章教你讀懂UI繪製流程

最近有好多人問我Android沒信心去深造了,找不到好的工作,其實我以一個他們進行回覆,發現他們主要是內心比較浮躁,要知道技術行業永遠缺少的是高手。建議先閱讀淺談Android發展趨勢分析,在工作中,總結菜式王道,沉澱才能成長!

前言

在android當中對於UI體系當中往往我們會在繪製UI的時候碰到各種各樣的問題而不知道從何解決, 也有時需要開發更改自定義組件時,需要做自己的調整,或者是實現某個自定義特效時的思路不明確,想要達到去玩轉UI的最爲基礎的部分,就是去全面的深入瞭解UI的繪製流程.所以接下來帶大家去進行全面分析UI整體的繪製體系.

思路:android程序啓動--->Activity加載並完成生命週期--->setContentView--->圖形繪製

疑惑:

1.Android程序是如何啓動,Activity生命週期如何調用?

2.在Activity onCreate當中我們的setContentView是如何將UI文件加載?

3.UI是如何繪製的?

答案:

1.Android程序流程

衆所周知,我們的java程序想要開啓需要依賴於main方法,也就是我們的程序入口(主線程)進入,但是在我們日常開發android程序的過程當中我們並沒有發現main方法的存在,那麼android當中的是如何開始運行的?

熟悉的朋友們可能都知道在android當中存在一個叫做ActivityThread的類,這個類代表的是android當中的主線程,而在這個類當中我們看到了比較熟悉的main方法,那麼現在是否可以認爲我們的android在打開app時是首先調用的是當前這個類的main,也就是此處爲我們的啓動點

在此處可以看到Activity調用了一個attach()方法

在這裏我們可能首先要考慮的是getService拿出來的是什麼?

進去之後,我們會發現

在這個當中,裏面調用了的系統的ActivityManagerService這個服務,並且給出了一個Binder接口

那麼在這裏,我們可以聯想到,在android當中的binder通信機制,那麼實際上我們的ActivityManager是有系統服務所調用管理,並且通過在binder接口當中進行調用,這也是爲什麼我們講Activity是跨進程訪問的原因

那麼明白了這個時候能夠得到ActivityManager之後,我們接着回到attach當中繼續看下去, 這個時候會發現,我們調用了一個attachApplication方法(見圖2)這個方法又是幹嘛的?attachApplication在這裏的作用其實實際上是ActivityThread通過attach獲取到,然後將applciationThread將其關聯,把activity相關信息存儲在applciationThread裏面,apllicationThread的類爲activity的各種狀態做了相對應的準備工作

這個時候我們需要關注,ApplicationThread當中做了什麼?

當我們打開ApplicationThread中我們會看到一堆的schedle方法,這些方法的名稱其實就可以給我們表明,代表的是在執行Activity的某種狀態時調用的計劃執行方法

這時我們會看到一個scheduleLaunchActivity方法,表示計劃加載時調用的

這裏我門發現了一個很有意思的事情

這個上面我們會看到一個ActivityClientRecord對象,這個對象其實實際上就是我們的Activity

而且似乎每一個方法還幹了一件讓我們非常熟悉的一件事, 進行了一次sendMessage()將當前創建的Activity發送了出去

當走到這裏我們會發現最終我們調用的是Handler的消息通信機制,也就是說,在這裏我們可以總結一下,

當Activity狀態改變時,都會有對應的一個消息發送出去

而接收這裏,我能發現通過發送時不同的狀態,這邊調用了不同的handlerXXXActivity方法

在這裏,我門貌似發現了Activity的生命週期的調用痕跡,那麼其實到此爲止,我門可以得出一個結論,

Application運行的過程當中,對於Activity的操作,狀態轉變,其實實際上是通過Handler消息機制來完成的,

Application當中只管去發, 由消息機制負責調用,因爲在main方法當中我門的Looper輪訓器是一直在進行輪訓的

而當我們在加載Activity的時候,當中調用了一個performLaunchActivity()方法,在這個中間我發現了我們onCreate的調用痕跡

也就是說,到目前爲止我們能夠明白,整個Application加載Activity的整套流程是怎麼回事

那麼接下來我們需要關注的是,在onCreate當中我們所寫的setContentView到底幹了什麼

2.setContentView

在onCreate當中我們往往會使用setContentView去進行設置我們自己的佈局文件或者view,那麼在這當中他到底是怎麼做的?通過觀察源碼,這個時候通過一系列線索我找到了最終的位置PhoneWindow類

這個時候我們會看到他做了兩個事情,一個是installDecor,另一個是inflate,這兩個後一個不難猜出他是在進行佈局文件的解析, 前面的我們認爲她是在初始化某個東西

進來之後發現他初始化了兩個東西,一個叫做mDecor,一個叫做mContentParent

我們看到了mDecor是一個DecorView

mContentParent是一個ViewGroup

透過註釋的翻譯,其實我們就能很明確知道這兩個是用來幹嘛的

// 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.(它要麼是mDecor本身,要麼是mDecor的子類的內容。)

//This is the top-level view of the window, containing the window decor.(這是在窗口當中的頂層View,包含窗口的decor)

一個代表的是頂層view,一個用來裝他下面的視圖內容

在接着往下看的時候,我門發現,generateLayout方法當中,發現了在此處進行了大量的requestFeature的調用,也就是所,我們的requestFeature

然後在下面我門會發現在做了一件事情,

當前這裏竟然在加載佈局文件,並且生成了一個view, 但是好像貌似不是我門自己的

所以我們需要去探尋他到底加載了一個什麼東東?

這是我找到了一個比較有意思的組件,

在這個上面我看到了一句這樣的註釋

//This is an optimized layout for a screen, with the minimum set of features

enabled.

這是一個屏幕的優化佈局,具有最小的特徵集啓用。

通過註釋和一些資料分析, 得到了一個比較坑的結果。

這是DecorView默認的一個渲染,然後我門自己的佈局都是渲染到她的FrameLayout上的

那麼在這裏我門現在能夠明白,installDector其實實際上是在初始化兩個視圖容器,然後加載系統的R資源及特徵,產生了一個基本佈局

那麼接着回到之前我門關注的另外一個方法mLayoutInflater.inflate(layoutResID, mContentParent);

這個方法就比較好理解了,

這這段註釋上面我門就可以得到一個信息

//Inflate a new view hierarchy from the specified xml resource.(從指定的視圖當中獲取試圖的層次結構,意思就是,現在在加載自己的資源)

而具體流程就不貼代碼了給各位上一張圖

那麼在這裏我門就能夠明白,setContentView其實做了兩件比較核心的事情,就是加載環境配置,和自己的佈局,那麼接下來我門需要考慮的事情就是,他到底怎麼畫到界面上的

3.UI是如何繪製的?

通過前面兩個章節,我門瞭解到,程序對於activity生命週期的調用,以及我們的視圖資源的由來。這是我門需要找到的是我門的繪製起點在哪?

在ActivityThread啓動時, 我發現在加載handleLaunchActivity方法調用performLaunchActivity方法之後又調用了一個handleResumeActivity在這裏我發現了繪製流程的開始

通過前面的流程我門知道,onCreate之行完成之後,所有資源交給WindowManager保管

在這裏,將我們的VIew交給了WindowManager,此處調用了addView

進入addView之後我們發現了一段這樣的代碼,他將視圖,和參數還有我門的一個ViewRoot對象都用了容器去裝在了起來,那麼在此處我門可以得出,是將所有的相關對象保存起來

mViews保存的是View對象,DecorView

mRoots保存和頂層View關聯的ViewRootImpl對象

mParams保存的是創建頂層View的layout參數。

而WindowManagerGlobal類也負責和WMS通信

而在此時,有一句關鍵代碼root.setView,這裏是將我們的參數,和視圖同時交給了ViewRoot,那麼這個時候我們來看下ViewRoot當中的setView幹了什麼

終於在這裏讓我發現了讓我明白的一步

在這裏我門會看到view.assignParent的設置是this, 那麼也就是說在view當中parent其實實際上是ViewRoot

那麼在setContentView當中調用了一個setLayoutParams()是調用的ViewRoot的

而在ViewRoot當中發現了setLayoutParams和preformLayout對requestLayout方法的調用

在requestLayout當中發現了對scheduleTraversals方法的調用而scheduleTraversals當中調用了doTraversal的訪問,最終訪問到了performTraversals(),而在這個裏面,我發現了整體的繪製流程的調用

當前裏面依次是用了

UI繪製先回去測量佈局,然後在進行佈局的擺放,當所有的佈局測量擺放完畢之後,進行繪製。

至此整體UI繪製過程我們就已經非常清楚了。

我門可以根據這種繪製的流程來操作自己的自定義組件。

作者:barry 鏈接:https://www.jianshu.com/p/0b1d1124c002,轉載請註明原創

總結

對於我們APP開發者來講,建議大家不要以市場行情的變化而受影響,堅持自己喜歡人認定的路線走下去,沉澱和進步!

2018 互聯網IT開發者簡歷如何脫穎而出

最新2017(Android)面試題級答案(精選版)

如果有什麼的問題,歡迎隨時來撩我。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章