android創建view

『壹』 android中如何用代碼生成View控制項

在代碼中，如果需要生成一個View控制項，只需要像對待一般對象一樣，使用new關鍵字，即可創建一個View。
代碼演示：
TextView mTextView = new TextView(this);//此例代指系統自帶控制項View
M_drawView m_drawView = new M_drawView(this);// 此例代指自定義控制項View
View是所有UI控制項，容器控制項的基類，View需要放到容器組件中或者，使用Activity將它顯示出來。
開發者可以通過繼承View類來派生出自定義的View。

『貳』 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之Draw過程(上)

Draw 過程系列文章

Android 展示之三部曲：

前邊我們已經分析了：

這倆最主要的任務是： 確定View/ViewGroup可繪制的矩形區域。
接下來將會分析，如何在這給定的區域內繪制想要的圖形。

通過本篇文章，你將了解到：

Android 提供了關於View最基礎的兩個類：

然而ViewGroup 並沒有約定其內部的子View是如何布局的，是疊加在一起呢？還是橫向擺放、縱向擺放等。同樣的View 也沒有約定其展示的內容是啥樣，是矩形、圓形、三角形、一張圖片、一段文字抑或是不規則的形狀？這些都要我們自己去實現嗎？
不盡然，值得高興的是Android已經考慮到上述需求了，為了開發方便已經預制了一些常用的ViewGroup、View。
如：
繼承自ViewGroup的子類

繼承自View的子類

雖然以上衍生的View/ViewGroup子類已經大大為我們提供了便利，但也僅僅是通用場景下的通用控制項，我們想實現一些較為復雜的效果，比如波浪形狀進度條、會發光的球體等，這些系統控制項就無能為力了，也沒必要去預制千奇百怪的控制項。想要達到此效果，我們需要自定義View/ViewGroup。
通常來說自定義View/ViewGroup有以下幾種：

3 一般不怎麼用，除非布局比較特殊。1、2、4 是我們常用的手段，對於我們常說的"自定義View" 一般指的是 4。
接下來我們來看看 4是怎麼實現的。

在xml里引用MyView

效果如下：

黑色部分為其父布局背景。
紅色矩形+黃色圓形即是MyView繪制的內容。
以上是最簡單的自定義View的實現，我們提取重點歸納如下：

由上述Demo可知，我們只需要在重寫的onDraw(xx)方法里繪制想要的圖形即可。
來看看View 默認的onDraw(xx)方法：

發現是個空實現，因此繼承自View的類必須重寫onDraw(xx)方法才能實現繪制。該方法傳入參數為：Canvas類型。
Canvas翻譯過來一般叫做畫布，在重寫的onDraw(xx)里拿到Canvas對象後，有了畫布我們還需要一支筆，這只筆即為Paint，翻譯過來一般稱作畫筆。兩者結合，就可以愉快的作畫(繪制)了。
你可能發現了，在Demo里調用

並沒有傳入Paint啊，是不是Paint不是必須的？實際上調用該方法後，底層會自動生成Paint對象。

可以看到，底層初始化了Paint，並且給其設置的顏色為在java層設置的顏色。

onDraw(xx)比較簡單，開局一個Canvas，效果全靠畫。
試想，這個Canvas怎麼來的呢，換句話說是誰調用了onDraw(xx)。發揮一下聯想功能，在Measure、Layout 過程有提到過兩者套路很像：

那麼Draw過程是否也是如此套路呢？看見了onDraw(xx)，那麼draw(xx)還遠嗎？
沒錯，還真有draw(xx)方法：

可以看出，draw(xx)主要分為兩個部分：

不管是A分支還是B分支，都進行了好幾步的繪制。
通常來說，單一一個View的層次分為：

後面繪制的可能會遮擋前邊繪制的。
對於一個ViewGroup來說，層次分為：

來看看A分支標注的4個點:
(1)
onDraw(canvas)
前面分析過，對於單一的View，onDraw(xx)是空實現，需要由我們自定義繪制。
而對於ViewGroup，也並沒有具體實現，如果在自定義ViewGroup里重寫onDraw(xx)，它會執行嗎？默認是不會執行的，相關分析請移步：
Android ViewGroup onDraw為什麼沒調用

(2)
dispatchDraw(canvas)，來看看在View.java里的實現:

發現是個空實現，再看看ViewGroup.java里的實現:

也即是說，對於單一View，因為沒有子布局，因此沒必要再分發Draw，而對於ViewGroup來說，需要觸發其子布局發起Draw過程(此過程後續分析)，可以類比事件分發過程View、ViewGroup的處理。感興趣的請移步：
Android 輸入事件一擼到底之View接盤俠（3）

(3)
OverLay，顧名思義就是"蓋在某個東西上面"，此處是在繪制內容之後，繪制前景之前。怎麼用呢？

以上是給一個ViewGroup設置overLay，效果如下：

你可能發現了，這和設置overLay差不多的嘛，實際還是有差別的。在onDrawForeground(xx)里會重新調整Drawable的尺寸，該尺寸與View大小一致，之前給Drawable設置的尺寸會失效。運行效果如下：

可以看出，ViewGroup都被前景蓋住了。
再來看看B分支的重點：邊緣漸變效果
先來看看TextView 邊緣漸變效果：

加上這倆參數。
實際上系統自帶的一些控制項也使用了該效果，如NumberPicker、YearPickerView

以上是NumberPicker 的效果，可以看出是垂直方向漸變的。

對於View.java 里的onDraw(xx)、draw(xx)，ViewGroup.java里並沒有重寫。
而對於dispatchDraw(xx)，在View.java里是空實現。在ViewGroup.java里發起對子布局的繪制。

來看看標記的2點：
(1)
設置padding的目的是為了讓子布局留出一定的空隙出來，因此當設置了padding後，子布局的canvas需要根據padding進行裁減。判斷標記為：

FLAG_CLIP_TO_PADDING 默認設置為true
FLAG_PADDING_NOT_NULL 只要有padding不為0，該標記就會打上。
也就是說：只要設置了padding 不為0，子布局顯示區域需要裁減。
能不能不讓子布局裁減顯示區域呢？
答案是可以的。
考慮到一種場景：使用RecyclerView的時候，我們需要設置paddingTop = 20px，效果是：RecyclerView Item展示時離頂部有20px，但是滾動的時候永遠滾不到頂部，看起來不是那麼友好。這就是上述的裁減起作用了，需要將此動作禁止。通過設置：

當然也可以在xml里設置：

(2)
drawChild(xx)

從方法名上看是調用子布局進行繪制。
child.draw(x1,x2,x3)里分兩種情況:

這兩者具體作用與區別會在下篇文章分析，不管是硬體加速繪制還是軟體加速繪制，最終都會調用View.draw(xx)方法，該方法上面已經分析過。
注意，draw(x1,x2,x3)與draw(xx)並不一樣，不要搞混了。

用圖表示：

View/ViewGroup Draw過程的聯系：

一般來說，我們通常會自定義View，並且重寫其onDraw(xx)方法，有沒有繪制內容的ViewGroup需求呢？
是有的，舉個例子，大家可以去看看RecyclerView ItemDecoration 的繪制，其中運用到了ViewGroup draw(xx)、ViewGroup onDraw(xx) 、View onDraw(xx)繪制的先後順序來實現分割線，分組頭部懸停等功能的。

本篇文章基於 Android 10.0

『肆』 如何在android studio中實現自定義view

一、首先新建一個項目，項目及名稱自擬。
二、在app上點擊右鍵->new->Mole 選擇Android library。
三、在topbar下的values中新建一個attrs.xml文件，用來存放自定義view的屬性。
4.在topbar下實現view。
5.上面兩部做完後就是引用這個view，這里需要注意的是要在主app的build.gradle中添加引用如下：
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile project(':topbar')
}
topbar就是要使用的moudle，切記添加引用。然後就可以使用了。
6.要想使用自定義view中的屬性的話任然需要添加xmlns:custom="schemas.android.com/apk/res-auto"，前面加上http。
在這里還要注意命名空間也就是xustom之前一定不能定義過，否則重復的話就無法使用。

『伍』 Android開發 自定義View

Android自定義View實現很簡單:
1、繼承View，重寫構造函數、onDraw，（onMeasure）等函數。
2、如果自定義的View需要有自定義的屬性，需要在values下建立attrs.xml。在其中定義你的屬性。
3、在使用到自定義View的xml布局文件中需要加入xmlns:前綴="http://schemas.android.com/apk/res/你的自定義View所在的包路徑".
4、在使用自定義屬性的時候，使用前綴：屬性名，如my:textColor="#FFFFFFF"。
實例：
自定義TextView類：
復制代碼
package com.zst.service.component;
import com.example.hello_wangle.R;
import android.content.Context;
import android.content.res.TypedArray;
import android.graphics.Canvas;
import android.graphics.Color;
import android.graphics.Paint;
import android.util.AttributeSet;
import android.util.Log;
import android.view.View;
import android.widget.TextView;
public class MyTextView extends TextView {
//不能在布局文件中使用
public MyTextView(Context context) {
super(context);
}

//布局文件中用到此構造函數

『陸』 Android寶典|View必考知識點總結

我們知道，Activity 是在 ActivityThread 的 performLaunchActivity 中進行創建的，在創建完成之後就會調用其 attach 方法，它是先於 onCreate、onStart、onResume 等生命周期函數的，因此將 attach 方法作為這篇文章主線的開頭：

attach() 方法就是 new 一個 PhoneWindow 並且關聯 WindowManager。

接下來就到了 onCreate 方法：

這一步就是把我們的布局文件解析成 View 塞到 DecorView 的一個 id 為 R.id.content 的 ContentView 中，DecorView 本身是一個 FrameLayout，它還承載了 StatusBar、NavigationBar 。

然後在 handleResumeActivity 中，通過 WindowManager 的 addView 方法把 DecorView 添加進去，實際實現是 WindowManagerImpl 的 addView 方法，它裡面再通過 WindowManagerGlobal 的實例去 addView 的，在它裡面就會 new 一個 ViewRootImpl，也就是說最後是把 DecorView 傳給了 ViewRootImpl 的 setView 方法。ViewRootImpl 是 DecorView 的管理者，它負責 View 樹的測量、布局、繪制，以及通過 Choreographer 來控制 View 的刷新。

WMS 是所有 Window 窗口的管理員，負責 Window 的添加和刪除、Surface 的管理和事件派發等等，因此每一個 Activity 中的 PhoneWindow 對象如果需要顯示等操作，就必須要與 WMS 交互才能進行。

在 ViewRootImpl 的 setView 方法中，會調用 requestLayout，並且通過 WindowSession 的 addToDisplay 與 WMS 進行交互。WMS 會為每一個 Window 關聯一個 WindowStatus。

SurfaceFlinger 主要是進行 Layer 的合成和渲染。

在 WindowStatus 中，會創建 SurfaceSession，SurfaceSession 會在 Native 層構造一個 SurfaceComposerClient 對象，它是應用程序與 SurfaceFlinger 溝通的橋梁。

經過步驟四和步驟五之後，ViewRootImpl 與 WMS、SurfaceFlinger 都已經建立起連接，但此時 View 還沒顯示出來，我們知道，所有的 UI 最終都要通過 Surface 來顯示，那麼 Surface 是什麼時候創建的呢？

這就要回到前面所說的 ViewRootImpl 的 requestLayout 方法了，首先會 checkThread 檢查是否是主線程，然後調用 scheleTraversals 方法，scheleTraversals 方法會先設置同步屏障，然後通過 Choreographer 類在下一幀到來時去執行 doTraversal 方法。簡單來說，Choreographer 內部會接受來自 SurfaceFlinger 發出的 Vsync 垂直同步信號，這個信號周期一般是 16ms 左右。doTraversal 方法首先會先移除同步屏障，然後 performTraversals 真正進行 View 的繪制流程，即調用 performMeasure、performLayout、performDraw。不過在它們之前，會先調用 relayoutWindow 通過 WindowSession 與 WMS 進行交互，即把 Java 層創建的 Surface 與 Native 層的 Surface 關聯起來。

接下來就是正式繪制 View 了，從 performTraversals 開始，Measure、Layout、Draw 三步走。

第一步是獲取 DecorView 的寬高的 MeasureSpec 然後執行 performMeasure 流程。MeasureSpec 簡單來說就是一個 int 值，高 2 位表示測量模式，低 30 位用來表示大小。策略模式有三種，EXACTLY、AT_MOST、UNSPECIFIED。EXACTLY 對應為 match_parent 和具體數值的情況，表示父容器已經確定 View 的大小；AT_MOST 對應 wrap_content，表示父容器規定 View 最大隻能是 SpecSize；UNSPECIFIED 表示不限定測量模式，父容器不對 View 做任何限制，這種適用於系統內部。接著說，performMeasure 中會去調用 DecorView 的 measure 方法，這個是 View 裡面的方法並且是 final 的，它裡面會把參數透傳給 onMeasure 方法，這個方法是可以重寫的，也就是我們可以干預 View 的測量過程。在 onMeasure 中，會通過 getDefaultSize 獲取到寬高的默認值，然後調用 setMeasureDimension 將獲取的值進行設置。在 getDefaultSize 中，無論是 EXACTLY 還是 AT_MOST，都會返回 MeasureSpec 中的大小，這個 SpecSize 就是測量後的最終結果。至於 UNSPECIFIED 的情況，則會返回一個建議的最小值，這個值和子元素設置的最小值以及它的背景大小有關。從這個默認實現來看，如果我們自定義一個 View 不重寫它的 onMeasure 方法，那麼 warp_content 和 match_parent 一樣。所以 DecorView 重寫了 onMeasure 函數，它本身是一個 FrameLayout，所以最後也會調用到 FrameLayout 的 onMeasure 函數，作為一個 ViewGroup，都會遍歷子 View 並調用子 View 的 measure 方法。這樣便實現了層層遞歸調用到了每個子 View 的 onMeasure 方法進行測量。

第二步是執行 performLayout 的流程，也就是調用到 DecorView 的 layout 方法，也就是 View 裡面的方法，如果 View 大小發生變化，則會回調 onSizeChanged 方法，如果 View 狀態發生變化，則會回調 onLayout 方法，這個方法在 View 中是空實現，因此需要看 DecorView 的父容器 FrameLayout 的 onLayout 方法，這個方法就是遍歷子 View 調用其 layout 方法進行布局，子 View 的 layout 方法被調用的時候，它的 onLayout 方法又會被調用，這樣就布局完了所有的 View。

第三步就是 performDraw 方法了，裡面會調用 drawSoftware 方法，這個方法需要先通過 mSurface lockCanvas 獲取一個 Canvas 對象，作為參數傳給 DecorView 的 draw 方法。這個方法調用的是 View 的 draw 方法，先繪制 View 背景，然後繪制 View 的內容，如果有子 View 則會調用子 View 的 draw 方法，層層遞歸調用，最終完成繪制。

完成這三步之後，會在 ActivityThread 的 handleResumeActivity 最後調用 Activity 的 makeVisible，這個方法就是將 DecorView 設置為可見狀態。

https://juejin.im/post/5c67c1e16fb9a04a05403549

https://juejin.im/post/5bf16ff5f265da6141712acc

『柒』 Android自定義View——從零開始實現書籍翻頁效果（一）

前言 ：本篇是系列博客的第三篇，這次我們要研究 書籍翻頁效果 。不知道大家平時有沒用過iReader、掌閱這些小說軟體，裡面的翻頁效果感覺十分的酷炫。有心想研究研究如何實現，於是網上找了找，發現這方面的教學資料非常少，所幸能找到 何明桂大大 的 Android 實現書籍翻頁效果----原理篇 這樣的入門博客（感謝大大 Orz），我們就以這篇博客為切入點從零實現我們自己的翻頁效果。由於這次坑比較深，預計會寫好幾期，感興趣的小夥伴可以點下關注以便及時收到更新提醒，謝謝大家的支持 ~

本篇只著重於思路和實現步驟，裡面用到的一些知識原理不會非常細地拿來講，如果有不清楚的api或方法可以在網上搜下相應的資料，肯定有大神講得非常清楚的，我這就不獻丑了。本著認真負責的精神我會把相關知識的博文鏈接也貼出來（其實就是懶不想寫那麼多哈哈），大家可以自行傳送。為了照顧第一次閱讀系列博客的小夥伴，本篇會出現一些在之前 系列博客 就講過的內容，看過的童鞋自行跳過該段即可

國際慣例，先上效果圖，本次主要實現了 基本的上下翻頁效果 與 右側最大翻頁距離的限制

在看這篇博客之前，希望大家能先了解一下書籍翻頁的實現原理，博客鏈接我已經貼出來了。通過原理講解我們知道，整個書籍翻頁效果界面分成了三個區域， A 為當前頁區域， B 為下一頁區域， C 為當前頁背面，如圖所示

書籍翻頁效果的實現就是要以我們 觸摸屏幕位置的坐標 為基礎繪制出這三個區域，形成模擬翻頁的特效。要繪制這三個區域，我們需要通過一組 特定的點 來完成，這些點的坐標需要通過兩個已知的點（ 觸摸點 、 相對邊緣角 ）計算得到，下圖我將各個特定點的位置和計算公式貼出來，大家對照著原理一起理解（渣畫工望體諒 ╮(╯▽╰)╭ ），其中 b 點是由 ae 和 cj 的交點， k 點是由 ah 和 cj 的交點

簡單總結一下， a 是觸摸點， f 是觸摸點相對的邊緣角， eh 我們設置為 af 的垂直平分線，則 g 是 af 的中點， ab 、 ak 、 dj 是 直線 ； 曲線cdb 是起點為 c ，控制點為 e ，終點為 b 的 二階貝塞爾曲線 ； 曲線kij 是起點為 k ，控制點為 h ，終點為 j 的 二階貝塞爾曲線 ，區域 A 、 B 、 C 就由這些點和線劃分開來。我們將這些點稱為標識點，下一步就是模擬設定 a 和 f 點的位置，將這組標識點繪制到屏幕上來驗證我們的計算公式是否正確，創建 BookPageView

實體類 MyPoint 用來存放我們的標識點坐標

界面布局：

在Activity中進行注冊

效果如圖

前文我們提到 ab 、 ak 、 dj 是 直線 ； 曲線cdb 是起點為 c ，控制點為 e ，終點為 b 的 二階貝塞爾曲線 ； 曲線kij 是起點為 k ，控制點為 h ，終點為 j 的 二階貝塞爾曲線 。通過觀察分析得知， 區域A 是由View 左上角 ， 左下角 ， 曲線cdb ， 直線 ab 、 ak ， 曲線kij ， 右上角 連接而成的區域，修改 BookPageView ，利用 path 繪制處 區域A

效果如圖

區域C 理論上應該是由點 a , b , d , i , k 連接而成的閉合區域,但由於 d 和 i 是曲線上的點，我們沒辦法直接從 d 出發通過 path 繪制路徑連接 b 點（ i , k 同理），也就不能只用 path 的情況下直接繪制出 區域C ，我們需要用 PorterDuffXfermode 方面的知識「曲線救國」。我們試著先將點 a , b , d , i , k 連接起來，觀察閉合區域與 區域A 之間的聯系。修改 BookPageView

效果如圖

我們將兩條曲線也畫出來對比觀察

觀察分析後可以得出結論， 區域C 是 由直線ab,bd,dj,ik,ak連接而成的區域 減去 與區域A交集部分 後剩餘的區域。於是我們設置 區域C 畫筆 Xfermode 模式為 DST_ATOP

效果如圖

最後是 區域B ，因為 區域B 處於最底層，我們直接將 區域B 畫筆 Xfermode 模式設為 DST_ATOP ，在 區域A、C 之後繪制即可，修改 BookPageView

效果如圖

翻頁可以從右下方翻自然也可以從右上方翻，我們將 f 點設在右上角，由於View上下兩部分是呈 鏡像 的，所以各標識點的位置也應該是鏡像對應的，因為 區域B和C 的繪制與 f 點沒有關系，所以我們只需要修改 區域A 的繪制邏輯，新增 getPathAFromTopRight() 方法

效果如圖

之前由於測試效果沒有對View的大小進行重新測量，在實現觸摸翻頁之前先把這個結了。重寫View的 onMeasure() 方法

我們的需求是，在上半部分翻頁時 f 點在右上角，在下半部分翻頁時 f 則在右下角，當手指離開屏幕時回到 初始狀態 ，根據需求，修改 BookPageView

在Activity中監聽View的 onTouch 狀態

注意，要設置 android:clickable 為 true ，否則無法監聽到 ACTION_MOVE 和 ACTION_UP 狀態

效果如圖

到這里我們已經實現了基本的翻頁效果，但要還原真實的書籍翻頁效果，我們還需要設置一些限制條件來完善我們的項目

對於一般的書本來說，最左側應該是釘起來的，也就是說如果我們從右側翻頁，翻動的距離是 有限制的 ，最下方翻頁形成的曲線起點（ c 點）的x坐標不能小於0（上方同理），按照這個限定條件，修改我們的 BookPageView

效果如圖

至此本篇教程就告一段落了，當然還有許多功能需要繼續完善，例如橫向翻頁、翻頁動畫、陰影效果等等，這些都會在後面的教程中一一解決。如果大家看了感覺還不錯麻煩點個贊，你們的支持是我最大的動力~

『捌』 Android 動態創建View，是否可以使用 style，如何使用

Android 是可以使用 style的，具體方法為：
1、在Android中可以這樣定義樣式：
在res/values/styles.xml文件中添加以下內容
<?xml version="1.0" encoding="utf-8"?>
<resources>
<style name=「itcast」>
<item name="android:textSize">18px</item>
<item name="android:textColor">#0000CC</item>
</style>
</resources>
2、在layout文件中可以像下面這樣使用上面的android樣式：
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" ....>
<TextView style="@style/itcast"
..... />
3、可以使他繼承父樣式，當然，如果父樣式的值不符合需求，你也可以對它進行修改，如下：
<?xml version="1.0" encoding="utf-8"?>
<resources>
<style name="itcast">
<item name="android:textSize">18px</item>
<item name="android:textColor">#0000CC</item>
</style>
<style name="subitcast" parent="@style/itcast">
<item name="android:textColor">#FF0000</item>
</style>
</resources>

『玖』 android 自定義view 怎麼規定view的樣式

android 自定義view的樣式的實現：

1.在values文件夾下，打開attrs.xml，其實這個文件名稱可以是任意的，寫在這里更規范一點，表示裡面放的全是view的屬性。

2.因為我們下面的實例會用到2個長度，一個顏色值的屬性，所以我們這里先創建3個屬性。

<declare-styleable name="rainbowbar">
<attr name="rainbowbar_hspace" format="dimension"></attr>
<attr name="rainbowbar_vspace" format="dimension"></attr>
<attr name="rainbowbar_color" format="color"></attr>
</declare-styleable>

舉例說明：

藍色的進度條

public class RainbowBar extends View {

//progress bar color
int barColor = Color.parseColor("#1E88E5");
//every bar segment width
int hSpace = Utils.dpToPx(80, getResources());
//every bar segment height
int vSpace = Utils.dpToPx(4, getResources());
//space among bars
int space = Utils.dpToPx(10, getResources());
float startX = 0;
float delta = 10f;
Paint mPaint;

public RainbowBar(Context context) {
super(context);
}

public RainbowBar(Context context, AttributeSet attrs) {
this(context, attrs, 0);
}

public RainbowBar(Context context, AttributeSet attrs, int defStyleAttr) {
super(context, attrs, defStyleAttr);
//read custom attrs
TypedArray t = context.obtainStyledAttributes(attrs,
R.styleable.rainbowbar, 0, 0);
hSpace = t.getDimensionPixelSize(R.styleable.rainbowbar_rainbowbar_hspace, hSpace);
vSpace = t.getDimensionPixelOffset(R.styleable.rainbowbar_rainbowbar_vspace, vSpace);
barColor = t.getColor(R.styleable.rainbowbar_rainbowbar_color, barColor);
t.recycle(); // we should always recycle after used
mPaint = new Paint();
mPaint.setAntiAlias(true);
mPaint.setColor(barColor);
mPaint.setStrokeWidth(vSpace);
}

.......
}

View有了三個構造方法需要我們重寫，這里介紹下三個方法會被調用的場景，

第一個方法，一般我們這樣使用時會被調用，View view = new View(context);

第二個方法，當我們在xml布局文件中使用View時，會在inflate布局時被調用，
<View layout_width="match_parent" layout_height="match_parent"/>。

第三個方法，跟第二種類似，但是增加style屬性設置，這時inflater布局時會調用第三個構造方法。
<View style="@styles/MyCustomStyle" layout_width="match_parent" layout_height="match_parent"/>。

『拾』 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工作完畢。