Flutter性能優(yōu)化

1.圓角對性能的影響

成都創(chuàng)新互聯(lián)公司專注于惠民企業(yè)網(wǎng)站建設,響應式網(wǎng)站,商城網(wǎng)站開發(fā)。惠民網(wǎng)站建設公司,為惠民等地區(qū)提供建站服務。全流程按需制作網(wǎng)站，專業(yè)設計，全程項目跟蹤，成都創(chuàng)新互聯(lián)公司專業(yè)和態(tài)度為您提供的服務

盡量避免用Clipxxx組件，建議用BoxDecoration的image屬性實現(xiàn)，如果用Clipxxx組件，圓角取整后性能會提升。

2.減少重繪

根據(jù)場景合理使用RePaintBoundary，使繪制獨立于父布局，避免重繪，提升性能，但過度使用增加的圖層會帶來Raster合成的耗時。例如scrollview是滑動過程會導致所有的節(jié)點都重繪，可以在scrollview下一層使用RePaintBoundary。

3.滾動步長插值器優(yōu)化（了解）

官方的滾動差值器在出現(xiàn)小卡頓時，滾動步長會出現(xiàn)大的跳躍，導致體感上出現(xiàn)很明顯的抖動，優(yōu)化步長偏移量算法與原生效果對齊。

4.開啟SurfaceView

官方推薦Flutter用SurfaceView ，因為SurfaceView與應用窗口內(nèi)容分隔開，在專有硬件中合成，產(chǎn)生的中間副本少于TextureView，所以性能高，占用內(nèi)存少，但是在混合棧遇到的問題需要突破

5.使用RepaintBoundary 提升頻繁重繪控件的性能。使用RelayoutBoundary提升頻繁修改大小，增刪的布局中也可以提升性能。

6.build中不要去寫大量的耗時邏輯，因為數(shù)據(jù)更新會觸發(fā)build的多次調(diào)用，在里面做耗時邏輯會降低性能。

7.盡量使用statelessWidget代替statefulWidget，因為statefulWidget的銷毀重建會引起子widget的銷毀與重建。

8.解析json可以放到子線程線程中，開Isolate去解析，這樣，當返回數(shù)據(jù)特別大的時候也不會阻塞界面。

9.使用不變的組件的時候可以添加const，const組件不會進行build更新

10.由于flutter通過widget.runtimeType和key來判斷是否需要跟新組建，所以我們寫組件的時候盡量保持key不變，或者不寫key。對于一些需要頻繁改變，例如新增、刪除、排序的最好加上key。如果type一直，如果不寫key容易導致，element無法區(qū)分新舊widget，導致無法更新。

web前端培訓有哪些課程

第一階段 網(wǎng)頁重構：HTML+CSS核心技術、PC端網(wǎng)站布局、HTML5+CSS3核心技術、移動端網(wǎng)站布局、響應式布局實戰(zhàn)

第二階段 JS高級程序設計：JavaScript核心技術-網(wǎng)站動效交互、JavaScript核心技術-網(wǎng)站前后端交互、jQuery交互效果開發(fā)

第三階段 NodeJS前端架構及后臺開發(fā)：版本控制工具、NodeJS核心技術

第四階段 前端框架：Vuejs全家桶-Vue、React框架-React、微信小程序、Flutter

第五階段 小程序開發(fā)：能夠獨立開發(fā)小程序，提高就業(yè)能力，是就業(yè)的加分項。

Android圖形渲染原理上

對于Android開發(fā)者來說，我們或多或少有了解過Android圖像顯示的知識點，剛剛學習Android開發(fā)的人會知道，在Actvity的onCreate方法中設置我們的View后，再經(jīng)過onMeasure，onLayout，onDraw的流程，界面就顯示出來了；對Android比較熟悉的開發(fā)者會知道，onDraw流程分為軟件繪制和硬件繪制兩種模式，軟繪是通過調(diào)用Skia來操作，硬繪是通過調(diào)用Opengl ES來操作；對Android非常熟悉的開發(fā)者會知道繪制出來的圖形數(shù)據(jù)最終都通過GraphiBuffer內(nèi)共享內(nèi)存?zhèn)鬟f給SurfaceFlinger去做圖層混合，圖層混合完成后將圖形數(shù)據(jù)送到幀緩沖區(qū)，于是，圖形就在我們的屏幕顯示出來了。

但我們所知道的Activity或者是應用App界面的顯示，只屬于Android圖形顯示的一部分。同樣可以在Android系統(tǒng)上展示圖像的WebView，F(xiàn)lutter，或者是通過Unity開發(fā)的3D游戲，他們的界面又是如何被繪制和顯現(xiàn)出來的呢？他們和我們所熟悉的Acitvity的界面顯示又有什么異同點呢？我們可以不借助Activity的setView或者InflateView機制來實現(xiàn)在屏幕上顯示出我們想要的界面嗎？Android系統(tǒng)顯示界面的方式又和IOS，或者Windows等系統(tǒng)有什么區(qū)別呢？……

去探究這些問題，比僅僅知道Acitvity的界面是如何顯示出來更加的有價值，因為想要回答這些問題，就需要我們真正的掌握Android圖像顯示的底層原理，當我們掌握了底層的顯示原理后，我們會發(fā)現(xiàn)WebView，F(xiàn)lutter或者未來會出現(xiàn)的各種新的圖形顯示技術，原來都是大同小異。

我會花三篇文章的篇幅，去深入的講解Android圖形顯示的原理，OpenGL ES和Skia的繪制圖像的方式，他們?nèi)绾问褂茫约八麄冊贏ndroid中的使用場景，如開機動畫，Activity界面的軟件繪制和硬件繪制，以及Flutter的界面繪制。那么，我們開始對Android圖像顯示原理的探索吧。

在講解Android圖像的顯示之前，我會先講一下屏幕圖像的顯示原理，畢竟我們圖像，最終都是在手機屏幕上顯示出來的，了解這一塊的知識會讓我們更容易的理解Android在圖像顯示上的機制。

圖像顯示的完整過程，分為下面幾個階段：

圖像數(shù)據(jù)→CPU→顯卡驅動→顯卡（GPU）→顯存（幀緩沖）→顯示器

我詳細介紹一下這幾個階段：

實際上顯卡驅動，顯卡和顯存，包括數(shù)模轉換模塊都是屬于顯卡的模塊。但為了能能詳細的講解經(jīng)歷的步驟，這里做了拆分。

當顯存中有數(shù)據(jù)后，顯示器又是怎么根據(jù)顯存里面的數(shù)據(jù)來進行界面的顯示的呢？這里以LCD液晶屏為例，顯卡會將顯存里的數(shù)據(jù)，按照從左至右，從上到下的順序同步到屏幕上的每一個像素晶體管，一個像素晶體管就代表了一個像素。

如果我們的屏幕分辨率是1080x1920像素，就表示有1080x1920個像素像素晶體管，每個橡素點的顏色越豐富，描述這個像素的數(shù)據(jù)就越大，比如單色，每個像素只需要1bit，16色時，只需要4bit，256色時，就需要一個字節(jié)。那么1080x1920的分辨率的屏幕下，如果要以256色顯示，顯卡至少需要1080x1920個字節(jié)，也就是2M的大小。

剛剛說了，屏幕上的像素數(shù)據(jù)是從左到右，從上到下進行同步的，當這個過程完成了，就表示一幀繪制完成了，于是會開始下一幀的繪制，大部分的顯示屏都是以60HZ的頻率在屏幕上繪制完一幀，也就是16ms，并且每次繪制新的一幀時，都會發(fā)出一個垂直同步信號（VSync）。我們已經(jīng)知道，圖像數(shù)據(jù)都是放在幀緩沖中的，如果幀緩沖的緩沖區(qū)只有一個，那么屏幕在繪制這一幀的時候，圖像數(shù)據(jù)便沒法放入幀緩沖中了，只能等待這一幀繪制完成，在這種情況下，會有很大了效率問題。所以為了解決這一問題，幀緩沖引入兩個緩沖區(qū)，即 雙緩沖機制 。雙緩沖雖然能解決效率問題，但會引入一個新的問題。當屏幕這一幀還沒繪制完成時，即屏幕內(nèi)容剛顯示一半時，GPU 將新的一幀內(nèi)容提交到幀緩沖區(qū)并把兩個緩沖區(qū)進行交換后，顯卡的像素同步模塊就會把新的一幀數(shù)據(jù)的下半段顯示到屏幕上，造成畫面撕裂現(xiàn)象。

為了解決撕裂問題，就需要在收到垂直同步的時候才將幀緩沖中的兩個緩沖區(qū)進行交換。Android4.1黃油計劃中有一個優(yōu)化點，就是CPU和GPU都只有收到垂直同步的信號時，才會開始進行圖像的繪制操作，以及緩沖區(qū)的交換工作。

我們已經(jīng)了解了屏幕圖像顯示的原理了，那么接著開始對Android圖像顯示的學習。

從上一章已經(jīng)知道，計算機渲染界面必須要有GPU和幀緩沖。對于Linux系統(tǒng)來說，用戶進程是沒法直接操作幀緩沖的，但我們想要顯示圖像就必須要操作幀緩沖，所以Linux系統(tǒng)設計了一個虛擬設備文件，來作為對幀緩沖的映射，通過對該文件的I/O讀寫，我們就可以實現(xiàn)讀寫屏操作。幀緩沖對應的設備文件于/dev/fb* ，*表示對多個顯示設備的支持， 設備號從0到31，如/dev/fb0就表示第一塊顯示屏，/dev/fb1就表示第二塊顯示屏。對于Android系統(tǒng)來說，默認使用/dev/fb0這一個設幀緩沖作為主屏幕，也就是我們的手機屏幕。我們Android手機屏幕上顯示的圖像數(shù)據(jù)，都是存儲在/dev/fb0里，早期AndroidStuio中的DDMS工具實現(xiàn)截屏的原理就是直接讀取/dev/fb0設備文件。

我們知道了手機屏幕上的圖形數(shù)據(jù)都存儲在幀緩沖中，所以Android手機圖像界面的原理就是將我們的圖像數(shù)據(jù)寫入到幀緩沖內(nèi)。那么，寫入到幀緩沖的圖像數(shù)據(jù)是怎么生成的，又是怎樣加工的呢？圖形數(shù)據(jù)是怎樣送到幀緩沖去的，中間經(jīng)歷了哪些步驟和過程呢？了解了這幾個問題，我們就了解了Android圖形渲染的原理，那么帶著這幾個疑問，接著往下看。

想要知道圖像數(shù)據(jù)是怎么產(chǎn)生的，我們需要知道 圖像生產(chǎn)者 有哪些，他們分別是如何生成圖像的，想要知道圖像數(shù)據(jù)是怎么被消費的，我們需要知道 圖像消費者 有哪些，他們又分別是如何消費圖像的，想要知道中間經(jīng)歷的步驟和過程，我們需要知道 圖像緩沖區(qū) 有哪些，他們是如何被創(chuàng)建，如何分配存儲空間，又是如何將數(shù)據(jù)從生產(chǎn)者傳遞到消費者的，圖像顯示是一個很經(jīng)典的消費者生產(chǎn)者的模型，只有對這個模型各個模塊的擊破，了解他們之間的流動關系，我們才能找到一條更容易的路徑去掌握Android圖形顯示原理。我們看看谷歌提供的官方的架構圖是怎樣描述這一模型的模塊及關系的。

如圖， 圖像的生產(chǎn)者 主要有MediaPlayer，CameraPrevier，NDK，OpenGl ES。MediaPlayer和Camera Previer是通過直接讀取圖像源來生成圖像數(shù)據(jù)，NDK（Skia），OpenGL ES是通過自身的繪制能力生產(chǎn)的圖像數(shù)據(jù)； 圖像的消費者 有SurfaceFlinger，OpenGL ES Apps，以及HAL中的Hardware Composer。OpenGl ES既可以是圖像的生產(chǎn)者，也可以是圖像的消費者，所以它也放在了圖像消費模塊中； 圖像緩沖區(qū) 主要有Surface以及前面提到幀緩沖。

Android圖像顯示的原理，會僅僅圍繞 圖像的生產(chǎn)者 ， 圖像的消費者 ， 圖像緩沖區(qū) 來展開，在這一篇文章中，我們先看看Android系統(tǒng)中的圖像消費者。

SurfaceFlinger是Android系統(tǒng)中最重要的一個圖像消費者，Activity繪制的界面圖像，都會傳遞到SurfaceFlinger來，SurfaceFlinger的作用主要是接收圖像緩沖區(qū)數(shù)據(jù)，然后交給HWComposer或者OpenGL做合成，合成完成后，SurfaceFlinger會把最終的數(shù)據(jù)提交給幀緩沖。

那么SurfaceFlinger是如何接收圖像緩沖區(qū)的數(shù)據(jù)的呢？我們需要先了解一下Layer（層）的概念，一個Layer包含了一個Surface，一個Surface對應了一塊圖形緩沖區(qū)，而一個界面是由多個Surface組成的，所以他們會一一對應到SurfaceFlinger的Layer中。SurfaceFlinger通過讀取Layer中的緩沖數(shù)據(jù)，就相當于讀取界面上Surface的圖像數(shù)據(jù)。Layer本質上是 Surface和SurfaceControl的組合 ，Surface是圖形生產(chǎn)者和圖像消費之間傳遞數(shù)據(jù)的緩沖區(qū)，SurfaceControl是Surface的控制類。

前面在屏幕圖像顯示原理中講到，為了防止圖像的撕裂，Android系統(tǒng)會在收到VSync垂直同步時才會開始處理圖像的繪制和合成工作，而Surfaceflinger作為一個圖像的消費者，同樣也是遵守這一規(guī)則，所以我們通過源碼來看看SurfaceFlinger是如何在這一規(guī)則下，消費圖像數(shù)據(jù)的。

SurfaceFlinger專門創(chuàng)建了一個EventThread線程用來接收VSync。EventThread通過Socket將VSync信號同步到EventQueue中，而EventQueue又通過回調(diào)的方式，將VSync信號同步到SurfaceFlinger內(nèi)。我們看一下源碼實現(xiàn)。

上面主要是SurfaceFlinger初始化接收VSYNC垂直同步信號的操作，主要有這幾個過程：

經(jīng)過上面幾個步驟，我們接收VSync的初始化工作都準備好了，EventThread也開始運轉了，接著看一下EventThread的運轉函數(shù)threadLoop做的事情。

threadLoop主要是兩件事情

mConditon又是怎么接收VSync的呢？我們來看一下

可以看到，mCondition的VSync信號實際是DispSyncSource通過onVSyncEvent回調(diào)傳入的，但是DispSyncSource的VSync又是怎么接收的呢？在上面講到的SurfaceFlinger的init函數(shù)，在創(chuàng)建EventThread的實現(xiàn)中，我們可以發(fā)現(xiàn)答案—— mPrimaryDispSync 。

DispSyncSource的構造方法傳入了mPrimaryDispSync，mPrimaryDispSync實際是一個DispSyncThread線程，我們看看這個線程的threadLoop方法

DispSyncThread的threadLoop會通過mPeriod來判斷是否進行阻塞或者進行VSync回調(diào)，那么mPeriod又是哪兒被設置的呢？這里又回到SurfaceFlinger了，我們可以發(fā)現(xiàn)在SurfaceFlinger的 resyncToHardwareVsync 函數(shù)中有對mPeriod的賦值。

可以看到，這里最終通過HWComposer，也就是硬件層拿到了period。終于追蹤到了VSync的最終來源了， 它從HWCompser產(chǎn)生，回調(diào)至DispSync線程，然后DispSync線程回調(diào)到DispSyncSource，DispSyncSource又回調(diào)到EventThread，EventThread再通過Socket分發(fā)到MessageQueue中 。

我們已經(jīng)知道了VSync信號來自于HWCompser，但SurfaceFlinger并不會一直監(jiān)聽VSync信號，監(jiān)聽VSync的線程大部分時間都是休眠狀態(tài)，只有需要做合成工作時，才會監(jiān)聽VSync，這樣即保證圖像合成的操作能和VSync保持一致，也節(jié)省了性能。SurfaceFlinger提供了一些主動注冊監(jiān)聽VSync的操作函數(shù)。

可以看到，只有當SurfaceFlinger調(diào)用 signalTransaction 或者 signalLayerUpdate 函數(shù)時，才會注冊監(jiān)聽VSync信號。那么signalTransaction或者signalLayerUpdate什么時候被調(diào)用呢？它可以由圖像的生產(chǎn)者通知調(diào)用，也可以由SurfaceFlinger根據(jù)自己的邏輯來判斷是否調(diào)用。

現(xiàn)在假設App層已經(jīng)生成了我們界面的圖像數(shù)據(jù)，并調(diào)用了 signalTransaction 通知SurfaceFlinger注冊監(jiān)聽VSync，于是VSync信號便會傳遞到了MessageQueue中了，我們接著看看MessageQueue又是怎么處理VSync的吧。

MessageQueue收到VSync信號后，最終回調(diào)到了SurfaceFlinger的 onMessageReceived 中，當SurfaceFlinger接收到VSync后，便開始以一個圖像消費者的角色來處理圖像數(shù)據(jù)了。我們接著看SurfaceFlinger是以什么樣的方式消費圖像數(shù)據(jù)的。

VSync信號最終被SurfaceFlinger的onMessageReceived函數(shù)中的INVALIDATE模塊處理。

INVALIDATE的流程如下：

handleMessageTransaction的處理比較長，處理的事情也比較多，它主要做的事情有這些

handleMessageRefresh函數(shù)，便是SurfaceFlinger真正處理圖層合成的地方，它主要下面五個步驟。

我會詳細介紹每一個步驟的具體操作

合成前預處理會判斷Layer是否發(fā)生變化，當Layer中有新的待處理的Buffer幀（mQueuedFrames0），或者mSidebandStreamChanged發(fā)生了變化， 都表示Layer發(fā)生了變化，如果變化了，就調(diào)用signalLayerUpdate，注冊下一次的VSync信號。如果Layer沒有發(fā)生變化，便只會做這一次的合成工作，不會注冊下一次VSync了。

重建Layer棧會遍歷Layer，計算和存儲每個Layer的臟區(qū)， 然后和當前的顯示設備進行比較，看Layer的臟區(qū)域是否在顯示設備的顯示區(qū)域內(nèi)，如果在顯示區(qū)域內(nèi)的話說明該layer是需要繪制的，則更新到顯示設備的VisibleLayersSortedByZ列表中，等待被合成

rebuildLayerStacks中最重要的一步是 computeVisibleRegions ，也就是對Layer的變化區(qū)域和非透明區(qū)域的計算，為什么要對變化區(qū)域做計算呢？我們先看看SurfaceFlinger對界面顯示區(qū)域的分類：

還是以這張圖做例子，可以看到我們的狀態(tài)欄是半透明的，所以它是一個opaqueRegion區(qū)域，微信界面和虛擬按鍵是完全不透明的，他是一個visibleRegion，除了這三個Layer外，還有一個我們看不到的Layer——壁紙，它被上方visibleRegion遮擋了，所以是coveredRegion

對這幾個區(qū)域的概念清楚了，我們就可以去了解computeVisibleRegions中做的事情了，它主要是這幾步操作：

Flutter面試：渲染原理

頁面中的各界面元素（Widget）以樹的形式組織，即控件樹。Flutter通過控件樹中的每個控件創(chuàng)建不同類型的渲染對象，組成渲染對象樹。而渲染對象樹在Flutter的展示過程分為三個階段：布局、繪制、合成和渲染。

（一）布局

Flutter采用深度優(yōu)先機制遍歷渲染對象樹，決定渲染對象樹中各渲染對象在屏幕上的位置和尺寸。在布局過程中，渲染對象樹中的每個渲染對象都會接收父對象的布局約束參數(shù)，決定自己的大小，然后父對象按照控件邏輯決定各個子對象的位置，完成布局過程。

為了防止因子節(jié)點發(fā)生變化而導致整個控件樹重新布局，F(xiàn)lutter加入了一個機制——布局邊界（Relayout Boundary），可以在某些節(jié)點自動或手動地設置布局邊界，當邊界內(nèi)的任何對象發(fā)生重新布局時，不會影響邊界外的對象，反之亦然。

二）繪制

布局完成后，渲染對象樹中的每個節(jié)點都有了明確的尺寸和位置。Flutter會把所有的渲染對象繪制到不同的圖層上。與布局過程一樣，繪制過程也是深度優(yōu)先遍歷，而且總是先繪制自身，再繪制子節(jié)點。

以下圖為例：節(jié)點1在繪制完自身后，會再繪制節(jié)點2，然后繪制它的子節(jié)點3、4和5，最后繪制節(jié)點6。

可以看到，由于一些其他原因（比如，視圖手動合并）導致2的子節(jié)點5與它的兄弟節(jié)點6處于了同一層，這樣會導致當節(jié)點2需要重繪的時候，與其無關的節(jié)點6也會被重繪，帶來性能損耗。

為了解決這一問題，F(xiàn)lutter提出了與布局邊界對應的機制——重繪邊界（Repaint Boundary）。在重繪邊界內(nèi)，F(xiàn)lutter會強制切換新的圖層，這樣就可以避免邊界內(nèi)外的互相影響，避免無關內(nèi)容置于同一圖層引起不必要的重繪。

重繪邊界的一個典型場景是Scrollview。ScrollView滾動的時候需要刷新視圖內(nèi)容，從而觸發(fā)內(nèi)容重繪。而當滾動內(nèi)容重繪時，一般情況下其他內(nèi)容是不需要重繪的，這時候重繪邊界就派上用場了。

（三）合成和渲染

終端設備的頁面越來越復雜，因此Flutter的渲染樹層級通常很多，直接交付給渲染引擎進行多圖層渲染，可能會出現(xiàn)大量渲染內(nèi)容的重復繪制，所以還需要先進行一次圖層合成，即將所有的圖層根據(jù)大小、層級、透明度等規(guī)則計算出最終的顯示效果，將相同的圖層歸類合并，簡化渲染樹，提高渲染效率。

合并完成后，F(xiàn)lutter會將幾何圖層數(shù)據(jù)交由Skia引擎加工成二維圖像數(shù)據(jù)，最終交由GPU進行渲染，完成界面的展示。

四、總結

咱們從各種業(yè)界主流跨端方案與Flutter的對比開始，到Flutter的簡要介紹以及Flutter的運行機制，并以界面渲染過程為例，從布局、繪制、合成和渲染三個階段講述了Flutter的實現(xiàn)原理。相信大家對Flutter已經(jīng)有一個整體認知，趕快一起上手操作起來吧！

Android 圖形系統(tǒng)（Graphics）

本文將從三個方面介紹Android 圖形系統(tǒng)。

圖形系統(tǒng)提供繪圖和圖形處理支持。

Android 框架提供了各種用于 2D 和 3D 圖形渲染的 API、圖片解碼庫，以及各種Driver支持。

? 繪圖API：2D引擎 Skia，3D引擎 OpenGL ES，RenderScript，OpenCV和Vulkan。

? 圖片解碼庫：jpg，png，gif等。

應用開發(fā)者可通過三種方式將圖像繪制到屏幕:

? Canvas : 2D圖形API，Android View樹實際的繪制者。

? OpenGL ES : 嵌入式設備的OpenGL 三維圖形API子集。

? Vulkan :跨平臺的2D和3D繪圖引擎,Android 7.0后支持，NDK。

整個圖形系統(tǒng)架構是一個生產(chǎn)者和消費者模式，五層依次介紹：

2D繪制：Canvas api / view 的子類 (button ,list)/自定義view

3D繪制：應用直接使用OpenGL 接口繪制圖形(PixelFlinger對應的是openGl 1.0 ，GUP driver 對應的是2.0和3.0)

所有情況下的繪圖都渲染到一個包含 GraphicBuffer的Surface上，當一塊 Surface 顯示在屏幕上時，就是用戶所看到的窗口。

? Canvas：畫布，2D圖形API，Android View樹實際的渲染者。

? Skia繪制：Android4.0之前默認使用，主線程通過CPU完成繪圖指令操作，在復雜場景下單幀容易超過16ms導致卡頓。

WindowManagerService（WMS）窗口管理服務，管理系統(tǒng)中所有的窗口。

? 管理window （view的容器）

? Window與surface對應，一塊顯示區(qū)域。添加一個window，就是 WMS 為其分配一塊 Surface 的過程。

Google 在Android source官網(wǎng)提示：

這里就對這些控件進行簡單介紹：

Surface : Handle onto a raw buffer that is being managed by the screen compositor.

Surface 對應一塊屏幕緩沖區(qū)。生產(chǎn)者是： SurfaceTexture、MediaRecorder 等，消費者是： OpenGL、MediaPlayer 或 CameraDevice等。每個window對應一個Surface。Canvas或OpenGL ES等最終都渲染到Surface上。

? Flutter在Android平臺上也是直接渲染到Surface。例如：一個Activity/Dialog都是一個Surface，它承載了上層的圖形數(shù)據(jù)，與SurfaceFlinger側的Layer相對應。

Canvas（畫布）實現(xiàn)由 Skia 圖形庫提供。為了確保兩個客戶端不會同時更新某個緩沖區(qū)，使用以下命令處理畫布鎖：

使用雙緩沖機制，有自己的 surface，View只是一個透明的占位符，Surface可以在后臺線程中繪制。雙緩沖機制提高渲染效率，獨立線程

繪制，提升流暢性。適合一些場景：需要界面迅速更新、UI繪制時間長、對幀率要求較高的情況。

提供訪問和控制Surface 相關的方法 。通過SurfaceView的getHolder()函數(shù)可以獲取SurfaceHolder對象，Surface 就在SurfaceHolder對象內(nèi)。

addCallback(SurfaceHolder.Callbackcallback) /Canvas lockCanvas() /unlockCanvasAndPost(Canvascanvas)

SurfaceTexture： Surface 和 OpenGL ES (GLES) 紋理（Texture）的組合。將圖像流轉為 OpenGL 外部紋理。

TextureView：持有 SurfaceTexture，將圖像處理為 OpenGL 紋理更新到 HardwareLayer。

GLSurfaceView：加入 EGL 管理，自帶 GL 上下文和 GL 渲染線程

這些View通常涉及到Android音視頻相關，需要高效的渲染能力。如下面的SurfaceTexture在camera中的應用。

簡稱Buffer, 一個Buffer包含一幀圖像，Buffer由gralloc分配和回收。Buffer 屬性包含：width, height, format, usage等

BufferQueue 的引入是為了解決顯示和性能問題。

? Surface屬于APP進程，Layer屬于系統(tǒng)進程，如果它們之間只用一個Buffer，會存在顯示和性能問題。

? 一些Buffer用于繪制，一些Buffer用于顯示，雙方處理完之后，交換一下Buffer，提高效率。

? BufferQueue中包含多個Buffer對象。

Android圖形系統(tǒng)包含了兩對生產(chǎn)者和消費者模型，它們都通過BufferQueue進行連接：

1.Canvas和OpenGL ES生產(chǎn)圖形數(shù)據(jù)，SurfaceFlinger消費圖形數(shù)據(jù)。

2.SurfaceFlinger合成所有圖層的圖形數(shù)據(jù)，Display顯示合成結果。

code：frameworks/native/services/surfaceflinger

? Surface表示APP進程的一個窗口，承載了窗口的圖形數(shù)據(jù)。

? SurfaceFlinger是系統(tǒng)進程合成所有窗口的系統(tǒng)服務，負責合成所有Surface提供的圖形數(shù)據(jù)，然后送顯到屏幕。

? SurfaceFlinger既是上層應用的消費者，又是Display的生產(chǎn)者，起到了承上啟下的作用。

數(shù)據(jù)流：

合成示意圖：

在介紹Vsync機制之前先介紹兩個重要概念：

屏幕刷新率：屏幕每秒鐘可以刷新多少次。60HZ刷新率，16.7ms刷新一次。（120HZ/8.3ms），硬件指標。

GPU 繪制幀率：GPU 每秒能夠合成繪制多少幀。

軟件層觸發(fā) View 繪制的時機是隨機的，當下一次屏幕刷新時，屏幕從 Frame Buffer 中拿到的數(shù)據(jù)還是“幀1”的數(shù)據(jù)，導致“丟幀”。

每隔 16ms 硬件層發(fā)出 vsync 信號，應用層接收到此信號后會觸發(fā)UI 的渲染流程，同時 vsync 信號也會觸發(fā) SurfaceFlinger 讀取Buffer 中的數(shù)據(jù)，進行合成顯示到屏幕上。

總結：Vsync機制將 CPU 和 GPU 的開始時間與屏幕刷新強行拖拽到同一起跑線

Android提供的Graphics流程相對比較復雜對其進行具象后的流程如下兩張圖所示：

文章題目：flutter圖層,flutter繪圖
轉載來源：http://chinadenli.net/article15/dsgjddi.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供搜索引擎優(yōu)化、靜態(tài)網(wǎng)站、面包屑導航、品牌網(wǎng)站設計、網(wǎng)站排名、品牌網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)