【工匠若水 http://blog.csdn.net/yanbober 轉載煩請註明出處,尊重分享成果】
1 背景
還記得前面《Android應用setContentView與LayoutInflater加載解析機制源碼分析》這篇文章嗎?我們有分析到Activity中界面加載顯示的基本流程原理,記不記得最終分析結果就是下面的關係:
看見沒有,如上圖中id爲content的內容就是整個View樹的結構,所以對每個具體View對象的操作,其實就是個遞歸的實現。
前面《Android觸摸屏事件派發機制詳解與源碼分析一(View篇)》文章的3-1小節說過Android中的任何一個佈局、任何一個控件其實都是直接或間接繼承自View實現的,當然也包括我們後面一步一步引出的自定義控件也不例外,所以說這些View應該都具有相同的繪製流程與機制才能顯示到屏幕上(因爲他們都具備相同的父類View,可能每個控件的具體繪製邏輯有差異,但是主流程都是一樣的)。經過總結髮現每一個View的繪製過程都必須經歷三個最主要的過程,也就是measure、layout和draw。
既然一個View的繪製主要流程是這三步,那一定有一個開始地方呀,就像一個類從main函數執行一樣呀。對於View的繪製開始調運地方這裏先給出結論,本文後面會反過來分析原因的,先往下看就行。具體結論如下:
整個View樹的繪圖流程是在ViewRootImpl類的performTraversals()方法(這個方法巨長)開始的,該函數做的執行過程主要是根據之前設置的狀態,判斷是否重新計算視圖大小(measure)、是否重新放置視圖的位置(layout)、以及是否重繪 (draw),其核心也就是通過判斷來選擇順序執行這三個方法中的哪個,如下:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 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
- 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
可以看見這個方法的註釋說是用來測Root View的。上面傳入參數後這個函數走的是MATCH_PARENT,使用MeasureSpec.makeMeasureSpec方法組裝一個MeasureSpec,MeasureSpec的specMode等於EXACTLY,specSize等於windowSize,也就是爲何根視圖總是全屏的原因。
其中的mView就是View對象。如下就是整個流程的大致流程圖:
如下我們就依據View繪製的這三個主要流程進行詳細剖析(基於Android5.1.1 API 22源碼進行分析)。
【工匠若水 http://blog.csdn.net/yanbober 轉載煩請註明出處,尊重分享成果】
2 View繪製流程第一步:遞歸measure源碼分析
整個View樹的源碼measure流程圖如下:
2-1 measure源碼分析
先看下View的measure方法源碼,如下:
- 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
- 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
看見註釋信息沒有,他告訴你了很多重要信息。爲整個View樹計算實際的大小,然後設置實際的高和寬,每個View控件的實際寬高都是由父視圖和自身決定的。實際的測量是在onMeasure方法進行,所以在View的子類需要重寫onMeasure方法,這是因爲measure方法是final的,不允許重載,所以View子類只能通過重載onMeasure來實現自己的測量邏輯。
這個方法的兩個參數都是父View傳遞過來的,也就是代表了父view的規格。他由兩部分組成,高2位表示MODE,定義在MeasureSpec類(View的內部類)中,有三種類型,MeasureSpec.EXACTLY表示確定大小, MeasureSpec.AT_MOST表示最大大小, MeasureSpec.UNSPECIFIED不確定。低30位表示size,也就是父View的大小。對於系統Window類的DecorVIew對象Mode一般都爲MeasureSpec.EXACTLY ,而size分別對應屏幕寬高。對於子View來說大小是由父View和子View共同決定的。
在這裏可以看出measure方法最終回調了View的onMeasure方法,我們來看下View的onMeasure源碼,如下:
- 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
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 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
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
看見沒有,其實註釋已經很詳細了(自定義View重寫該方法的指導操作註釋都有說明),不做過多解釋。
對於非ViewGroup的View而言,通過調用上面默認的onMeasure即可完成View的測量,當然你也可以重載onMeasure並調用setMeasuredDimension來設置任意大小的佈局,但一般不這麼做,因爲這種做法不太好,至於爲何不好,後面分析完你就明白了。
我們可以看見onMeasure默認的實現僅僅調用了setMeasuredDimension,setMeasuredDimension函數是一個很關鍵的函數,它對View的成員變量mMeasuredWidth和mMeasuredHeight變量賦值,measure的主要目的就是對View樹中的每個View的mMeasuredWidth和mMeasuredHeight進行賦值,所以一旦這兩個變量被賦值意味着該View的測量工作結束。既然這樣那我們就看看設置的默認尺寸大小吧,可以看見setMeasuredDimension傳入的參數都是通過getDefaultSize返回的,所以再來看下getDefaultSize方法源碼,如下:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
看見沒有,如果specMode等於AT_MOST或EXACTLY就返回specSize,這就是系統默認的規格。
回過頭繼續看上面onMeasure方法,其中getDefaultSize參數的widthMeasureSpec和heightMeasureSpec都是由父View傳遞進來的。getSuggestedMinimumWidth與getSuggestedMinimumHeight都是View的方法,具體如下:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
看見沒有,建議的最小寬度和高度都是由View的Background尺寸與通過設置View的miniXXX屬性共同決定的。
到此一次最基礎的元素View的measure過程就完成了。上面說了View實際是嵌套的,而且measure是遞歸傳遞的,所以每個View都需要measure。實際能夠嵌套的View一般都是ViewGroup的子類,所以在ViewGroup中定義了measureChildren, measureChild, measureChildWithMargins方法來對子視圖進行測量,measureChildren內部實質只是循環調用measureChild,measureChild和measureChildWithMargins的區別就是是否把margin和padding也作爲子視圖的大小。如下我們以ViewGroup中稍微複雜的measureChildWithMargins方法來分析:
- 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
- 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
關於該方法的參數等說明註釋已經描述的夠清楚了。該方法就是對父視圖提供的measureSpec參數結合自身的LayoutParams參數進行了調整,然後再來調用child.measure()方法,具體通過方法getChildMeasureSpec來進行參數調整。所以我們繼續看下getChildMeasureSpec方法代碼,如下:
- 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
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 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
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
可以看見,getChildMeasureSpec的邏輯是通過其父View提供的MeasureSpec參數得到specMode和specSize,然後根據計算出來的specMode以及子View的childDimension(layout_width或layout_height)來計算自身的measureSpec,如果其本身包含子視圖,則計算出來的measureSpec將作爲調用其子視圖measure函數的參數,同時也作爲自身調用setMeasuredDimension的參數,如果其不包含子視圖則默認情況下最終會調用onMeasure的默認實現,並最終調用到setMeasuredDimension。
所以可以看見onMeasure的參數其實就是這麼計算出來的。同時從上面的分析可以看出來,最終決定View的measure大小是View的setMeasuredDimension方法,所以我們可以通過setMeasuredDimension設定死值來設置View的mMeasuredWidth和mMeasuredHeight的大小,但是一個好的自定義View應該會根據子視圖的measureSpec來設置mMeasuredWidth和mMeasuredHeight的大小,這樣的靈活性更大,所以這也就是上面分析onMeasure時說View的onMeasure最好不要重寫死值的原因。
可以看見當通過setMeasuredDimension方法最終設置完成View的measure之後View的mMeasuredWidth和mMeasuredHeight成員纔會有具體的數值,所以如果我們自定義的View或者使用現成的View想通過getMeasuredWidth()和getMeasuredHeight()方法來獲取View測量的寬高,必須保證這兩個方法在onMeasure流程之後被調用才能返回有效值。
還記得前面《Android應用setContentView與LayoutInflater加載解析機制源碼分析》文章3-3小節探討的inflate方法加載一些佈局顯示時指定的大小失效問題嗎?當時只給出了結論,現在給出了詳細原因分析,我想不需要再做過多解釋了吧。
至此整個View繪製流程的第一步就分析完成了,可以看見,相對來說還是比較複雜的,接下來進行小結。
2-2 measure原理總結
通過上面分析可以看出measure過程主要就是從頂層父View向子View遞歸調用view.measure方法(measure中又回調onMeasure方法)的過程。具體measure核心主要有如下幾點:
- MeasureSpec(View的內部類)測量規格爲int型,值由高2位規格模式specMode和低30位具體尺寸specSize組成。其中specMode只有三種值:
- 1
- 2
- 3
- 1
- 2
- 3
-
View的measure方法是final的,不允許重載,View子類只能重載onMeasure來完成自己的測量邏輯。
-
最頂層DecorView測量時的MeasureSpec是由ViewRootImpl中getRootMeasureSpec方法確定的(LayoutParams寬高參數均爲MATCH_PARENT,specMode是EXACTLY,specSize爲物理屏幕大小)。
-
ViewGroup類提供了measureChild,measureChild和measureChildWithMargins方法,簡化了父子View的尺寸計算。
-
只要是ViewGroup的子類就必須要求LayoutParams繼承子MarginLayoutParams,否則無法使用layout_margin參數。
-
View的佈局大小由父View和子View共同決定。
-
使用View的getMeasuredWidth()和getMeasuredHeight()方法來獲取View測量的寬高,必須保證這兩個方法在onMeasure流程之後被調用才能返回有效值。
【工匠若水 http://blog.csdn.net/yanbober 轉載煩請註明出處,尊重分享成果】
3 View繪製流程第二步:遞歸layout源碼分析
在上面的背景介紹就說過,當ViewRootImpl的performTraversals中measure執行完成以後會接着執行mView.layout,具體如下:
- 1
- 2
- 3
- 4
- 5
- 1
- 2
- 3
- 4
- 5
可以看見layout方法接收四個參數,這四個參數分別代表相對Parent的左、上、右、下座標。而且還可以看見左上都爲0,右下分別爲上面剛剛測量的width和height。
至此又迴歸到View的layout(int l, int t, int r, int b)方法中去實現具體邏輯了,所以接下來我們開始分析View的layout過程。
整個View樹的layout遞歸流程圖如下:
3-1 layout源碼分析
layout既然也是遞歸結構,那我們先看下ViewGroup的layout方法,如下:
- 1
- 2
- 3
- 4
- 5
- 6
- 1
- 2
- 3
- 4
- 5
- 6
看着沒有?ViewGroup的layout方法實質還是調運了View父類的layout方法,所以我們看下View的layout源碼,如下:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
看見沒有,類似measure過程,lauout調運了onLayout方法。
對比上面View的layout和ViewGroup的layout方法可以發現,View的layout方法是可以在子類重寫的,而ViewGroup的layout是不能在子類重寫的,言外之意就是說ViewGroup中只能通過重寫onLayout方法。那我們接下來看下ViewGroup的onLayout方法,如下:
- 1
- 2
- 3
- 1
- 2
- 3
看見沒有?ViewGroup的onLayout()方法竟然是一個抽象方法,這就是說所有ViewGroup的子類都必須重寫這個方法。所以在自定義ViewGroup控件中,onLayout配合onMeasure方法一起使用可以實現自定義View的複雜佈局。自定義View首先調用onMeasure進行測量,然後調用onLayout方法動態獲取子View和子View的測量大小,然後進行layout佈局。重載onLayout的目的就是安排其children在父View的具體位置,重載onLayout通常做法就是寫一個for循環調用每一個子視圖的layout(l, t, r, b)函數,傳入不同的參數l, t, r, b來確定每個子視圖在父視圖中的顯示位置。
再看下View的onLayout方法源碼,如下:
- 1
- 2
- 1
- 2
我勒個去!是一個空方法,沒啥可看的。
既然這樣那我們只能分析一個現有的繼承ViewGroup的控件了,就拿LinearLayout來說吧,如下是LinearLayout中onLayout的一些代碼:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
看見沒有,LinearLayout的layout過程是分Vertical和Horizontal的,這個就是xml佈局的orientation屬性設置的,我們爲例說明ViewGroup的onLayout重寫一般步驟就拿這裏的VERTICAL模式來解釋吧,如下是layoutVertical方法源碼:
- 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
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 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
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
從上面分析的ViewGroup子類LinearLayout的onLayout實現代碼可以看出,一般情況下layout過程會參考measure過程中計算得到的mMeasuredWidth和mMeasuredHeight來安排子View在父View中顯示的位置,但這不是必須的,measure過程得到的結果可能完全沒有實際用處,特別是對於一些自定義的ViewGroup,其子View的個數、位置和大小都是固定的,這時候我們可以忽略整個measure過程,只在layout函數中傳入的4個參數來安排每個子View的具體位置。
到這裏就不得不提getWidth()、getHeight()和getMeasuredWidth()、getMeasuredHeight()這兩對方法之間的區別(上面分析measure過程已經說過getMeasuredWidth()、getMeasuredHeight()必須在onMeasure之後使用纔有效)。可以看出來getWidth()與getHeight()方法必須在layout(int l, int t, int r, int b)執行之後纔有效。那我們看下View源碼中這些方法的實現吧,如下:
- 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
- 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
這也解釋了爲什麼有些情況下getWidth()和getMeasuredWidth()以及getHeight()和getMeasuredHeight()會得到不同的值,所以這裏不做過多解釋。
到此整個View的layout過程分析就算結束了,接下來進行一些總結工作。
3-2 layout原理總結
整個layout過程比較容易理解,從上面分析可以看出layout也是從頂層父View向子View的遞歸調用view.layout方法的過程,即父View根據上一步measure子View所得到的佈局大小和佈局參數,將子View放在合適的位置上。具體layout核心主要有以下幾點:
-
View.layout方法可被重載,ViewGroup.layout爲final的不可重載,ViewGroup.onLayout爲abstract的,子類必須重載實現自己的位置邏輯。
-
measure操作完成後得到的是對每個View經測量過的measuredWidth和measuredHeight,layout操作完成之後得到的是對每個View進行位置分配後的mLeft、mTop、mRight、mBottom,這些值都是相對於父View來說的。
-
凡是layout_XXX的佈局屬性基本都針對的是包含子View的ViewGroup的,當對一個沒有父容器的View設置相關layout_XXX屬性是沒有任何意義的(前面《Android應用setContentView與LayoutInflater加載解析機制源碼分析》也有提到過)。
-
使用View的getWidth()和getHeight()方法來獲取View測量的寬高,必須保證這兩個方法在onLayout流程之後被調用才能返回有效值。
【工匠若水 http://blog.csdn.net/yanbober 轉載煩請註明出處,尊重分享成果】
4 View繪製流程第三步:遞歸draw源碼分析
在上面的背景介紹就說過,當ViewRootImpl的performTraversals中measure和layout執行完成以後會接着執行mView.layout,具體如下:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
draw過程也是在ViewRootImpl的performTraversals()內部調運的,其調用順序在measure()和layout()之後,這裏的mView對於Actiity來說就是PhoneWindow.DecorView,ViewRootImpl中的代碼會創建一個Canvas對象,然後調用View的draw()方法來執行具體的繪製工。所以又迴歸到了ViewGroup與View的樹狀遞歸draw過程。
先來看下View樹的遞歸draw流程圖,如下:
如下我們詳細分析這一過程。
4-1 draw源碼分析
由於ViewGroup沒有重寫View的draw方法,所以如下直接從View的draw方法開始分析:
- 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
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 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
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
看見整個View的draw方法很複雜,但是源碼註釋也很明顯。從註釋可以看出整個draw過程分爲了6步。源碼註釋說(”skip step 2 & 5 if possible (common case)”)第2和5步可以跳過,所以我們接下來重點剩餘四步。如下:
第一步,對View的背景進行繪製。
可以看見,draw方法通過調運drawBackground(canvas);方法實現了背景繪製。我們來看下這個方法源碼,如下:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
第三步,對View的內容進行繪製。
可以看到,這裏去調用了一下View的onDraw()方法,所以我們看下View的onDraw方法(ViewGroup也沒有重寫該方法),如下:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 1
- 2
- 3
- 4
- 5
- 6
- 7
可以看見,這是一個空方法。因爲每個View的內容部分是各不相同的,所以需要由子類去實現具體邏輯。
第四步,對當前View的所有子View進行繪製,如果當前的View沒有子View就不需要進行繪製。
我們來看下View的draw方法中的dispatchDraw(canvas);方法源碼,可以看見如下:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
看見沒有,View的dispatchDraw()方法是一個空方法,而且註釋說明了如果View包含子類需要重寫他,所以我們有必要看下ViewGroup的dispatchDraw方法源碼(這也就是剛剛說的對當前View的所有子View進行繪製,如果當前的View沒有子View就不需要進行繪製的原因,因爲如果是View調運該方法是空的,而ViewGroup纔有實現),如下:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
可以看見,ViewGroup確實重寫了View的dispatchDraw()方法,該方法內部會遍歷每個子View,然後調用drawChild()方法,我們可以看下ViewGroup的drawChild方法,如下:
- 1
- 2
- 3
- 1
- 2
- 3
可以看見drawChild()方法調運了子View的draw()方法。所以說ViewGroup類已經爲我們重寫了dispatchDraw()的功能實現,我們一般不需要重寫該方法,但可以重載父類函數實現具體的功能。
第六步,對View的滾動條進行繪製。
可以看到,這裏去調用了一下View的onDrawScrollBars()方法,所以我們看下View的onDrawScrollBars(canvas);方法,如下:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
可以看見其實任何一個View都是有(水平垂直)滾動條的,只是一般情況下沒讓它顯示而已。
到此,View的draw繪製部分源碼分析完畢,我們接下來進行一些總結。
4-2 draw原理總結
可以看見,繪製過程就是把View對象繪製到屏幕上,整個draw過程需要注意如下細節:
-
如果該View是一個ViewGroup,則需要遞歸繪製其所包含的所有子View。
-
View默認不會繪製任何內容,真正的繪製都需要自己在子類中實現。
-
View的繪製是藉助onDraw方法傳入的Canvas類來進行的。
-
區分View動畫和ViewGroup佈局動畫,前者指的是View自身的動畫,可以通過setAnimation添加,後者是專門針對ViewGroup顯示內部子視圖時設置的動畫,可以在xml佈局文件中對ViewGroup設置layoutAnimation屬性(譬如對LinearLayout設置子View在顯示時出現逐行、隨機、下等顯示等不同動畫效果)。
-
在獲取畫布剪切區(每個View的draw中傳入的Canvas)時會自動處理掉padding,子View獲取Canvas不用關注這些邏輯,只用關心如何繪製即可。
-
默認情況下子View的ViewGroup.drawChild繪製順序和子View被添加的順序一致,但是你也可以重載ViewGroup.getChildDrawingOrder()方法提供不同順序。
【工匠若水 http://blog.csdn.net/yanbober 轉載煩請註明出處,尊重分享成果】
5 View的invalidate和postInvalidate方法源碼分析
你可能已經看見了,在上面分析View的三步繪製流程中最後都有調運一個叫invalidate的方法,這個方法是啥玩意?爲何出現頻率這麼高?很簡單,我們拿出來分析分析不就得了。
5-1 invalidate方法源碼分析
來看一下View類中的一些invalidate方法(ViewGroup沒有重寫這些方法),如下:
- 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
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 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
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
看見沒有,View的invalidate(invalidateInternal)方法實質是將要刷新區域直接傳遞給了父ViewGroup的invalidateChild方法,在invalidate中,調用父View的invalidateChild,這是一個從當前向上級父View回溯的過程,每一層的父View都將自己的顯示區域與傳入的刷新Rect做交集 。所以我們看下ViewGroup的invalidateChild方法,源碼如下:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
這個過程最後傳遞到ViewRootImpl的invalidateChildInParent方法結束,所以我們看下ViewRootImpl的invalidateChildInParent方法,如下:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
看見沒有?這個ViewRootImpl類的invalidateChildInParent方法直接返回了null,也就是上面ViewGroup中說的,層層上級傳遞到ViewRootImpl的invalidateChildInParent方法結束了那個do while循環。看見這裏調運的scheduleTraversals這個方法嗎?scheduleTraversals會通過Handler的Runnable發送一個異步消息,調運doTraversal方法,然後最終調用performTraversals()執行重繪。開頭背景知識介紹說過的,performTraversals就是整個View數開始繪製的起始調運地方,所以說View調運invalidate方法的實質是層層上傳到父級,直到傳遞到ViewRootImpl後觸發了scheduleTraversals方法,然後整個View樹開始重新按照上面分析的View繪製流程進行重繪任務。
到此View的invalidate方法原理就分析完成了。
5-2 postInvalidate方法源碼分析
上面分析invalidate方法時註釋中說該方法只能在UI Thread中執行,其他線程中需要使用postInvalidate方法,所以我們來分析分析postInvalidate這個方法源碼。如下:
- 1
- 2
- 3
- 1
- 2
- 3
繼續看下他的調運方法postInvalidateDelayed,如下:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
我們繼續看他調運的ViewRootImpl類的dispatchInvalidateDelayed方法,如下源碼:
- 1
- 2
- 3
- 4
- 1
- 2
- 3
- 4
看見沒有,通過ViewRootImpl類的Handler發送了一條MSG_INVALIDATE消息,繼續追蹤這條消息的處理可以發現:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
看見沒有,實質就是又在UI Thread中調運了View的invalidate();方法,那接下來View的invalidate();方法我們就不說了,上名已經分析過了。
到此整個View的postInvalidate方法就分析完成了。
5-3 invalidate與postInvalidate方法總結
依據上面對View的invalidate分析我總結繪製如下流程圖:
依據上面對View的postInvalidate分析我總結繪製如下流程圖:
關於這兩個方法的具體流程和原理上面也分析過了,流程圖也給出了,相信已經很明確了,沒啥需要解釋的了。所以我們對其做一個整體總結,歸納出重點如下:
invalidate系列方法請求重繪View樹(也就是draw方法),如果View大小沒有發生變化就不會調用layout過程,並且只繪製那些“需要重繪的”View,也就是哪個View(View只繪製該View,ViewGroup繪製整個ViewGroup)請求invalidate系列方法,就繪製該View。
常見的引起invalidate方法操作的原因主要有:
- 直接調用invalidate方法.請求重新draw,但只會繪製調用者本身。
- 觸發setSelection方法。請求重新draw,但只會繪製調用者本身。
- 觸發setVisibility方法。 當View可視狀態在INVISIBLE轉換VISIBLE時會間接調用invalidate方法,繼而繪製該View。當View的可視狀態在INVISIBLE\VISIBLE 轉換爲GONE狀態時會間接調用requestLayout和invalidate方法,同時由於View樹大小發生了變化,所以會請求measure過程以及draw過程,同樣只繪製需要“重新繪製”的視圖。
- 觸發setEnabled方法。請求重新draw,但不會重新繪製任何View包括該調用者本身。
- 觸發requestFocus方法。請求View樹的draw過程,只繪製“需要重繪”的View。
5-4 通過invalidate方法分析結果回過頭去解決一個背景介紹中的疑惑
分析完invalidate後需要你回過頭去想一個問題。還記不記得這篇文章的開頭背景介紹,我們說整個View繪製流程的最初代碼是在ViewRootImpl類的performTraversals()方法中開始的。上面當時只是告訴你了這個結論,至於這個ViewRootImpl類的performTraversals()方法爲何會被觸發沒有說明原因。現在我們就來分析一下這個觸發的源頭。
讓我們先把大腦思考暫時挪回到《Android應用setContentView與LayoutInflater加載解析機制源碼分析》這篇博文的setContentView機制分析中(不清楚的請點擊先看這篇文章再回過頭來繼續看)。我們先來看下那篇博文分析的PhoneWindow的setContentView方法源碼,如下:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
這個方法是Activity中setContentView的實現,我們繼續看下這個方法裏調運的addView方法,也就是ViewGroup的addView方法,如下:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
看見addView調運invalidate方法沒有?這不就真相大白了。當我們寫一個Activity時,我們一定會通過setContentView方法將我們要展示的界面傳入該方法,該方法會講我們界面通過addView追加到id爲content的一個FrameLayout(ViewGroup)中,然後addView方法中通過調運invalidate(true)去通知觸發ViewRootImpl類的performTraversals()方法,至此遞歸繪製我們自定義的所有佈局。
【工匠若水 http://blog.csdn.net/yanbober 轉載煩請註明出處,尊重分享成果】
6 View的requestLayout方法源碼分析
6-1 requestLayout方法分析
和invalidate類似,其實在上面分析View繪製流程時或多或少都調運到了這個方法,而且這個方法對於View來說也比較重要,所以我們接下來分析一下他。如下View的requestLayout源碼:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
看見沒有,當我們觸發View的requestLayout時其實質就是層層向上傳遞,直到ViewRootImpl爲止,然後觸發ViewRootImpl的requestLayout方法,如下就是ViewRootImpl的requestLayout方法:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
看見沒有,類似於上面分析的invalidate過程,只是設置的標記不同,導致對於View的繪製流程中觸發的方法不同而已。
6-2 requestLayout方法總結
可以看見,這些方法都是大同小異。對於requestLayout方法來說總結如下:
requestLayout()方法會調用measure過程和layout過程,不會調用draw過程,也不會重新繪製任何View包括該調用者本身。
7 View繪製流程總結
至此整個關於Android應用程序開發中的View繪製機制及相關重要方法都已經分析完畢。關於各個方法的總結這裏不再重複,直接通過該文章前面的目錄索引到相應方法的總結小節進行查閱即可。
【工匠若水 http://blog.csdn.net/yanbober 轉載煩請註明出處,尊重分享成果】