androidview繪制完成

❶ android怎麼繪制view的一部分

越少越好 為了加速視圖，從那些調用頻繁的活動中減少不必要的代碼。在OnDraw()方法中開始繪制，它會給你最大的 效益。特別低，你也應該減少在onDraw()方法中的內存分配，因為任何內存分配都可能導致內存回收，這將會 引起不連貫。 在初始化或者...

❷ android 怎麼知道自定義view圖畫完了

為什麼我們覺得自定義View是學習Android的一道坎？
為什麼那麼多Android大神卻認為自定義View又是如此的簡單？
為什麼google隨便定義一個View都是上千行的代碼？
以上這些問題，相信學Android的同學或多或少都有過這樣的疑問。
那麼，看完此文，希望對你們的疑惑有所幫助。

回到主題，自定義View ，需要掌握的幾個點是什麼呢？
我們先把自定義View細分一下，分為兩種
1） 自定義ViewGroup
2） 自定義View

其實ViewGroup最終還是繼承之View，當然它內部做了許多操作；繼承之ViewGroup的View我們一般稱之為容器，而今天我們不講這方面，後續有機會再講。
來看看自定義View 需要掌握的幾點，主要就是兩點

一、重寫 protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {}方法。
二、重寫 protected void onDraw(Canvas canvas) {}方法

空講理論很難理解，我們還得用例子來說明，記得我前面來寫了一篇 Android 微信6.1 tab欄圖標和字體顏色漸變的實現 的博客，裡面tab的每個item就是通過自定義View來實現的，那麼接下來就通過此例子來說明問題。

我們可以把View理解為一張白紙，而自定義View就是在這張白紙上畫上我們自己繪制的圖案，可以在繪制任何圖案，也可以在白紙的任何位置繪制，那麼問題來了，白紙哪裡來？圖案哪裡來？位置如何計算？

a）白紙好說，只要我們繼承之View，在onDraw(Canvas canvas)中的canvas就是我們所說的白紙
/**
* Created by moon.zhong on 2015/2/13.
*/
public class CustomView extends View {
public CustomView(Context context) {
super(context);
}

public CustomView(Context context, AttributeSet attrs) {
super(context, attrs);
}

public CustomView(Context context, AttributeSet attrs, int defStyleAttr) {
super(context, attrs, defStyleAttr);
}

@Override
protected void onDraw(Canvas canvas) {
// canvas 即為白紙
super.onDraw(canvas);
}
}

b）圖案呢？這里的圖案就是有圖片和文字組成，這個也好說，定義一個Bitmap 成員變數，和一個String的成員變數
private Bitmap mBitmap ;
private String mName ;
mName = "這里直接賦值";
mBitmap = BitmapFactory.decodeResource(getResources(),R.drawable.ic_launcher) ;1234

圖片可以通過資源文件可以拿到。

c）計算位置
所以最核心的也是我們認為最麻煩的地方就是計算繪制的位置，計算位置就得先測量自身的大小，也就是我們必須掌握的兩點中的第一點：需要重寫
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec)
{}方法
先來看一下google寫的TextView的onMeasure（）方法是如何實現的
@Override
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
int widthMode = MeasureSpec.getMode(widthMeasureSpec);
int heightMode = MeasureSpec.getMode(heightMeasureSpec);
int widthSize = MeasureSpec.getSize(widthMeasureSpec);
int heightSize = MeasureSpec.getSize(heightMeasureSpec);

int width;
int height;

BoringLayout.Metrics boring = UNKNOWN_BORING;
BoringLayout.Metrics hintBoring = UNKNOWN_BORING;

if (mTextDir == null) {
mTextDir = getTextDirectionHeuristic();
}

int des = -1;
boolean fromexisting = false;

if (widthMode == MeasureSpec.EXACTLY) {
// Parent has told us how big to be. So be it.
width = widthSize;
} else {
if (mLayout != null && mEllipsize == null) {
des = desired(mLayout);
}

if (des < 0) {
boring = BoringLayout.isBoring(mTransformed, mTextPaint, mTextDir, mBoring);
if (boring != null) {
mBoring = boring;
}
} else {
fromexisting = true;
}

if (boring == null || boring == UNKNOWN_BORING) {
if (des < 0) {
des = (int) FloatMath.ceil(Layout.getDesiredWidth(mTransformed, mTextPaint));
}
width = des;
} else {
width = boring.width;
}

final Drawables dr = mDrawables;
if (dr != null) {
width = Math.max(width, dr.mDrawableWidthTop);
width = Math.max(width, dr.mDrawableWidthBottom);
}

if (mHint != null) {
int hintDes = -1;
int hintWidth;

if (mHintLayout != null && mEllipsize == null) {
hintDes = desired(mHintLayout);
}

if (hintDes < 0) {
hintBoring = BoringLayout.isBoring(mHint, mTextPaint, mTextDir, mHintBoring);
if (hintBoring != null) {
mHintBoring = hintBoring;
}
}

if (hintBoring == null || hintBoring == UNKNOWN_BORING) {
if (hintDes < 0) {
hintDes = (int) FloatMath.ceil(Layout.getDesiredWidth(mHint, mTextPaint));
}
hintWidth = hintDes;
} else {
hintWidth = hintBoring.width;
}

if (hintWidth > width) {
width = hintWidth;
}
}

width += getCompoundPaddingLeft() + getCompoundPaddingRight();

if (mMaxWidthMode == EMS) {
width = Math.min(width, mMaxWidth * getLineHeight());
} else {
width = Math.min(width, mMaxWidth);
}

if (mMinWidthMode == EMS) {
width = Math.max(width, mMinWidth * getLineHeight());
} else {
width = Math.max(width, mMinWidth);
}

// Check against our minimum width
width = Math.max(width, getSuggestedMinimumWidth());

if (widthMode == MeasureSpec.AT_MOST) {
width = Math.min(widthSize, width);
}
}

int want = width - getCompoundPaddingLeft() - getCompoundPaddingRight();
int unpaddedWidth = want;

if (mHorizontallyScrolling) want = VERY_WIDE;

int hintWant = want;
int hintWidth = (mHintLayout == null) ? hintWant : mHintLayout.getWidth();

if (mLayout == null) {
makeNewLayout(want, hintWant, boring, hintBoring,
width - getCompoundPaddingLeft() - getCompoundPaddingRight(), false);
} else {
final boolean layoutChanged = (mLayout.getWidth() != want) ||
(hintWidth != hintWant) ||
(mLayout.getEllipsizedWidth() !=
width - getCompoundPaddingLeft() - getCompoundPaddingRight());

final boolean widthChanged = (mHint == null) &&
(mEllipsize == null) &&
(want > mLayout.getWidth()) &&
(mLayout instanceof BoringLayout || (fromexisting && des >= 0 && des <= want));

final boolean maximumChanged = (mMaxMode != mOldMaxMode) || (mMaximum != mOldMaximum);

if (layoutChanged || maximumChanged) {
if (!maximumChanged && widthChanged) {
mLayout.increaseWidthTo(want);
} else {
makeNewLayout(want, hintWant, boring, hintBoring,
width - getCompoundPaddingLeft() - getCompoundPaddingRight(), false);
}
} else {
// Nothing has changed
}
}

if (heightMode == MeasureSpec.EXACTLY) {
// Parent has told us how big to be. So be it.
height = heightSize;
mDesiredHeightAtMeasure = -1;
} else {
int desired = getDesiredHeight();

height = desired;
mDesiredHeightAtMeasure = desired;

if (heightMode == MeasureSpec.AT_MOST) {
height = Math.min(desired, heightSize);
}
}

int unpaddedHeight = height - getCompoundPaddingTop() - getCompoundPaddingBottom();
if (mMaxMode == LINES && mLayout.getLineCount() > mMaximum) {
unpaddedHeight = Math.min(unpaddedHeight, mLayout.getLineTop(mMaximum));
}

/*
* We didn't let makeNewLayout() register to bring the cursor into view,
* so do it here if there is any possibility that it is needed.
*/
if (mMovement != null ||
mLayout.getWidth() > unpaddedWidth ||
mLayout.getHeight() > unpaddedHeight) {
registerForPreDraw();
} else {
scrollTo(0, 0);
}

setMeasuredDimension(width, height);
}

哇！好長！而且方法中還嵌套方法，如果真要算下來，代碼量不會低於500行，看到這么多代碼，頭都大了，我想這也是我們為什麼在學習Android自定義View的時候覺得如此困難的原因。大多數情況下，因為我們是自定義的View，可以說是根據我們的需求定製的View，所以很多裡面的功能我們完全沒必要，只需要幾十行代碼就能搞定。看到幾十行代碼就能搞定，感覺頓時信心倍增(^.^)
在重寫這個方法之前，得先了解一個類 MeasureSpec ，如果不了解，沒關系，下面就一起來了解一下這個類。先把代碼貼出來，膜拜一下
1234
public static class MeasureSpec {
private static final int MODE_SHIFT = 30;
private static final int MODE_MASK = 0x3 << MODE_SHIFT;
public static final int UNSPECIFIED = 0 << MODE_SHIFT;
public static final int EXACTLY = 1 << MODE_SHIFT;
public static final int AT_MOST = 2 << MODE_SHIFT;
public static int makeMeasureSpec(int size, int mode) {
if (sUseBrokenMakeMeasureSpec) {
return size + mode;
} else {
return (size & ~MODE_MASK) | (mode & MODE_MASK);
}
}
public static int getMode(int measureSpec) {
return (measureSpec & MODE_MASK);
}
public static int getSize(int measureSpec) {
return (measureSpec & ~MODE_MASK);
}
}

這里我把裡面一些我認為沒必要的代碼都去掉了，只留了以上幾行代碼，這樣看起來很清晰，也非常容易理解。
我們先做個轉化，把上面幾個成員變數轉化成二進制

這個就不需要轉化了，這里代表的只是一個移動的位置，也就是一個單純的數字
private static final int MODE_SHIFT = 30;
0x3 就是 11 左移30位 ，就是補30個0；
private static final int MODE_MASK = 1100 0000 0000 0000 0000 0000 0000 0000 ;
00 左移30位
public static final int UNSPECIFIED = 0000 0000 0000 0000 0000 0000 0000 0000 ;
01 左移30位
public static final int EXACTLY = 0100 0000 0000 0000 0000 0000 0000 0000 ;
10 左移30位
public static final int AT_MOST = 1000 0000 0000 0000 0000 0000 0000 0000 ;

你就會問了，這樣寫有什麼好處呢？ 細心的人看了上面這幾個方法就明白了，每個方法中都有一個 & 的操作，所以我們接下來看看這集幾個方法的含義是什麼，先從下往上看，先易後難
1、 public static int getSize(int measureSpec) {
return (measureSpec & ~MODE_MASK);
}
顧名思義，通過measureSpec這個參數，獲取size ，兩個都是int類型，怎麼通過一個int類型的數獲取另一個int類型的數。我們在學習java的時候知道，一個int類型是32位，任何int類型的數都是有32位，比如一個int類型的數值3，它也是佔有32位，只是高30位全部為0。google 也是利用這一點，讓這個int類型的measureSpec數存了兩個信息，一個就是size，保存在int類型的低30位，另一個就是mode，保存在int類型的高2位。前面我們看到了有幾個成員變數，UNSPECIFIED，EXACTLY，AT_MOST
者就是mode的三種選擇，目前也只有這三種選擇，所以只需要2位就能實現。
2、 ` public static int getMode(int measureSpec) {
return (measureSpec & MODE_MASK);
}`
這也好理解，獲取模式，但這些模式有啥用處呢？
1）、EXACTLY 模式： 准確的、精確的；這種模式，是最容易理解和處理的，可以理解為大小固定，比如在定義layout_width的時候，定義為固定大小 10dp，20dp，或者match_parent(此時父控制項是固定的)這時候，獲取出來的mode就是EXACTLY
2）、AT_MOST 模式： 最大的；這種模式稍微難處理些，不過也好理解，就是View的大小最大不能超過父控制項，超過了，取父控制項的大小，沒有，則取自身大小，這種情況一般都是在layout_width設為warp_content時。
3）、UNSPECIFIED 模式：不指定大小，這種情況，我們幾乎用不上，它是什麼意思呢，就是View的大小想要多大，就給多大，不受父View的限制，幾個例子就好理解了，ScrollView控制項就是。

❸ 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 View雙緩沖機制

繪制圖像時不用上述中逐個繪制的方案，先在內存中將所有的圖像都繪制到一個Bitmap對象上，然後一次性將內存中的Bitmap繪制到屏幕，從而提高繪制的效率。View的onDraw()方法已經實現了這一層緩沖。

onDraw()方法的Canvas對象是和屏幕關聯的，而onDraw()方法是運行在UI線程中的，如果要繪制的圖像過於復雜，則有可能導致應用程序卡頓，甚至ANR。

因此我們可以先創建一個臨時的Canvas對象，將圖像都繪制到這個臨時的Canvas對象中，繪制完成之後再將這個臨時Canvas對象中的內容(也就是一個Bitmap)，通過drawBitmap()方法繪制到onDraw()方法中的canvas對象中。這樣的話就相當於是一個Bitmap的拷貝過程，比直接繪制效率要高，可以減少對UI線程的阻塞。

創建臨時bitmap，進行相關繪制：

❺ Android 如何判斷一個View重繪或載入完成

1、view重繪時回調（即監聽函數，當view重繪完成自動動用，需要向view的觀察者添加監聽器）。格式：

view.getViewTreeObserver().addOnDrawListener(new OnDrawListener() {

@Override

public void onDraw() {

// TODO Auto-generated method stub

}

});

2、view載入完成時回調（當view載入完成自動動用，需要向view的觀察者添加監聽器）。格式：

view.getViewTreeObserver().addOnGlobalLayoutListener(new OnGlobalLayoutListener() {

@Override

public void onGlobalLayout() {

// TODO Auto-generated method stub

}

});

(5)androidview繪制完成擴展閱讀：

兩種方式刷新：

1、主線程可以直接調用Invalidate()方法刷新

2、子線程可以直接調用postInvalidate()方法刷新。

API的描述 : Invalidatethe whole view. If the view is visible, onDraw(Canvas) will be called at somepoint in the future. This must be called from a UI thread. To call from anon-UI thread, call postInvalidate().。

API的描述譯文：當Invalidate()被調用的時候，View的OnDraw()就會被調用，Invalidate()必須是在UI線程中被調用，如果在新線程中更新視圖的就調用postInvalidate()。

❻ Android - View 繪制流程

我們知道，在 Android 中，View 繪制主要包含 3 大流程：

Android 中，主要有兩種視圖： View 和 ViewGroup ，其中：

雖然 ViewGroup 繼承於 View ，但是在 View 繪制三大流程中，某些流程需要區分 View 和 ViewGroup ，它們之間的操作並不完全相同，比如：

對 View 進行測量，主要包含兩個步驟：

對於第一個步驟，即求取 View 的 MeasureSpec ，首先我們來看下 MeasureSpec 的源碼定義：

MeasureSpec 是 View 的一個公有靜態內部類，它是一個 32 位的 int 值，高 2 位表示 SpecMode（測量模式），低 30 位表示 SpecSize（測量尺寸/測量大小）。
MeasureSpec 將兩個數據打包到一個 int 值上，可以減少對象內存分配，並且其提供了相應的工具方法可以很方便地讓我們從一個 int 值中抽取出 View 的 SpecMode 和 SpecSize。

一個 MeasureSpec 表達的是：該 View 在該種測量模式（SpecMode）下對應的測量尺寸（SpecSize）。其中，SpecMode 有三種類型：

對 View 進行測量，最關鍵的一步就是計算得到 View 的 MeasureSpec ，子View 在創建時，可以指定不同的 LayoutParams （布局參數）， LayoutParams 的源碼主要內容如下所示：

其中：

LayoutParams 會受到父容器的 MeasureSpec 的影響，測量過程會依據兩者之間的相互約束最終生成子View 的 MeasureSpec ，完成 View 的測量規格。

簡而言之，View 的 MeasureSpec 受自身的 LayoutParams 和父容器的 MeasureSpec 共同決定（ DecorView 的 MeasureSpec 是由自身的 LayoutParams 和屏幕尺寸共同決定，參考後文）。也因此，如果要求取子View 的 MeasureSpec ，那麼首先就需要知道父容器的 MeasureSpec ，層層逆推而上，即最終就是需要知道頂層View（即 DecorView ）的 MeasureSpec ，這樣才能一層層傳遞下來，這整個過程需要結合 Activity 的啟動過程進行分析。

我們知道，在 Android 中， Activity 是作為視圖組件存在，主要就是在手機上顯示視圖界面，可以供用戶操作， Activity 就是 Andorid 中與用戶直接交互最多的系統組件。

Activity 的基本視圖層次結構如下所示：

Activity 中，實際承載視圖的組件是 Window （更具體來說為 PhoneWindow ），頂層View 是 DecorView ，它是一個 FrameLayout ， DecorView 內部是一個 LinearLayout ，該 LinearLayout 由兩部分組成（不同 Android 版本或主題稍有差異）： TitleView 和 ContentView ，其中， TitleView 就是標題欄，也就是我們常說的 TitleBar 或 ActionBar ， ContentView 就是內容欄，它也是一個 FrameLayout ，主要用於承載我們的自定義根布局，即當我們調用 setContentView(...) 時，其實就是把我們自定義的布局設置到該 ContentView 中。

當 Activity 啟動完成後，最終就會渲染出上述層次結構的視圖。

因此，如果我們要求取得到子View 的 MeasureSpec ，那麼第一步就是求取得到頂層View（即 DecorView ）的 MeasureSpec 。大致過程如下所示：

經過上述步驟求取得到 View 的 MeasureSpec 後，接下來就可以真正對 View 進行測量，求取 View 的最終測量寬/高：

Android 內部對視圖進行測量的過程是由 View#measure(int, int) 方法負責的，但是對於 View 和 ViewGroup ，其具體測量過程有所差異。

因此，對於測量過程，我們分別對 View 和 ViewGroup 進行分析：

綜上，無論是對 View 的測量還是 ViewGroup 的測量，都是由 View#measure(int widthMeasureSpec, int heightMeasureSpec) 方法負責，然後真正執行 View 測量的是 View 的 onMeasure(int widthMeasureSpec, int heightMeasureSpec) 方法。

具體來說， View 直接在 onMeasure(...) 中測量並設置自己的最終測量寬/高。在默認測量情況下， View 的測量寬/高由其父容器的 MeasureSpec 和自身的 LayoutParams 共同決定，當 View 自身的測量模式為 LayoutParams.UNSPECIFIED 時，其測量寬/高為 android:minWidth / android:minHeight 和其背景寬/高之間的較大值，其餘情況皆為自身 MeasureSpec 指定的測量尺寸。

而對於 ViewGroup 來說，由於布局特性的豐富性，只能自己手動覆寫 onMeasure(...) 方法，實現自定義測量過程，但是總的思想都是先測量 子View 大小，最終才能確定自己的測量大小。

當確定了 View 的測量大小後，接下來就可以來確定 View 的布局位置了，也即將 View 放置到屏幕具體哪個位置。

View 的布局過程由 View#layout(...) 負責，其源碼如下：

View#layout(...) 主要就做了兩件事：

ViewGroup 的布局流程由 ViewGroup#layout(...) 負責，其源碼如下：

可以看到， ViewGroup#layout(...) 最終也是通過 View#layout(...) 完成自身的布局過程，一個注意的點是， ViewGroup#layout(...) 是一個 final 方法，因此子類無法覆寫該方法，主要是 ViewGroup#layout(...) 方法內部對子視圖動畫效果進行了相關設置。

由於 ViewGroup#layout(...) 內部最終調用的還是 View#layout(...) ，因此， ViewGroup#onLayout(...) 就會得到回調，用於處理 子View 的布局放置，其源碼如下：

由於不同的 ViewGroup ，其布局特性不同，因此 ViewGroup#onLayout(...) 是一個抽象方法，交由 ViewGroup 子類依據自己的布局特性，擺放其 子View 的位置。

當 View 的測量大小，布局位置都確定後，就可以最終將該 View 繪制到屏幕上了。

View 的繪制過程由 View#draw(...) 方法負責，其源碼如下：

其實注釋已經寫的很清楚了， View#draw(...) 主要做了以下 6 件事：

我們知道，在 Activity 啟動過程中，會調用到 ActivityThread.handleResumeActivity(...) ，該方法就是 View 視圖繪制的起始之處：

可以看到， ActivityThread.handleResumeActivity(...) 主要就是獲取到當前 Activity 綁定的 ViewManager ，最後調用 ViewManager.addView(...) 方法將 DecorView 設置到 PhoneWindow 上，也即設置到當前 Activity 上。 ViewManager 是一個介面， WindowManager 繼承 ViewManager ，而 WindowManagerImpl 實現了介面 WindowManager ，此處的 ViewManager.addView(...) 實際上調用的是 WindowManagerImpl.addView(...) ，源碼如下所示：

WindowManagerImpl.addView(...) 內部轉發到 WindowManagerGlobal.addView(...) ：

在 WindowManagerGlobal.addView(...) 內部，會創建一個 ViewRootImpl 實例，然後調用 ViewRootImpl.setView(...) 將 ViewRootImpl 與 DecorView 關聯到一起：

ViewRootImpl.setView(...) 內部首先關聯了傳遞過來的 DecorView （通過屬性 mView 指向 DecorView 即可建立關聯），然後最終調用 requestLayout() ，而 requestLayout() 內部又會調用方法 scheleTraversals() ：

ViewRootImpl.scheleTraversals() 內部主要做了兩件事：

Choreographer.postCallback(...) 會申請一次 VSYNC 中斷信號，當 VSYNC 信號到達時，便會回調 Choreographer.doFrame(...) 方法，內部會觸發已經添加的回調任務， Choreographer 的回調任務有以下四種類型：

因此， ViewRootImpl.scheleTraversals(...) 內部通過 mChoreographer.postCallback(Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null) 發送的非同步視圖渲染消息就會得到回調，即回調 mTra

❼ 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 view的繪制中,View繪制的時間如何和vsync屏幕刷新頻率...

兩者並不同步。硬體Vsync被轉化為兩個不同delay的軟體信號，分別供給Choreographer和SurfaceFlinger(並且前者的延時可能是負值)，用以在兩者之間製造出充分的時間窗。當硬體產生Vsync後，經過Delay1，開始所有當前窗口的繪制；經過Delay2,SurfaceFlinger服務開始合並所有窗口(Layer)的最新內容,將結果提交給fb來刷新顯示。所以如果某應用未能在時間窗內及時完成顯示工作(queueBuffer),它只能等到SurfaceFlinger的下一輪合並了。以上流程依賴具體平台實現，僅供參考。

❾ android怎麼判斷view有沒有繪制結束

可以設置這個回調函數

//view重繪時回調
view.getViewTreeObserver().addOnDrawListener(new OnDrawListener() {
@Override
public void onDraw() {
// TODO Auto-generated method stub

}
});

//view載入完成時回調
view.getViewTreeObserver().addOnGlobalLayoutListener(new OnGlobalLayoutListener() {
@Override
public void onGlobalLayout() {
// TODO Auto-generated method stub

}
});

❿ android怎麼動態調用View.ondraw實現動態繪制自定義View

在自定義的時候，復寫該方法，在代碼中繪制控制項時，會自動調用該方法，在修改了控制項，需要重新繪制時，則使用View的invalidate()即可實現重繪！！！