前言

好久沒寫部落格了，現在都是一個月才寫一些，也是因為自己沒什麼料，技術仍然有待提高

問題描述

canvas是我們常用的功能，我們經常在canvas畫布上繪製各種自己想要的效果。

今天分享一個自己在呼叫canvas繪製動畫效果的時候遇到的一個問題，由於目標動畫效果需要只顯示一塊區域，比方說我們的圖很多，但是我們只想要它顯示一個小圓，這時候我們可以用clipPath方法來實現。

    /**
     * Intersect the current clip with the specified path.
     *
     * @param path The path to intersect with the current clip
     * @return
 
     true if the resulting is non-empty
     */
    public boolean clipPath(@NonNull Path path) {
        return clipPath(path, Region.Op.INTERSECT);
    }

如何只顯示一個小圓的區域，可以呼叫最簡單的
Path#addCircle()

    /**
     * Add a closed circle contour to the path
     *
     * @param x   The x-coordinate of the center of a circle to add to the path
     * @param
 
 y   The y-coordinate of the center of a circle to add to the path
     * @param radius The radius of a circle to add to the path
     * @param dir    The direction to wind the circle's contour
     */
    public void addCircle(float x, float y, float radius, Direction dir) {
        isSimplePath = false
 
;
        native_addCircle(mNativePath, x, y, radius, dir.nativeInt);
    }

也可以繪製一個橢圓區域來實現圓形，我們只需要保證外接矩陣是正方形就行
Path#addOval()

    /**
     * Add a closed oval contour to the path
     *
     * @param oval The bounds of the oval to add as a closed contour to the path
     * @param dir  The direction to wind the oval's contour
     */
    public void addOval(RectF oval, Direction dir) {
        addOval(oval.left, oval.top, oval.right, oval.bottom, dir);
    }

還有一種方式，我們可以自己繪製一段圓弧，在之前的部落格中我提到如何利用貝塞爾曲線繪製一個圓形，只不過過程略顯繁瑣。

當然除了呼叫clipPath，我們還可以利用其他api來實現這種效果。
有時候覺得，做動畫是一件很有意思的事情，但是真正到了過機型的時候，又是一件最煩心的事。

我們發現，在部分機型上，clipPath()方法會失效，明明想要切的是圓形，卻得到的只是矩陣。
看一下我們的示例程式碼：

    @Override
    protected void onDraw(Canvas canvas) {
        super.onDraw(canvas);
        testAddCircle(canvas);
    }

    private void testAddCircle(Canvas canvas) {
        mClipPath = new Path();
        mClipPath.addCircle(80, 80, 80, Path.Direction.CCW);
        canvas.clipPath(mClipPath);
        canvas.drawColor(0xFF892342);
    }

在某臺4.0的手機上執行，再看一下結果：

後來我們在Overflow上找到的答案：

Canvas.clipPath() support with hardware acceleration has been reintroduced since API 18.

API18以下的機型，當開啟硬體加速的時候，clipPath()方法會不支援且失效。

關於硬體加速

API11（Android3.0）的時候開始支援，開啟硬體加速能夠讓我們的圖形繪製更加流暢，API14的時候，預設所有的Activity都是開啟硬體加速的。

Android 的繪圖模式

當硬體加速開啟的時候，Framework層會採用新的繪圖模式(display lists)來把你的應用程式繪製到螢幕上。

1) 軟體繪圖模式（Software-based drawing model）

在軟體繪圖模式中，檢視通過以下兩部來實現繪製：
呼叫Invalidate重新整理檢視框架
重新繪製檢視框架

這種繪圖模式的隱患：

在每次繪圖的時候，會帶來大量的程式碼執行，例如，當我們的呼叫某個Button的invalidate()方法的時候，如果這個Button處於某個ViewGroup的頂層檢視中，會造成這個ViewGroup也會重新繪製。這樣就造成了無意義的繪製，浪費了大量資源。同時，這樣的繪圖模式可能會在程式中隱藏一些Bug，尤其是在上一種情況中，ViewGroup本來不需要重新繪製，卻因為和Button有了檢視交集，而重新繪製重新整理，可能會出現我們原本不期望出現的情況。

Note: Android檢視會自動呼叫invalidate在其屬性更改時，如背景顏色或TextView中的文字。

2) 硬體繪圖模式(Hardware accelerated drawing model)

硬體加速開啟之後，會啟用硬體繪圖模式，主要有以下步驟：

Invalidate the hierarchy 呼叫invalidate重新整理檢視框架
Record and update display lists 記錄和更新展示層集合
Draw the display lists 繪製展示層集合

Android框架依然會使用invalidate方法和draw方法來重新整理和繪製檢視，只不過不在呼叫後立刻重新繪製。Disaplay Lists是一個繪製命令緩衝區，也就是說，當View的成員函式onDraw被呼叫時，我們呼叫通過引數傳遞進來的Canvas的drawXXX成員函式繪製圖形時，我們實際上只是將對應的繪製命令以及引數儲存在一個Display List中。接下來再通過Display List Renderer執行這個Display List的命令，這個過程稱為Display List Replay。

引進Display List的概念有什麼好處呢？

主要是兩個好處。第一個好處是在下一幀繪製中，如果一個View的內容不需要更新，那麼就不用重建它的DisplayList，也就是不需要呼叫它的onDraw成員函式。第二個好處是在下一幀中，如果一個View僅僅是一些簡單的屬性發生變化，例如位置和Alpha值發生變化，那麼也無需要重建它的Display List，只需要在上一次建立的DisplayList中修改一下對應的屬性就可以了，這也意味著不需要呼叫它的onDraw成員函式。這兩個好處使用在繪製應用程式視窗的一幀時，省去很多應用程式程式碼的執行，也就是大大地節省了CPU的執行時間。

然而，不是所有canvas繪圖都支援硬體加速的，從developer開發者網站我可以看到：
https://developer.android.com/guide/topics/graphics/hardware-accel.html#model
clipPath()方法從API18開始才能支援硬體加速，另外，drawBitmapMesh()方法也是從API18才開始支援硬體加速，更多的2D繪製支援版本我們可以瀏覽開發者網站。

解決方案

Overflow上的開發者提供了兩個解決方案：

1) 低版本放棄硬體加速

我們都知道3.0之後硬體加速是預設開啟的，它能為我們提供更加流暢的介面效果，當我們需要繪製複雜動畫的時候，就需要開啟硬體加速，否則動畫效果會極差，出現卡頓現象。
這時候，如果我們只是需要切一個靜態的圖片，例如我們要實現一個圓角頭像圖片，就可以放棄硬體加速。關閉硬體加速可以從三個途徑來實現，這裡我們直接從View層來禁用硬體加速。

if (Build.VERSION.SDK_INT < Build.VERSION_CODES.JELLY_BEAN_MR2
        && Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
    setLayerType(LAYER_TYPE_SOFTWARE, null);
}

2) 低版本放棄clipPath()方法

前面說到如果是複雜動畫，在關閉硬體加速的情況下，會失去動畫的流暢性。這時候我們只能放棄clipPath()方法。

if (doClip) {
    try {
        canvas.clipPath(clipPath);
    } catch (UnsupportedOperationException e) {
        Log.e(TAG, "clipPath() not supported");
        doClip = false;
    }
}

捕捉到異常之後，我們利用其他方法來實現類似的效果，例如通過Xfermode或者BitmapShader的方式來實現。

3) 不放棄clipPath()方法也不放棄硬體加速（11.17在看硬體加速原理的時候更新）

在前面分析開啟硬體加速的時候，Android是通過硬體模式來繪製，onDraw()中我們寫入的繪製程式碼都不會立刻執行，而會一條一條儲存在DisplayList中，也就是通過onDraw()傳入引數canvas呼叫的繪製方法，最後會使用硬體加速來繪製。
那麼，對於使用了GPU不支援的2DUI繪製命令的View，我們的做法是建立一個新的Canvas，這個Canvas的底層是一個Bitmap，也就是說，我們那些不支援的2DUI繪製都發生在這個Bitmap上。繪製完成之後，再把這個Bitmap再被記錄在其Parent View的Display List中。
而當Display List的命令被執行時，記錄在裡面的Bitmap再通過Open GL命令來繪製。

 void onDraw(Canvas canvas) {
        super.onDraw(canvas);
        mTempCanvas.drawColor(Color.TRANSPARENT, PorterDuff.Mode.CLEAR);
        mTempCanvas.clipPath(mClipPath);
        mTempCanvas.drawBitmap(mTargetBitmap, null, mRect, null);
        Rect rect = new Rect(0, 0, sceneWidth, sceneHeight);
        canvas.drawBitmap(mTempBitmap, rect, rect, null);
}

最後，連結一篇文章，其中詳細地講解了硬體加速的由來以及原理：

老羅寫的部落格真是太賞心悅目了。