一　概述

上篇分析了自定義 View 繪制流程及其常用方法：Android View繪制4　Draw過程（上），
本篇將從代碼的角度深入分析硬件加速繪制與軟件繪制。
通過本篇文章，你將了解到：

1、軟件繪制流程
2、硬件加速繪制流程
2、LayerType 對繪制的影響
3、Canvas 從哪里來到哪里去
4、繪制流程全家福

二　軟件繪制流程

上篇說過在ViewRootImpl->draw(xx)里軟件繪制與硬件加速繪制分道揚鑣：

上圖是Window 區分硬件加速繪制與軟件繪制的入口。
由易到難，先來看看軟件繪制流程。

drawSoftware(xx)

#ViewRootImpl.javaprivate boolean drawSoftware(Surface surface, AttachInfo attachInfo, int xoff, int yoff,boolean scalingRequired, Rect dirty, Rect surfaceInsets) {//持有的畫布final Canvas canvas;...try {...//申請畫布對象，該畫布初始大小為dirty的尺寸canvas = mSurface.lockCanvas(dirty);//設置密度canvas.setDensity(mDensity);} catch (Surface.OutOfResourcesException e) {...} catch (IllegalArgumentException e) {...return false;} finally {...}try {//畫布是否需要移動canvas.translate(-xoff, -yoff);//mView 即是添加到該Window的RootView//對于Activity、Dialog開啟的Window，mView就是我們熟知的DecorView//rootView draw()方法mView.draw(canvas);} finally {try {//提交繪制的內容到Surfacesurface.unlockCanvasAndPost(canvas);} catch (IllegalArgumentException e) {...}}return true;}

以上方法功能重點如下：

1、從Surface 申請Canvas對象，該Canvas為CompatibleCanvas 類型
2、拿到Canvas后，調用View.draw(Canvas)開始繪制RootView
3、整個ViewTree 繪制完成后將內容提交到Surface

注：RootView 只是個代稱，并不是某個View的名字。
一些常見的RootView 請移步：Android 輸入事件一擼到底之源頭活水（1）

關于View.draw(xx)方法在：Android 自定義View之Draw過程(上) 已做過詳細分析，結合上述代碼，用如下圖表示：

可以看得出來，軟件繪制有如下特點：

從RootView 遞歸調用子布局的draw(xx)方法，直到每個符合條件的View都進行了繪制
繪制過程中，所有的View持有相同的Canvas對象
引入問題1：既然所有的View都持有相同的Canvas，那么每個View繪制的起點、終點是如何確定的呢？
該問題稍后分析。

硬件加速繪制流程
概要
軟件繪制是將Canvas的一系列操作寫入到Bitmap里，而對于硬件加速繪制來說，每個View 都有一個RenderNode，當需要繪制的時候，從RenderNode里獲取一個RecordingCanvas，與軟件繪制一樣，也是調用Canvas一系列的API，只不過調用的這些API記錄為一系列的操作行為存放在DisplayList。當一個View錄制結束，再將DisplayList交給RenderNode。此時，繪制的步驟已經記錄在RenderNode里，到此，針對單個View的硬件繪制完成，這個過程也稱作為DisplayList的構建過程。

調用過程分析
來看看硬件加速的入口：

#ThreadedRenderer.javavoid draw(View view, AttachInfo attachInfo, DrawCallbacks callbacks) {...//(1)--->錄制操作//更新根View的DisplayList//從此處開始將繪制操作記錄到DisplayList里//最終記錄在rootRenderNode里updateRootDisplayList(view, callbacks);//(2)--->渲染//渲染繪制的內容//以proxy為橋梁，而proxy又與rootRenderNode關聯//因此最終將上一步記錄的繪制操作交給單獨的線程渲染int syncResult = syncAndDrawFrame(choreographer.mFrameInfo);...}

重點關注錄制操作過程，接著來分析它：

#ThreadedRenderer.javaprivate void updateRootDisplayList(View view, DrawCallbacks callbacks) {//遍歷ViewTree，構建DisplayListupdateViewTreeDisplayList(view);//當ViewTree DisplayList構建完畢后//一開始mRootNode 是沒有DisplayListif (mRootNodeNeedsUpdate || !mRootNode.hasDisplayList()) {//申請CanvasRecordingCanvas canvas = mRootNode.beginRecording(mSurfaceWidth, mSurfaceHeight);try {...//view.updateDisplayListIfDirty() 返回的是RootView 關聯的renderNode//現在將RootView renderNode掛到canvas下，這樣子就串聯起所有的renderNode了canvas.drawRenderNode(view.updateDisplayListIfDirty());...mRootNodeNeedsUpdate = false;} finally {//最后將DisplayList 掛到renderNode下mRootNode.endRecording();}}}private void updateViewTreeDisplayList(View view) {//標記該View已繪制過view.mPrivateFlags |= View.PFLAG_DRAWN;//mRecreateDisplayList --> 表示該View 是否需要重建DisplayList，也就是重新錄制，更直白地說是否需要走Draw 過程//若是打上了 PFLAG_INVALIDATED 標記，也就是該View需要刷新，則需要重建view.mRecreateDisplayList = (view.mPrivateFlags & View.PFLAG_INVALIDATED)== View.PFLAG_INVALIDATED;//清空原來的值view.mPrivateFlags &= ~View.PFLAG_INVALIDATED;//如果有需要，更新View的DisplayListview.updateDisplayListIfDirty();//View 已經重建完畢，無需再重建view.mRecreateDisplayList = false;}

以上調用了到了View里的方法：updateDisplayListIfDirty()。
顧名思義，如果有需要更新View的DisplayList。

#View.javapublic RenderNode updateDisplayListIfDirty() {//每個View構造的時候都會創建一個RenderNode:mRenderNode，稱之為渲染節點final RenderNode renderNode = mRenderNode;//是否支持硬件加速，通過判斷View.AttachInfo.mThreadedRendererif (!canHaveDisplayList()) {return renderNode;}//取出該View的標記//1、繪制緩存失效 2、渲染節點還沒有DisplayList 3、渲染節點有DisplayList，但是需要更新//三者滿足其中一個條件，則進入條件代碼塊if ((mPrivateFlags & PFLAG_DRAWING_CACHE_VALID) == 0|| !renderNode.hasDisplayList()|| (mRecreateDisplayList)) {//如果有DisplayList且該DisplayList無需更新，則說明該View不需要重新走Draw過程if (renderNode.hasDisplayList()&& !mRecreateDisplayList) {//標記該View已經繪制完成且緩存是有效的mPrivateFlags |= PFLAG_DRAWN | PFLAG_DRAWING_CACHE_VALID;mPrivateFlags &= ~PFLAG_DIRTY_MASK;//繼續查看子布局是否需要構建DisplayListdispatchGetDisplayList(); //---------(1)return renderNode; // no work needed}//上述條件不滿足，則說明該View需要構建DisplayListmRecreateDisplayList = true;//layout 過程確定的View的坐標此時用到了int width = mRight - mLeft;int height = mBottom - mTop;//獲取當前設置的layerTypeint layerType = getLayerType();//從renderNode里獲取Canvas對象，Canvas的尺寸初始化為View的尺寸//該Canvas是RecordingCanvas類型，簡單理解為用來錄制的Canvasfinal RecordingCanvas canvas = renderNode.beginRecording(width, height);try {//layerType 有三種取值//如果是軟件繪制緩存if (layerType == LAYER_TYPE_SOFTWARE) {//---------(2)//則構建緩存buildDrawingCache(true);//實際上就是將繪制操作寫入Bitmap里Bitmap cache = getDrawingCache(true);if (cache != null) {//將該Bitmap繪制到Canvas里canvas.drawBitmap(cache, 0, 0, mLayerPaint);}} else {//如果沒有設置軟件繪制緩存//一般配合Scroller 滑動使用computeScroll();//mScrollX、mScrollY 為滾動的距離//當mScrollX 為正值時，canvas向左移動，繪制的內容往左移動，這也就是為什么明明scroll為正值，為啥View內容往左移的根本原因canvas.translate(-mScrollX, -mScrollY);mPrivateFlags |= PFLAG_DRAWN | PFLAG_DRAWING_CACHE_VALID;mPrivateFlags &= ~PFLAG_DIRTY_MASK;//---------(3)if ((mPrivateFlags & PFLAG_SKIP_DRAW) == PFLAG_SKIP_DRAW) {//該View不需要繪制自身內容（包括內容、前景、背景等)//直接發起繪制子布局的請求dispatchDraw(canvas);drawAutofilledHighlight(canvas);if (mOverlay != null && !mOverlay.isEmpty()) {mOverlay.getOverlayView().draw(canvas);}if (debugDraw()) {debugDrawFocus(canvas);}} else {//需要繪制自身draw(canvas);}}} finally {//最后結束canvas錄制，并將錄制產生的結果：DisplayList交給renderNode//---------(4)renderNode.endRecording();setDisplayListProperties(renderNode);}} else {//三個條件不滿足，認為已經繪制完成mPrivateFlags |= PFLAG_DRAWN | PFLAG_DRAWING_CACHE_VALID;mPrivateFlags &= ~PFLAG_DIRTY_MASK;}//返回renderNode 到上一層//---------(5)return renderNode;}

注釋里列出了5個比較重要的點，來一一解析：
(1)
dispatchGetDisplayList()
該方法在View里沒有實現，在ViewGroup實現如下：

#ViewGroup.javaprotected void dispatchGetDisplayList() {final int count = mChildrenCount;final View[] children = mChildren;for (int i = 0; i < count; i++) {//遍歷子布局final View child = children[i];if (((child.mViewFlags & VISIBILITY_MASK) == VISIBLE || child.getAnimation() != null)) {//重建子布局DisplayListrecreateChildDisplayList(child);}}...}private void recreateChildDisplayList(View child) {//判斷是否需要重建child.mRecreateDisplayList = (child.mPrivateFlags & PFLAG_INVALIDATED) != 0;child.mPrivateFlags &= ~PFLAG_INVALIDATED;//調用子布局重建方法child.updateDisplayListIfDirty();child.mRecreateDisplayList = false;}

可以看出，dispatchGetDisplayList 作用：

遍歷子布局，并調用它們的重建方法

這樣子，從RootView開始遞歸調用updateDisplayListIfDirty()，如果子布局需要重建DisplayList，則重新錄制繪制操作，否則繼續查找子布局是否需要重建DisplayList。

(2)
buildDrawingCache(xx) 用來繪制離屏緩存，后續再細說。

(3)
跳過繪制這段可參考：Android ViewGroup onDraw為什么沒調用

(4)
硬件加速繪制有開始、錄制、結束的標記：

1、renderNode生成用來繪制的Canvas–> beginRecording，此為開始。
2、調用Canvas.drawXX()–> 錄制具體的東西，此為錄制過程
3、renderNode結束繪制–> endRecording()，從Canvas里拿到錄制的結果：DisplayList，并將該結果賦值給renderNode，此為錄制結束

(5)
從第4點可以看出，錄制的結果已經存放到RenderNode里，需要將RenderNode返回，該RenderNode將會被掛到父布局的Canvas里，也就是說父布局Canvas已經持有了子布局錄制好的DisplayList。

簡單一些，用圖表示單個View的硬件加速繪制流程：

ViewTree 硬件加速過程：

很明顯，硬件加速繪制過程就是構建DisplayList過程，從RootView遞歸子布局構建DisplayList，當整個DisplayList構建完畢，就可以進行渲染了，渲染線程交給GPU處理，這樣子大大解放了CPU工作。

LayerType 對繪制的影響
以上分別闡述了軟件繪制與硬件加速繪制的流程，分析的起點是該Window是否支持硬件加速而走不同的分支。
從RootView開始到遍歷所有的子孫View，要么都是軟件繪制，要么都是硬件加速繪制，如果在硬件加速繪制的中途禁用了某個View的硬件加速會如何表現呢？我們之前提到過通過設置View->LayerType來禁用硬件加速，接下來分析LayerType對繪制流程的影響。
從 Android 自定義View之Draw過程(上)
分析可知：不管軟件繪制或者硬件加速繪制，都會走一套公共的流程：

draw(xx)->dispatchDraw(xx)->draw(x1,x2,x3)->draw(xx)...

這也是遞歸調用的過程。
對于單個View，軟件繪制與硬件加速分歧點在哪呢？
答案是：draw(x1,x2,x3)方法

View的軟硬繪制分歧點

#View.javaboolean draw(Canvas canvas, ViewGroup parent, long drawingTime) {//canvas是否支持硬件加速//默認canvas是不支持硬件加速的//RecordingCanvas支持硬件加速final boolean hardwareAcceleratedCanvas = canvas.isHardwareAccelerated();//是否使用RenderNode繪制，也就是該View是否支持硬件加速//該View支持硬件加速的條件是：canvas支持硬件加速+該Window支持硬件加速boolean drawingWithRenderNode = mAttachInfo != null&& mAttachInfo.mHardwareAccelerated&& hardwareAcceleratedCanvas;//動畫相關...if (hardwareAcceleratedCanvas) {//canvas支持硬件加速，需要檢測是否需要重建DisplayListmRecreateDisplayList = (mPrivateFlags & PFLAG_INVALIDATED) != 0;mPrivateFlags &= ~PFLAG_INVALIDATED;}RenderNode renderNode = null;Bitmap cache = null;//獲取LayerType，View 默認類型是Noneint layerType = getLayerType();//------>(1)if (layerType == LAYER_TYPE_SOFTWARE || !drawingWithRenderNode) {//1、設置了離屏軟件繪制緩存 2、View不支持硬件加速繪制//兩者滿足其一if (layerType != LAYER_TYPE_NONE) {//可能設置了軟件緩存或者硬件緩存//此時硬件緩存當做軟件緩存來使用layerType = LAYER_TYPE_SOFTWARE;//繪制到軟件緩存//------>(2)buildDrawingCache(true);}//取出軟件緩存cache = getDrawingCache(true);}if (drawingWithRenderNode) { //----->(3)//該View支持硬件加速//則嘗試構建DisplayList，并返回renderNoderenderNode = updateDisplayListIfDirty();if (!renderNode.hasDisplayList()) {//一般很少走這renderNode = null;drawingWithRenderNode = false;}}int sx = 0;int sy = 0;if (!drawingWithRenderNode) {computeScroll();//不使用硬件加速時將內容偏移記錄sx = mScrollX;sy = mScrollY;}//注意這兩個標記，下面會用到//1、存在軟件緩存 2、不支持硬件加速 兩者同時成立，則說明：使用軟件緩存繪制final boolean drawingWithDrawingCache = cache != null && !drawingWithRenderNode;//1、不存在軟件緩存 2、不支持硬件加速，兩者同時成立，則說明：使用軟件繪制final boolean offsetForScroll = cache == null && !drawingWithRenderNode;if (offsetForScroll) {//------>(4)//如果是軟件繪制，需要根據View的偏移與內容偏移移動canvas//此時包括內容滾動偏移量canvas.translate(mLeft - sx, mTop - sy);} else {if (!drawingWithRenderNode) {//------>(5)//如果不支持硬件加速，則說明可能是軟件緩存繪制//此時也需要位移canvas，只不過不需要考慮內容滾動偏移量canvas.translate(mLeft, mTop);}...}...if (!drawingWithRenderNode) {//不支持硬件加速if ((parentFlags & ViewGroup.FLAG_CLIP_CHILDREN) != 0 && cache == null) {//裁減canvas，限制canvas展示區域，這就是子布局展示為什么不能超過父布局區域的原因if (offsetForScroll) {//是軟件繪制，則裁減掉滾動的距離//------>(6)canvas.clipRect(sx, sy, sx + getWidth(), sy + getHeight());} else {//否則無需考慮滾動距離if (!scalingRequired || cache == null) {canvas.clipRect(0, 0, getWidth(), getHeight());} else {canvas.clipRect(0, 0, cache.getWidth(), cache.getHeight());}}}...}if (!drawingWithDrawingCache) {//不使用軟件緩存繪制if (drawingWithRenderNode) {//支持硬件加速mPrivateFlags &= ~PFLAG_DIRTY_MASK;//將該View的renderNode掛到父布局的Canvas下，此處建立了連接((RecordingCanvas) canvas).drawRenderNode(renderNode);} else {//軟件繪制，發起了繪制請求：dispatchDraw(canvas) & draw(canvas);//------>(7)if ((mPrivateFlags & PFLAG_SKIP_DRAW) == PFLAG_SKIP_DRAW) {mPrivateFlags &= ~PFLAG_DIRTY_MASK;dispatchDraw(canvas);} else {draw(canvas);}}} else if (cache != null) {//軟件繪制緩存存在mPrivateFlags &= ~PFLAG_DIRTY_MASK;if (layerType == LAYER_TYPE_NONE || mLayerPaint == null) {...//沒有設置緩存類型，則將軟件繪制緩存寫入到canvas的bitmap里canvas.drawBitmap(cache, 0.0f, 0.0f, cachePaint);} else {...canvas.drawBitmap(cache, 0.0f, 0.0f, mLayerPaint);}}...//該View 構建完畢mRecreateDisplayList = false;return more;}

該方法里面的判斷比較亂，提取了比較重要的7個點：
(1)
只要設置了離屏軟件緩存或者不支持硬件加速，那么就需要使用軟件緩存繪制。

(3)
只要支持硬件加速，則使用硬件加速繪制。結合(1)，是不是覺得有點矛盾呢？想想滿足(1)條件的情況之一：設置了離屏軟件緩存，也支持硬件加速，按照(1)的邏輯，那么此時啟用了軟件緩存繪制。那么(3)繼續用硬件加速繪制不是多此一舉嗎？
回顧一下updateDisplayListIfDirty()里的片段：

if (layerType == LAYER_TYPE_SOFTWARE) {...//軟件緩存繪制buildDrawingCache(true);} else {//硬件繪制...}

這里邊再次進行了判斷。

(4)(5)
Canvas位移
對于軟件繪制，將Canvas進行位移，位移距離考慮了View本身偏移以及View內容偏移。
對于軟件緩存繪制，將Canvas進行位移，僅僅考慮了View本身偏移。
對于硬件加速繪制，沒看到對Canvas進行位移。
實際上針對軟件緩存繪制與硬件加速繪制，Canvas位移既包括View本身偏移也包含了View內容偏移。只是不在上述的代碼里。
對于軟件緩存繪制：

在buildDrawingCacheImpl(xx) -> canvas.translate(-mScrollX, -mScrollY);進行了內容偏移。

而對于硬件加速繪制：

在layout(xx)->mRenderNode.setLeftTopRightBottom(mLeft, mTop, mRight, mBottom) 進行了View本身的偏移。
在updateDisplayListIfDirty(xx)->canvas.translate(-mScrollX, -mScrollY);進行了內容偏移。

因此，不論軟件繪制/軟件緩存繪制/硬件加速繪制，三者都對Canvas進行了位移，位移包括：View本身的偏移以及內容的偏移。

以上也解釋了問題1。

(6)
Canvas裁減
對于軟件繪制，Canvas裁減包括了View內容偏移。
對于軟件緩存繪制，Canvas 繪制到Bitmap里。
對于硬件加速繪制，在setDisplayListProperties(xx)->renderNode.setClipToBounds(xx) 進行裁減。
(7)
如果是軟件繪制，那么直接調用dispatchDraw(xx)/draw(xx)發起繪制。

draw(x1,x2,x3)方法作用：決定View是使用何種繪制方式：

1、硬件加速繪制
2、軟件繪制
3、軟件緩存繪制

軟件緩存繪制
來看看如何構建軟件緩存：

#View.javapublic void buildDrawingCache(boolean autoScale) {//如果緩存標記為失效或者緩存為空if ((mPrivateFlags & PFLAG_DRAWING_CACHE_VALID) == 0 || (autoScale ?mDrawingCache == null : mUnscaledDrawingCache == null)) {try {//構建緩存buildDrawingCacheImpl(autoScale);} finally {Trace.traceEnd(Trace.TRACE_TAG_VIEW);}}}private void buildDrawingCacheImpl(boolean autoScale) {int width = mRight - mLeft;int height = mBottom - mTop;...boolean clear = true;Bitmap bitmap = autoScale ? mDrawingCache : mUnscaledDrawingCache;//bitmap 不存在或者bitmap與View尺寸不一致，則創建...Canvas canvas;if (attachInfo != null) {canvas = attachInfo.mCanvas;if (canvas == null) {//第一次，AttachInfo里并沒有Canvascanvas = new Canvas();}//關聯bitmapcanvas.setBitmap(bitmap);attachInfo.mCanvas = null;} else {//很少走這canvas = new Canvas(bitmap);}computeScroll();final int restoreCount = canvas.save();//根據內容滾動平移canvas.translate(-mScrollX, -mScrollY);mPrivateFlags |= PFLAG_DRAWN;if (mAttachInfo == null || !mAttachInfo.mHardwareAccelerated ||mLayerType != LAYER_TYPE_NONE) {//打上標記，說明軟件繪制緩存已生效mPrivateFlags |= PFLAG_DRAWING_CACHE_VALID;}//同樣的，調用公共方法if ((mPrivateFlags & PFLAG_SKIP_DRAW) == PFLAG_SKIP_DRAW) {mPrivateFlags &= ~PFLAG_DIRTY_MASK;dispatchDraw(canvas);drawAutofilledHighlight(canvas);if (mOverlay != null && !mOverlay.isEmpty()) {mOverlay.getOverlayView().draw(canvas);}} else {draw(canvas);}canvas.restoreToCount(restoreCount);canvas.setBitmap(null);if (attachInfo != null) {//記錄下來，下次創建直接使用attachInfo.mCanvas = canvas;}}

如此一來，軟件緩存就構建完成了，其結果存儲在Bitmap里，可以通過如下方法獲取：

#View.javapublic Bitmap getDrawingCache(boolean autoScale) {//禁止使用軟件緩存//默認不禁止if ((mViewFlags & WILL_NOT_CACHE_DRAWING) == WILL_NOT_CACHE_DRAWING) {return null;}if ((mViewFlags & DRAWING_CACHE_ENABLED) == DRAWING_CACHE_ENABLED) {//是否開啟了軟件緩存繪制，默認不開啟//構建緩存buildDrawingCache(autoScale);}//將緩存返回return autoScale ? mDrawingCache : mUnscaledDrawingCache;}

該方法可用來獲取View的頁面。
做一個小結：

一開始，硬件加速繪制流程和軟件繪制流程各走各的互不影響。
1、使用軟件繪制時候，設置了離屏緩存類型：軟件緩存，則軟件繪制失效，僅僅使用軟件緩存繪制。設置了硬件緩存類型也當做軟件緩存繪制。
2、使用硬件加速繪制的時候，設置了離屏緩存類型：軟件緩存，則硬件加速繪制失效，僅僅使用軟件緩存繪制。這也就是為什么設置軟件緩存可以禁用硬件加速的原因。
3、軟件緩存繪制的結果保存在bitmap里，該Bitmap最終會繪制到父布局的Canvas里。

不管使用哪種繪制類型，都會走共同的調用方法：draw(xx)/dispatchDraw(xx)。
因此，繪制類型對于我們重寫onDraw(xx)是透明的。

Canvas 從哪里來到哪里去
軟件繪制
從ViewRootImpl->drawSoftware(xx)開始，通過：

canvas = mSurface.lockCanvas(dirty);

生成了Canvas。該Canvas通過View.draw(xx)方法傳遞給所有的子布局，因此此種情形下，整個ViewTree共享同一個Canvas對象。Canvas類型為：CompatibleCanvas。
硬件加速繪制
從View->updateDisplayListIfDirty(xx)開始，通過：

final RecordingCanvas canvas = renderNode.beginRecording(width, height);

生成了Canvas。可以看出，對于每個支持硬件加速的View都重新生成了Canvas。Canvas類型為：RecordingCanvas。
軟件緩存繪制
從View->buildDrawingCacheImpl(xx)開始，通過：

canvas = new Canvas();

生成了Canvas，并將該Canvas記錄在AttachInfo里，下次再次構建該View軟件緩存時拿出來使用。可以看出，對于每個使用了軟件緩存的View都生成了新的Canvas，當然如果AttachInfo有，就可以重復使用。
脫離View的Canvas
以上三者有個共同的特點：所生成的Canvas最終都與Surface建立了聯系，因此通過這些Canvas繪制的內容最終能夠展示在屏幕上。
那是否可以直接構造脫離View的Canvas呢？答案是可以的。

private void buildCanvas(int width, int height) {Bitmap bitmap = Bitmap.createBitmap(width, height, Bitmap.Config.ARGB_8888);Canvas canvas = new Canvas();canvas.setBitmap(bitmap);//繪制canvas.drawXX(xx);...}

如上所示，創建一個Canvas與Bitmap，并將兩者關聯起來。最后調用Canvas繪制API，繪制的結果將保存在Bitmap里。這個過程實際上也是軟件緩存繪制使用的方法。
當然拿到了Bitmap后，我們想讓其展示就比較簡單了，只要讓其關聯到View上就可以展示到屏幕上了。關聯到View上實際上就是使用View關聯的Canvas將生成的Bitmap繪制其上，

繪制流程全家福
用圖表示繪制流程：

單純的軟件繪制與硬件加速繪制：
設置了軟件緩存時的繪制：

至此，Draw過程系列文章結束。

總結

以上是生活随笔為你收集整理的Android View绘制6　Draw过程（下）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。