『壹』 android的自定義View的實現原理哪位能給我個思路呢。謝謝。
如果說要按類型來劃分的話，自定義View的實現方式大概可以分為三種，自繪控制項、組合控制項、以及繼承控制項。那麼下面我們就來依次學習一下，每種方式分別是如何自定義View的。
一、自繪控制項
自繪控制項的意思就是，這個View上所展現的內容全部都是我們自己繪制出來的。繪制的代碼是寫在onDraw()方法中的，而這部分內容我們已經在Android視圖繪制流程完全解析，帶你一步步深入了解View(二)中學習過了。
下面我們准備來自定義一個計數器View，這個View可以響應用戶的點擊事件，並自動記錄一共點擊了多少次。新建一個CounterView繼承自View，代碼如下所示：
<?xmlversion="1.0"encoding="utf-8"?>
<RelativeLayoutxmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="50dp"
android:background="#ffcb05">
<Button
android:id="@+id/button_left"
android:layout_width="60dp"
android:layout_height="40dp"
android:layout_centerVertical="true"
android:layout_marginLeft="5dp"
android:background="@drawable/back_button"
android:text="Back"
android:textColor="#fff"/>
<TextView
android:id="@+id/title_text"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_centerInParent="true"
android:text="ThisisTitle"
android:textColor="#fff"
android:textSize="20sp"/>
</RelativeLayout>
在這個布局文件中，我們首先定義了一個RelativeLayout作為背景布局，然後在這個布局裡定義了一個Button和一個TextView，Button就是標題欄中的返回按鈕，TextView就是標題欄中的顯示的文字。
接下來創建一個TitleView繼承自FrameLayout，代碼如下所示：
{
privateButtonleftButton;
privateTextViewtitleText;
publicTitleView(Contextcontext,AttributeSetattrs){
super(context,attrs);
LayoutInflater.from(context).inflate(R.layout.title,this);
titleText=(TextView)findViewById(R.id.title_text);
leftButton=(Button)findViewById(R.id.button_left);
leftButton.setOnClickListener(newOnClickListener(){
@Override
publicvoidonClick(Viewv){
((Activity)getContext()).finish();
}
});
}
publicvoidsetTitleText(Stringtext){
titleText.setText(text);
}
publicvoidsetLeftButtonText(Stringtext){
leftButton.setText(text);
}
(OnClickListenerl){
leftButton.setOnClickListener(l);
}
}TitleView中的代碼非常簡單，在TitleView的構建方法中，我們調用了LayoutInflater的inflate()方法來載入剛剛定義的title.xml布局，這部分內容我們已經在Android LayoutInflater原理分析，帶你一步步深入了解View(一)這篇文章中學習過了。
接下來調用findViewById()方法獲取到了返回按鈕的實例，然後在它的onClick事件中調用finish()方法來關閉當前的Activity，也就相當於實現返回功能了。
另外，為了讓TitleView有更強地擴展性，我們還提供了setTitleText()、setLeftButtonText()、setLeftButtonListener()等方法，分別用於設置標題欄上的文字、返回按鈕上的文字、以及返回按鈕的點擊事件。
到了這里，一個自定義的標題欄就完成了，那麼下面又到了如何引用這個自定義View的部分，其實方法基本都是相同的，在布局文件中添加如下代碼：
<RelativeLayoutxmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent">
<com.example.customview.TitleView
android:id="@+id/title_view"
android:layout_width="match_parent"
android:layout_height="wrap_content">
</com.example.customview.TitleView>
</RelativeLayout>
這樣就成功將一個標題欄控制項引入到布局文件中了，運行一下程序。
現在點擊一下Back按鈕，就可以關閉當前的Activity了。如果你想要修改標題欄上顯示的內容，或者返回按鈕的默認事件，只需要在Activity中通過findViewById()方法得到TitleView的實例，然後調用setTitleText()、setLeftButtonText()、setLeftButtonListener()等方法進行設置就OK了。
『貳』 android 繪制過程，onmeasure 的原理，解決了什麼問題
Android中View的繪制過程
當Activity獲得焦點時，它將被要求繪制自己的布局，Android
framework將會處理繪制過程，Activity只需提供它的布局的根節點。
繪制過程從布局的根節點開始，從根節點開始測量和繪制整個layout
tree。
每一個ViewGroup
負責要求它的每一個孩子被繪制，每一個View負責繪制自己。
因為整個樹是按順序遍歷的，所以父節點會先被繪制，而兄弟節點會按照它們在樹中出現的順序被繪制。
繪制是一個兩遍（two
pass）的過程：一個measure
pass和一個layout
pass。
測量過程（measuring
pass）是在measure(int,
int)中實現的，是從樹的頂端由上到下進行的。
在這個遞歸過程中，每一個View會把自己的dimension
specifications傳遞下去。
在measure
pass的最後，每一個View都存儲好了自己的measurements，即測量結果。
第二個是布局過程（layout
pass），它發生在
layout(int,
int,
int,
int)中，仍然是從上到下進行（top-down）。
在這一遍中，每一個parent都會負責用測量過程中得到的尺寸，把自己的所有孩子放在正確的地方。
『叄』 Android的UI底層是用CPU繪圖的還是GPU繪圖的呢
安卓有2種繪制模型：
一．軟體繪制模型，這里由CPU主導繪圖，視圖按照以下2個步驟繪圖。
讓視圖結構(view hierarchy)失效。
繪制整個視圖結構。
當應用程序需要更新它的部分UI時，都會調用內容發生改變的View對象的invalidate()方法。無效（invalidation）消息請求會在View對象層次結構中傳遞，以便計算出需要重繪的屏幕區域（臟區）。然後，Android系統會在View層次結構中繪制所有的跟臟區相交的區域。但是，這種方法有兩個缺點：
1. 繪制了不需要重繪的視圖（與臟區域相交的區域）
2. 掩蓋了一些應用的bug（由於會重繪與臟區域相交的區域）
注意：在View對象的屬性發生變化時，如背景色或TextView對象中的文本等，Android系統會自動的調用該View對象的invalidate()方法。
二．硬體加速繪制模型，這里由GPU主導繪圖，視圖按照以下3個步驟繪圖。
讓視圖結構失效。
記錄和更新顯示列表（Display List)。
繪制顯示列表。
這種模式下，Android系統依然會使用invalidate()方法和draw()方法來請求屏幕更新和展現View對象。但Android系統並不是立即執行繪制命令，而是首先把這些View的繪制函數作為繪制指令記錄一個顯示列表中，然後再讀取顯示列表中的繪制指令調用OpenGL相關函數完成實際繪制。另一個優化是，Android系統只需要針對由invalidate()方法調用所標記的View對象的臟區進行記錄和更新顯示列表。沒有失效的View對象就簡單重用先前顯示列表記錄的繪制指令來進行簡單的重繪工作。
使用顯示列表的目的是，把視圖的各種繪制函數翻譯成繪制指令保存起來，對於沒有發生改變的視圖把原先保存的操作指令重新讀取出來重放一次就可以了，提高了視圖的顯示速度。而對於需要重繪的View，則更新顯示列表，然後再調用OpenGL完成繪制。
在這種繪制模型下，不能依賴一個視圖與臟區(dirty region)相交而導致它的draw()方法被自動調用，所以必須要手動調用該視圖的invalidate()方法去更新顯示列表。如果忘記這么做可能導致視圖在改變後不會發生變化。
『肆』 android繪圖，怎麼才能做出拖動畫布效果
使用卡馬克地圖緩沖演算法。
基本原理是使用drawBitmap (Bitmap bitmap, Rect src, RectF dst, Paint paint）方法。
將點陣圖上指定的部分（src矩形部分）繪制到指定的屏幕位置（dst矩形部分），通過改變src矩形的位置改變實現地圖的移動。
給你個連接，自己先看看。
http://xys289187120.blog.51cto.com/3361352/656998
『伍』 要掌握Android的畫圖，首先就要了解一下，基本用到的圖形介面：
定義canvas，在canvas上用paint畫出自己想要畫的東西。畫圖形，寫字都行
『陸』 Android 重學系列 View的繪制流程(六) 硬體渲染(上)
本文開始聊聊Android中的硬體渲染。如果跟著我的文章順序，從SF進程到App進程的繪制流程一直閱讀，我們到這里已經有了一定的基礎，可以試著進行橫向比對如Chrome瀏覽器渲染流程，看看軟體渲染，硬體渲染，SF合成都做了什麼程度的優化。
先讓我們回顧一下負責硬體渲染的主體對象ThreadedRenderer在整個繪制流程中做了哪幾個步驟。
在硬體渲染的過程中，有一個很核心的對象RenderNode，作為每一個View繪制的節點對象。
當每一次進行准備進行繪制的時候，都會雷打不動執行如下三個步驟：
如果遇到什麼問題歡迎來到 https://www.jianshu.com/p/c84bfa909810 下進行討論
實際上整個硬體渲染的設計還是比較龐大。因此本文先聊聊ThreadedRender整個體系中主要對象的構造以及相關的原理。
首先來認識下面幾個重要的對象有一個大體的印象。
在java層中面向Framework中，只有這么多，下面是一一映射的簡圖。
能看到實際上RenderNode也會跟著View 樹的構建同時一起構建整個顯示層級。也是因此ThreadedRender也能以RenderNode為線索構建出一套和軟體渲染一樣的渲染流程。
僅僅這樣？如果只是這么簡單，知道我習慣的都知道，我喜歡把相關總結寫在最後。如果把總攬寫在正文開頭是因為設計比較繁多。因為我們如果以流水線的形式進行剖析容易造成迷失細節的困境。
讓我繼續介紹一下，在硬體渲染中native層的核心對象。
如下是一個思維導圖：
有這么一個大體印象後，就不容易迷失在源碼中。我們先來把這些對象的實例化以及上面列舉的ThreadedRenderer在ViewRootImpl中執行行為的順序和大家來聊聊其原理，先來看看ThreadedRenderer的實例化。
當發現mSurfaceHolder為空的時候會調用如下函數：
而這個方法則調用如下的方法對ThreadedRenderer進行創建：
文件：/ frameworks / base / core / java / android / view / ThreadedRenderer.java
能不能創建的了ThreadedRenderer則決定於全局配置。如果ro.kernel.qemu的配置為0，說明支持OpenGL 則可以直接返回true。如果qemu.gles為-1說明不支持OpenGL es返回false，只能使用軟體渲染。如果設置了qemu.gles並大於0，才能打開硬體渲染。
我們能看到ThreadedRenderer在初始化，做了三件事情：
關鍵是看1-3點中ThreadRenderer都做了什麼。
文件：/ frameworks / base / core / jni / android_view_ThreadedRenderer.cpp
能看到這里是直接實例化一個RootRenderNode對象，並把指針的地址直接返回。
能看到RootRenderNode繼承了RenderNode對象，並且保存一個JavaVM也就是我們所說的Java虛擬機對象，一個java進程全局只有一個。同時通過getForThread方法，獲取ThreadLocal中的Looper對象。這里實際上拿的就是UI線程的Looper。
在這個構造函數有一個mDisplayList十分重要，記住之後會頻繁出現。接著來看看RenderNode的頭文件：
文件：/ frameworks / base / libs / hwui / RenderNode.h
實際上我把幾個重要的對象留下來：
文件：/ frameworks / base / core / java / android / view / RenderNode.java
能看到很簡單，就是包裹一個native層的RenderNode返回一個Java層對應的對象開放Java層的操作API。
能看到這個過程生成了兩個對象：
這個對象實際上讓RenderProxy持有一個創建動畫上下文的工廠。RenderProxy可以通過ContextFactoryImpl為每一個RenderNode創建一個動畫執行對象的上下文AnimationContextBridge。
文件：/ frameworks / base / libs / hwui / renderthread / RenderProxy.cpp
在這里有幾個十分重要的對象被實例化，當然這幾個對象在聊TextureView有聊過( SurfaceView和TextureView 源碼淺析 )：
我們依次看看他們初始化都做了什麼。
文件：/ frameworks / base / libs / hwui / renderthread / RenderThread.cpp
能看到其實就是簡單的調用RenderThread的構造函數進行實例化，並且返回對象的指針。
RenderThread是一個線程對象。先來看看其頭文件繼承的對象：
文件：/ frameworks / base / libs / hwui / renderthread / RenderThread.h
其中RenderThread的中進行排隊處理的任務隊列實際上是來自ThreadBase的WorkQueue對象。
文件：/ frameworks / base / libs / hwui / thread / ThreadBase.h
ThreadBase則是繼承於Thread對象。當調用start方法時候其實就是調用Thread的run方法啟動線程。
另一個更加關鍵的對象，就是實例化一個Looper對象到WorkQueue中。而直接實例化Looper實際上就是新建一個Looper。但是這個Looper並沒有獲取當先線程的Looper，這個Looper做什麼的呢？下文就會揭曉。
WorkQueue把一個Looper的方法指針設置到其中，其作用可能是完成了某一件任務後喚醒Looper繼續工作。
而start方法會啟動Thread的run方法。而run方法最終會走到threadLoop方法中，至於是怎麼走進來的，之後有機會會解剖虛擬機的源碼線程篇章進行講解。
在threadloop中關鍵的步驟有如下四個：
在這個過程中創建了幾個核心對象：
另一個核心的方法就是，這個方法為WorkQueue的Looper注冊了監聽：
能看到在這個Looper中注冊了對DisplayEventReceiver的監聽，也就是Vsync信號的監聽，回調方法為displayEventReceiverCallback。
我們暫時先對RenderThread的方法探索到這里，我們稍後繼續看看回調後的邏輯。
文件：/ frameworks / base / libs / hwui / thread / ThreadBase.h
能看到這里的邏輯很簡單實際上就是調用Looper的pollOnce方法，阻塞Looper中的循環，直到Vsync的信號到來才會繼續往下執行。詳細的可以閱讀我寫的 Handler與相關系統調用的剖析 系列文章。
文件：/ frameworks / base / libs / hwui / thread / ThreadBase.h
實際上調用的是WorkQueue的process方法。
文件：/ frameworks / base / libs / hwui / thread / WorkQueue.h
能看到這個過程中很簡單，幾乎和Message的loop的邏輯一致。如果Looper的阻塞打開了，則首先找到預計執行時間比當前時刻都大的WorkItem。並且從mWorkQueue移除，最後添加到toProcess中，並且執行每一個WorkItem的work方法。而每一個WorkItem其實就是通過從某一個壓入方法添加到mWorkQueue中。
到這里，我們就明白了RenderThread中是如何消費渲染任務的。那麼這些渲染任務又是哪裡誕生呢？
上文聊到了在RenderThread中的Looper會監聽Vsync信號，當信號回調後將會執行下面的回調。
能看到這個方法的核心實際上就是調用drainDisplayEventQueue方法，對ui渲染任務隊列進行處理。
能到在這里mVsyncRequested設置為false，且mFrameCallbackTaskPending將會設置為true，並且調用queue的postAt的方法執行ui渲染方法。
還記得queue實際是是指WorkQueue，而WorkQueue的postAt方法實際實現如下：
/ frameworks / base / libs / hwui / thread / WorkQueue.h
情景帶入，當一個Vsync信號達到Looper的監聽者，此時就會通過WorkQueue的drainDisplayEventQueue 壓入一個任務到隊列中。
每一個默認的任務都是執行dispatchFrameCallback方法。這里的判斷mWorkQueue中是否存在比當前時間更遲的時刻，並返回這個WorkItem。如果這個對象在頭部needsWakeup為true，說明可以進行喚醒了。而mWakeFunc這個方法指針就是上面傳下來：
把阻塞的Looper喚醒。當喚醒後就繼續執行WorkQueue的process方法。也就是執行dispatchFrameCallbacks方法。
在這里執行了兩個事情：
先添加到集合中，在上面提到過的threadLoop中，會執行如下邏輯：
如果大小不為0，則的把中的IFrameCallback全部遷移到mFrameCallbacks中。
而這個方法什麼時候調用呢？稍後就會介紹。其實這部分的邏輯在TextureView的解析中提到過。
接下來將會初始化一個重要對象：
這個對象名字叫做畫布的上下文，具體是什麼上下文呢？我們現在就來看看其實例化方法。
文件：/ frameworks / base / libs / hwui / renderthread / CanvasContext.cpp
文件：/ device / generic / goldfish / init.ranchu.rc
在init.rc中默認是opengl，那麼我們就來看看下面的邏輯：
首先實例化一個OpenGLPipeline管道，接著OpenGLPipeline作為參數實例化CanvasContext。
文件：/ frameworks / base / libs / hwui / renderthread / OpenGLPipeline.cpp
能看到在OpenGLPipeline中，實際上就是存儲了RenderThread對象，以及RenderThread中的mEglManager。透過OpenGLPipeline來控制mEglManager進而進一步操作OpenGL。
做了如下操作：
文件：/ frameworks / base / libs / hwui / renderstate / RenderState.cpp
文件：/ frameworks / base / libs / hwui / renderthread / DrawFrameTask.cpp
實際上就是保存這三對象RenderThread；CanvasContext；RenderNode。
文件：/ frameworks / base / core / jni / android_view_ThreadedRenderer.cpp
能看到實際上就是調用RenderProxy的setName方法給當前硬體渲染對象設置名字。
文件：/ frameworks / base / libs / hwui / renderthread / RenderProxy.cpp
能看到在setName方法中，實際上就是調用RenderThread的WorkQueue，把一個任務隊列設置進去，並且調用runSync執行。
能看到這個方法實際上也是調用post執行排隊執行任務，不同的是，這里使用了線程的Future方式，阻塞了執行，等待CanvasContext的setName工作完畢。
『柒』 android ScrollView實現原理，求助
視圖的滾動過程，其實是在不斷修改原點坐標。當手指觸摸後，ScrollView會暫時攔截觸摸事件，使用一個計時器。
假如在計時器到點後沒有發生手指移動事件，那麼ScrollView發送tracking events到被點擊的subView；若是在計時器到點後發生了移動事件，那麼ScrollView取消tracking自己促發滾動。
其子類可以重載
touchesShouldBegin: withEvent: inContentView: 決定自己是否接收touch事件。
pagingEnabled: 當值是YES會自動滾動到subView的邊界，默認是NO。
: 開始發送tracking messages消息給subView的時候會調用這個方法。以決定是否發送tracking messages消息到subView。假如返回NO，發送。YES則不發送。若是canCancelContentTouches屬性是NO，則不調用這個方法來影響如何處理滾動手勢。
ScrollView還可處理縮放和平移手勢，要實現這必須實現委託viewForZoomingInScrollView:和scrollViewDidEndZooming: withView: atScale:兩個方法。另外maximumZoomScale和minimumZoomScale兩個屬性要不一樣。
常用屬性介紹
maximumZoomScale 能放大的最大倍數，是浮點數。
minimumZoomScale 能縮小的最小倍數，是浮點數。
pagingEnabled 是否自動滾動到subView邊界
scrollEnabled 是否可以滾動
contentSize 裡面內容的大小，即可以滾動的大小，默認是0，沒有滾動效果
滾動時是否顯示水平滾動條
showsVerticalScrollIndicator 滾動時是否顯示垂直滾動條
bounces 默認是YES，就是滾動超過邊界會反彈，即有反彈回來的效果。若是NO，則滾動到達邊界會立刻停止
bouncesZoom 與bounces類似，只是反映在縮放效果上。
directionalLockEnabled 默認是NO，可以在垂直和水平方向同時運動。當值是YES時，視哪個方向開始則鎖定另外一個方向的滾動。
indicatorStyle 滾動條的樣式。總共3色：默認、黑、白
scrollIndicatorInsets 設置滾動條位置
tracking 當touch後還沒有拖動的時候是YES，否則NO
zoomBouncing 當內容放大到最大或者最小的時候值是YES，否則NO
zooming 當正在縮放的時候值是YES，否則NO
decelerating 當滾動後，手指放開但還在繼續滾動中。此時是YES，其它時候都是NO
decelerationRate 設置手指放開後的減速率
基本使用方法：
初始化：一般的控制項初始化都是可以用alloc和init來初始化的。
UIScrollView *sv = [[UIScrollView alloc] initWithFrame:CGRectMake(0.0,0.0,self.view.frame.size.width, 400)];
關於控制項添加與初始化，建議都採用代碼調用合適的初始化方法來操作，雖然IB布局能夠節省時間，但不能哪過很好了解整個代碼執行流程。
委託方法：UIScrollView也要指定委託對象，該委託對象的控制器同樣也要遵循UIScrollViewDelegate協議，實現其相應的代理方法。
scrollViewDidScroll:
scrollViewWillBeginDragging:
scrollViewDidEndDragging:
scrollViewDidEndDecelerating:
屬性作用CGPoint contentOffSet監控目前滾動的位置CGSize contentSize滾動范圍的大小UIEdgeInsets contentInset視圖在scrollView中的位置id<UIScrollerViewDelegate>
delegate設置協議BOOL directionalLockEnabled指定控制項是否只能在一個方向上滾動BOOL bounces控制控制項遇到邊框是否反彈BOOL alwaysBounceVertical控制垂直方向遇到邊框是否反彈BOOL alwaysBounceHorizontal控制水平方向遇到邊框是否反彈BOOL pagingEnabled控制控制項是否整頁翻動BOOL scrollEnabled控制控制項是否能滾動BOOL 控制是否顯示水平方向的滾動條BOOL
showsVerticalScrollIndicator控制是否顯示垂直方向的滾動條UIEdgeInsets scrollIndicatorInsets指定滾動條在scrollerView中的位置UIScrollViewIndicatorStyle
indicatorStyle設定滾動條的樣式float decelerationRate改變scrollerView的減速點位置BOOL tracking監控當前目標是否正在被跟蹤BOOL dragging監控當前目標是否正在被拖拽BOOL decelerating監控當前目標是否正在減速BOOL delaysContentTouches控制視圖是否延時調用開始滾動的方法BOOL canCancelContentTouches控制控制項是否接觸取消touch的事件float minimumZoomScale縮小的最小比例float maximumZoomScale放大的最大比例float zoomScale設置變化比例BOOL bouncesZoom控制縮放的時候是否會反彈BOOL zooming判斷控制項的大小是否正在改變BOOL zoomBouncing判斷是否正在進行縮放反彈BOOL scrollsToTop控制控制項滾動到頂部
這里把UIScrollView的幾個要點總結下：
從你的手指touch屏幕開始，scrollView開始一個timer，如果：
1. 150ms內如果你的手指沒有任何動作，消息就會傳給subView。
2. 150ms內手指有明顯的滑動（一個swipe動作），scrollView就會滾動，消息不會傳給subView，這里就是產生問題二的原因。
3. 150ms內手指沒有滑動，scrollView將消息傳給subView，但是之後手指開始滑動，scrollView傳送touchesCancelled消息給subView，然後開始滾動。
觀察下tableView的情況，你先按住一個cell，cell開始高亮，手不要放開，開始滑動，tableView開始滾動，高亮取消。
delaysContentTouches的作用：
這個標志默認是YES，使用上面的150ms的timer，如果設置為NO，touch事件立即傳遞給subView，不會有150ms的等待。
cancelsTouches的作用：
這個標准默認為YES，如果設置為NO，這消息一旦傳遞給subView，這scroll事件不會再發生。
『捌』 Android UI繪制之View繪制的工作原理
這是AndroidUI繪制流程分析的第二篇文章，主要分析界面中View是如何繪制到界面上的具體過程。
ViewRoot 對應於 ViewRootImpl 類，它是連接 WindowManager 和 DecorView 的紐帶，View的三大流程均是通過 ViewRoot 來完成的。在 ActivityThread 中，當 Activity 對象被創建完畢後，會將 DecorView 添加到 Window 中,同時會創建 ViewRootImpl 對象，並將 ViewRootImpl 對象和 DecorView 建立關聯。
measure 過程決定了 View 的寬/高， Measure 完成以後，可以通過 getMeasuredWidth 和 getMeasuredHeight 方法來獲取 View 測量後的寬/高，在幾乎所有的情況下，它等同於View的最終的寬/高，但是特殊情況除外。 Layout 過程決定了 View 的四個頂點的坐標和實際的寬/高，完成以後，可以通過 getTop、getBottom、getLeft 和 getRight 來拿到View的四個頂點的位置，可以通過 getWidth 和 getHeight 方法拿到View的最終寬/高。 Draw 過程決定了 View 的顯示，只有 draw 方法完成後 View 的內容才能呈現在屏幕上。
DecorView 作為頂級 View ，一般情況下，它內部會包含一個豎直方向的 LinearLayout ，在這個 LinearLayout 裡面有上下兩個部分，上面是標題欄，下面是內容欄。在Activity中，我們通過 setContentView 所設置的布局文件其實就是被加到內容欄中的，而內容欄id為 content 。可以通過下面方法得到 content:ViewGroup content = findViewById(R.android.id.content) 。通過 content.getChildAt(0) 可以得到設置的 view 。 DecorView 其實是一個 FrameLayout , View 層的事件都先經過 DecorView ，然後才傳遞給我們的 View 。
MeasureSpec 代表一個32位的int值，高2位代表 SpecMode ,低30位代表 SpecSize , SpecMode 是指測量模式，而 SpecSize 是指在某種測量模式下的規格大小。
SpecMode 有三類，如下所示：
UNSPECIFIED
EXACTLY
AT_MOST
LayoutParams需要和父容器一起才能決定View的MeasureSpec，從而進一步決定View的寬/高。
對於頂級View，即DecorView和普通View來說，MeasureSpec的轉換過程略有不同。對於DecorView，其MeasureSpec由窗口的尺寸和其自身的LayoutParams共同確定；
對於普通View，其MeasureSpec由父容器的MeasureSpec和自身的Layoutparams共同決定；
MeasureSpec一旦確定，onMeasure就可以確定View的測量寬/高。
小結一下
當子 View 的寬高採用 wrap_content 時，不管父容器的模式是精確模式還是最大模式，子 View 的模式總是最大模式+父容器的剩餘空間。
View 的工作流程主要是指 measure 、 layout 、 draw 三大流程，即測量、布局、繪制。其中 measure 確定 View 的測量寬/高， layout 確定 view 的最終寬/高和四個頂點的位置，而 draw 則將 View 繪制在屏幕上。
measure 過程要分情況，如果只是一個原始的 view ，則通過 measure 方法就完成了其測量過程，如果是一個 ViewGroup ，除了完成自己的測量過程外，還會遍歷調用所有子元素的 measure 方法，各個子元素再遞歸去執行這個流程。
如果是一個原始的 View，那麼通過 measure 方法就完成了測量過程，在 measure 方法中會去調用 View 的 onMeasure 方法，View 類裡面定義了 onMeasure 方法的默認實現:
先看一下 getSuggestedMinimumWidth 和 getSuggestedMinimumHeight 方法的源碼：
可以看到， getMinimumWidth 方法獲取的是 Drawable 的原始寬度。如果存在原始寬度（即滿足 intrinsicWidth > 0），那麼直接返回原始寬度即可；如果不存在原始寬度（即不滿足 intrinsicWidth > 0），那麼就返回 0。
接著看最重要的 getDefaultSize 方法：
如果 specMode 為 MeasureSpec.UNSPECIFIED 即未指定模式，那麼返回由方法參數傳遞過來的尺寸作為 View 的測量寬度和高度；
如果 specMode 不是 MeasureSpec.UNSPECIFIED 即是最大模式或者精確模式，那麼返回從 measureSpec 中取出的 specSize 作為 View 測量後的寬度和高度。
看一下剛才的表格：
當 specMode 為 EXACTLY 或者 AT_MOST 時，View 的布局參數為 wrap_content 或者 match_parent 時，給 View 的 specSize 都是 parentSize 。這會比建議的最小寬高要大。這是不符合我們的預期的。因為我們給 View 設置 wrap_content 是希望View的大小剛好可以包裹它的內容。
因此：
如果是一個 ViewGroup，除了完成自己的 measure 過程以外，還會遍歷去調用所有子元素的 measure 方法，各個子元素再遞歸去執行 measure 過程。
ViewGroup 並沒有重寫 View 的 onMeasure 方法，但是它提供了 measureChildren、measureChild、measureChildWithMargins 這幾個方法專門用於測量子元素。
如果是 View 的話，那麼在它的 layout 方法中就確定了自身的位置（具體來說是通過 setFrame 方法來設定 View 的四個頂點的位置，即初始化 mLeft ， mRight ， mTop ， mBottom 這四個值）， layout 過程就結束了。
如果是 ViewGroup 的話，那麼在它的 layout 方法中只是確定了 ViewGroup 自身的位置，要確定子元素的位置，就需要重寫 onLayout 方法；在 onLayout 方法中，會調用子元素的 layout 方法，子元素在它的 layout 方法中確定自己的位置，這樣一層一層地傳遞下去完成整個 View 樹的 layout 過程。
layout 方法的作用是確定 View 本身的位置，即設定 View 的四個頂點的位置，這樣就確定了 View 在父容器中的位置；
onLayout 方法的作用是父容器確定子元素的位置，這個方法在 View 中是空實現，因為 View 沒有子元素了，在 ViewGroup 中則進行抽象化，它的子類必須實現這個方法。
1.繪制背景（ background.draw(canvas); ）；
2.繪制自己（ onDraw ）；
3.繪制 children（ dispatchDraw(canvas) ）；
4.繪制裝飾（ onDrawScrollBars ）。
dispatchDraw 方法的調用是在 onDraw 方法之後，也就是說，總是先繪制自己再繪制子 View 。
對於 View 類來說， dispatchDraw 方法是空實現的，對於 ViewGroup 類來說， dispatchDraw 方法是有具體實現的。
通過 dispatchDraw 來傳遞的。 dispatchDraw 會遍歷調用子元素的 draw 方法，如此 draw 事件就一層一層傳遞了下去。dispatchDraw 在 View 類中是空實現的，在 ViewGroup 類中是真正實現的。
如果一個 View 不需要繪制任何內容，那麼就設置這個標記為 true，系統會進行進一步的優化。
當創建的自定義控制項繼承於 ViewGroup 並且不具備繪制功能時，就可以開啟這個標記，便於系統進行後續的優化；當明確知道一個 ViewGroup 需要通過 onDraw 繪制內容時，需要關閉這個標記。
參考：《Android開發藝術探索》
『玖』 android繪圖之Canvas基礎（2）
Canvas畫布，用於繪制出各種形狀配合畫布的變幻操作可以繪制出很多復雜圖形，基本的繪制圖形分類。
提供的繪制函數：
上面四個函數都可以繪制canvas的背景，注意到PorterDuff.Mode變數，它只對兩個canvas繪制bitmap起作用，所以此處暫時不討論mode參數（沒有設置mode默認使用srcover porterff mode）。
Rect 和RectF都是提供一個矩形局域。
(1)精度不一樣，Rect是使用int類型作為數值，RectF是使用float類型作為數值。
(2)兩個類型提供的方法也不是完全一致。
**
rect：RectF對象，一個矩形區域。
rx：x方向上的圓角半徑。
ry：y方向上的圓角半徑。
paint：繪制時所使用的畫筆。**
**
cx 圓心x
cy 圓心y
radius半徑**
需要一個Path,代表路徑後面會講解。
繪制線的集合，參數中pts是點的集合，兩個值代表一個點，四個值代表一條線，互相之間不連接。
offset跳過的點，count跳過之後要繪制的點的總數，可以用於集合中部分點的繪制。
跳過部分節點：
沒有跳過點
RectF oval:生成弧的矩形，中心為弧的圓心
float startAngle：弧開始的角度，以X軸正方向為0度，順時針
float sweepAngle：弧持續的角度
boolean useCenter:是否有弧的兩邊，True，還兩邊，False，只有一條弧
在矩形框內畫一個橢圓，如果是個正方形會畫出一個圓。
canvas.drawPoint();
canvas.drawPoints();
**
只需要提供兩個點一個坐標就可以繪制點。
canvas.drawPoint(20,20,mPaint);
float[] points = {30,40,40,50,60,60};
canvas.drawPoints(points,mPaint);**
這幾種方法類似：
canvas.drawText("好好學習，天天向上",100,100,mPaint);
drawTextOnPath
沿著一條 Path 來繪制文字
text 為所需要繪制的文字
path 為文字的路徑
hOffset 文字相對於路徑的水平偏移量，用於調整文字的位置
vOffset 文字相對於路徑豎直偏移量，用於調整文字的位置
值得注意的是，在繪制 Path 的時候，應該在拐彎處使用圓角，這樣文字顯示時更舒服
大致講解，後面會重點講解。
Rect src
Rect dst
其中src和dst這兩個矩形區域是用來做什麼的？
Rect src：指定繪制圖片的區域
Rect dst或RectF dst：指定圖片在屏幕上的繪制（顯示）區域
首先指定圖片區域，然後指定繪制圖片的區域。
android繪圖之Paint(1)
android繪圖之Canvas基礎（2）
Android繪圖之Path（3）
Android繪圖之drawText繪制文本相關（4）
Android繪圖之Canvas概念理解（5）
Android繪圖之Canvas變換（6）
Android繪圖之Canvas狀態保存和恢復（7）
Android繪圖之PathEffect （8）
Android繪圖之LinearGradient線性漸變（9）
Android繪圖之SweepGradient（10）
Android繪圖之RadialGradient 放射漸變（11）
Android繪制之BitmapShader（12）
Android繪圖之ComposeShader，PorterDuff.mode及Xfermode（13）
Android繪圖之drawText,getTextBounds,measureText,FontMetrics,基線（14）
Android繪圖之貝塞爾曲線簡介（15）
Android繪圖之PathMeasure（16）
Android 動態修改漸變 GradientDrawable