flutter做壁紙,flutter設置背景圖片

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ū)，于是，圖形就在我們的屏幕顯示出來了。

創(chuàng)新互聯(lián)公司服務項目包括武都網(wǎng)站建設、武都網(wǎng)站制作、武都網(wǎng)頁制作以及武都網(wǎng)絡營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關系等，向廣大中小型企業(yè)、政府機構等提供互聯(lián)網(wǎng)行業(yè)的解決方案，武都網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務的客戶以成都為中心已經(jīng)輻射到武都省份的部分城市，未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任！

但我們所知道的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)绾问褂?，以及他們在Android中的使用場景，如開機動畫，Activity界面的軟件繪制和硬件繪制，以及Flutter的界面繪制。那么，我們開始對Android圖像顯示原理的探索吧。

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

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

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

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

實際上顯卡驅(qū)動，顯卡和顯存，包括數(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本質(zhì)上是 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中做的事情了，它主要是這幾步操作：

程序員的開源月刊《HelloGitHub》第 68 期

HelloGitHub 分享 GitHub 上有趣、入門級的開源項目。

這里有實戰(zhàn)項目、入門教程、黑 科技 、開源書籍、大廠開源項目等，涵蓋多種編程語言 Python、Java、Go、C/C++、Swift...讓你在短時間內(nèi)感受到開源的魅力，對編程產(chǎn)生興趣！

1、 toybox ：該項目將 200 多個常用的 Linux 命令行工具，做成一個可執(zhí)行文件。從而可以讓 Android 這種原本不支持 Linux 命令的系統(tǒng)，也得以用上 ls、find、ps 等命令。還可以用于快速構建最小的 Linux 環(huán)境

2、 the_silver_searcher ：比 ack 更快的命令行搜索工具。速度快、功能強大、使用簡單，支持 Linux、Windows、macOS 操作系統(tǒng)，還能夠整合進 Vim 和 Emacs 等編輯器

3、 WindTerm ：支持 SSH/Telnet/Serial/Shell/Sftp 的終端工具。雖然該軟件完全免費，但部分代碼尚未完全開源，對安全敏感的同學可以再觀望下

4、 wavefunctioncollapse ：基于波函數(shù)坍縮 (WFC) 算法，實現(xiàn)的無限城市示例。城市里有房子、樓梯、樹木、連接房屋的通道，你可以在城市中自由移動、跳躍、飛行，但不論你怎么移動都找不到盡頭，因為這座城市會無限延伸

5、 NETworkManager ：管理和解決網(wǎng)絡問題的工具。它集成了 IP 和端口掃描、WiFi 分析器、跟蹤路由、DNS 查詢等工具

6、 ppsspp ：能夠運行在 Android 和 PC 上的開源 PSP 模擬器

7、 leocad ：用來創(chuàng)建虛擬樂高模型的 CAD 工具。適用于 Windows、Linux 和 macOS 系統(tǒng)

8、 csshake ：用 CSS 實現(xiàn)抖動效果

9、 MangoDB ：真正開源的 MongoDB 替代品。它底層采用 PostgreSQL 作為存儲引擎，用 Go 語言實現(xiàn)了 MongoDB 協(xié)議，所以幾乎兼容所有的 MongoDB 庫，遷移起來毫無負擔。如果你用不到 MongoDB 的高級功能，還受限于它的開源協(xié)議，那么這個項目可作為 MongoDB 的開源替代方案。它才剛剛起步，建議觀望一段時間或做足測試再用于生產(chǎn)環(huán)境

10、 caddy ：用 Go 編寫的輕量級 Web 服務器。它相較于 Apache、Nginx 這些知名 Web 服務器，獨特點在于提供了編譯好的可執(zhí)行文件，實現(xiàn)了真正的開箱即用。無需任何配置即可擁有免費的 HTTPS、自動把 Markdown 文件轉化成 HTML 等人性化的功能。如果是搭建中小型的 Web 服務，它完全夠用而且省時省心

11、 croc ：可以讓任意兩臺計算機，安全方便地傳輸文件和文件夾的工具。輕松實現(xiàn)端到端加密的跨平臺文件傳輸，還支持多文件傳輸、傳輸中斷和恢復等功能

12、 jnativehook ：獲取鍵盤和鼠標事件的 Java 庫。輕松監(jiān)聽按鍵、鼠標移動、點擊等事件

13、 spider-flow ：用流程圖的方式編寫爬蟲的平臺。無需寫代碼就可以快速完成一個簡單的爬蟲

14、 greenDAO ：高性能的 Android ORM 庫。擁有體積小、易于使用、支持數(shù)據(jù)庫加密等特點，通過它 Android 開發(fā)者可以采用面向?qū)ο蟮姆绞讲僮鲾?shù)據(jù)庫，不需要再手寫和拼接 SQL 啦

15、 vue-color-avatar ：純前端實現(xiàn)的矢量風格頭像生成網(wǎng)站?？梢酝ㄟ^搭配不同的素材，生成個性化頭像。該項目使用 Vite + Vue3 開發(fā)，能夠幫助前端初學者熟悉 Vue3 語法并掌握項目搭建的相關知識

16、 colorfu ：自動生成由文字/顏色/圖片/紋理元素組成的壁紙

17、 pm2 ：Node.js 的進程管理工具。它容易上手操作簡單，可以有效地提高 Node.js 程序運行的穩(wěn)定性，支持自動重啟、負載均衡、不停服務重啟、性能監(jiān)控等功能，多用于生產(chǎn)環(huán)境中管理、監(jiān)控 Node.js 進程

18、 automa ：通過圖形化界面拖拽功能模塊，實現(xiàn)瀏覽器自動操作的擴展工具。輕松實現(xiàn)自動填表、截圖、定時執(zhí)行等操作。讓瀏覽器自動完成預設工作流的插件，從而減少重復性操作提高效率

19、 PyWebIO ：快速構建 Web 應用的 Python 工具。通過該項目你可在不寫 HTML、CSS、JS 代碼的前提下，僅用 Python 快速完成一個包含數(shù)據(jù)展示、表單的小型 Web 應用頁面

20、 pottery ：以 Python 的方式操作 Redis 的庫。忘記那些 Redis 命令吧，只要你知道如何使用 Python 字典，那么你就會用這個庫操作 Redis

21、 zulip ：完全開源的企業(yè)級即時通訊項目。后端采用 Python 語言實現(xiàn)性能足夠強大，功能齊全相當于開源、免費的 Slack，擁有拖拽上傳文件、代碼高亮、Markdown 語法、應用整合、容易接入的 API 等功能，還支持 Web、PC、iOS 和 Android 主流平臺，眾多知名企業(yè)都在用，能夠有效地提高團隊溝通和辦公效率。同時該項目對新手用戶友好，如果你想加入一個不錯的 Python 開源項目，推薦你花時間研究下它一定會有所收獲

22、 webssh ：簡單的 SSH 連接服務器的 Python Web 應用。該項目后端采用 Tornado Web 框架和 Python SSH 庫 paramiko，前端是 TypeScript 寫的命令行前端組件 Xterm.js 實現(xiàn)。整個項目簡單還具有實用價值，可作為 Python Web 的實戰(zhàn)項目學習

23、 django-debug-toolbar ：Django 的調(diào)試工具欄?？娠@示當前請求和響應有關的各種調(diào)試信息，包括耗時、SQL、配置、性能等信息

24、 hyperfine ：命令行基準測試工具?？捎脕聿榭春蛯Ρ让畹暮臅r，支持多次運行的統(tǒng)計分析、結果導出等功能

25、 xcode-dev-cleaner ：用于清理各種 Xcode 的緩存數(shù)據(jù)，釋放存儲空間。注意是清除 Xcode 緩存數(shù)據(jù)，不是卸載 Xcode 哈

26、 toml ：更易讀和易于維護的配置文件格式。如果你厭倦了 INI 的局限性、層層嵌套的 JSON 和 YAML 令人心驚膽戰(zhàn)的縮進語法，不防給 TOML 一個機會，它支持多種數(shù)據(jù)類型、拋棄了縮進和嵌套，而且眾多流行編程語言都有對應的庫。TOML 已經(jīng)足夠成熟，絕對值得一試

27、 waka-readme-stats ：自動在 GitHub 個人首頁展示編程時長的工具。該項目通過 WakaTime 記錄用戶在 IDE 的使用時間，統(tǒng)計編程時長和數(shù)據(jù)，然后采用 GitHub Action 自動獲取并動態(tài)更新到 GitHub 個人首頁。輕而易舉地展示自己的編程時長

28、 PathPlanning ：常見的路徑規(guī)劃算法集合。項目包含了 Python 代碼實現(xiàn)、運行過程動畫以及相關論文

29、 howdy ：為 Linux 系統(tǒng)提供人臉識別解鎖電腦的工具。通過電腦內(nèi)置的攝像頭和紅外設備，實現(xiàn)了類似 Windows Hello 風格的身份認證，可用于登陸、鎖屏、sudo 等任何需要輸入密碼的地方

30、 The-Open-Book ：開源的電子水墨屏閱讀設備。動手能力強的同學可跟著這個項目，從焊電路板開始親手制作出一個類 Kindle 的 4.2 英寸閱讀設備

31、 fl_chart ：Flutter 圖表庫。它支持折線圖、條形圖、餅圖、散點圖和雷達圖

32、 ugo-compiler-book ：《從頭開發(fā)一個迷你 Go 語言》該書教你從頭實現(xiàn)迷你 Go 語言，內(nèi)容包含了詞法解析、語法樹構建、函數(shù)閉包、接口、CGO 的實現(xiàn)等內(nèi)容

33、 archbase ：教科書《計算機體系結構基礎》第三版

34、 spring-in-action-v6-translate ：《Spring 實戰(zhàn)第 6 版》中文翻譯

35、 best_AI_papers_2021 ：2021 年必看的人工智能論文列表。該項目不是簡單的羅列論文，它不僅包含相關論文的代碼、效果展示，還有深入的文章和講解視頻。通過學習這些前沿的人工智能論文，提前了解 AI 在未來更多可能性

36、 AnimeGANv2 ：可以將圖片和視頻轉換成漫畫風格的工具。采用的是神經(jīng)風格遷移+生成對抗網(wǎng)絡（GAN）的組合，轉換速度快

感謝您的閱讀，如果覺得內(nèi)容還不錯的話 求贊、求分享 ，您的每一次支持都將讓 HelloGitHub 變得更好！

flutter中的controller是做什么的？

用來控制controller對應widget的各種各樣交互行為以及狀態(tài)變化的控制（類似于widget本身只是一個靜態(tài)的物品，而通過對controller的操作控制讓這個widget活了起來）

Flutter 啟動頁的前世今生適配歷程

APP 啟動頁在國內(nèi)是最常見也是必備的場景，其中啟動頁在 iOS 上算是強制性的要求，其實配置啟動頁挺簡單，因為在 Flutter 里現(xiàn)在只需要：

一般只要配置無誤并且圖片尺寸匹配，基本上就不會有什么問題， 那既然這樣，還有什么需要適配的呢？

事實上大部分時候 iOS 是不會有什么問題， 因為 LaunchScreen.storyboard 的流程本就是 iOS 官方用來做應用啟動的過渡；而對于 Andorid 而言，直到 12 之前 windowBackground 這種其實只能算“民間”野路子 ，所以對于 Andorid 來說，這其中就涉及到一個點：

所以下面主要介紹 Flutter 在 Android 上為了這個啟動圖做了哪些騷操作～

在已經(jīng)忘記版本的“遠古時期” ， FlutterActivity 還在 io.flutter.app.FlutterActivity 路徑下的時候，那時啟動頁的邏輯相對簡單，主要是通過 App 的 AndroidManifest 文件里是否配置了 SplashScreenUntilFirstFrame 來進行判斷。

在 FlutterActivity 內(nèi)部 FlutterView 被創(chuàng)建的時候，會通過讀取 meta-data 來判斷是否需要使用 createLaunchView 邏輯 ：

是不是很簡單，那就會有人疑問為什么要這樣做？我直接配置 Activity 的 android:windowBackground 不就完成了嗎？

這就是上面提到的時間差問題， 因為啟動頁到 Flutter 渲染完第一幀畫面中間，會出現(xiàn)概率出現(xiàn)黑屏的情況，所以才需要這個行為來實現(xiàn)過渡 。

經(jīng)歷了“遠古時代”之后， FlutterActivity 來到了 io.flutter.embedding.android.FlutterActivity ， 在到 2.5 版本發(fā)布之前，F(xiàn)lutter 又針對這個啟動過程做了不少調(diào)整和優(yōu)化，其中主要就是 SplashScreen 。

自從開始進入 embedding 階段后， FlutterActivity 主要用于實現(xiàn)了一個叫 Host 的 interface ，其中和我們有關系的就是 provideSplashScreen 。

默認情況下它會從 AndroidManifest 文件里是否配置了 SplashScreenDrawable 來進行判斷 。

默認情況下當 AndroidManifest 文件里配置了 SplashScreenDrawable ，那么這個 Drawable 就會在 FlutterActivity 創(chuàng)建 FlutterView 時被構建成 DrawableSplashScreen 。

DrawableSplashScreen 其實就是一個實現(xiàn)了 io.flutter.embedding.android.SplashScreen 接口的類，它的作用就是：

之后 FlutterActivity 內(nèi)會創(chuàng)建出 FlutterSplashView ，它是個 FrameLayout。

FlutterSplashView 將 FlutterView 和 ImageView 添加到一起， 然后通過 transitionToFlutter 的方法來執(zhí)行動畫，最后動畫結束時通過 onTransitionComplete 移除 splashScreenView 。

所以整體邏輯就是：

當然這里也是分狀態(tài)：

當然這個階段的 FlutterActivity 也可以通過 override provideSplashScreen 方法來自定義 SplashScreen 。

看到?jīng)]有，做了這么多其實也就是為了彌補啟動頁和 Flutter 渲染之間， 另外還有一個優(yōu)化，叫 NormalTheme 。

通過該配置 NormalTheme ，在 Activity 啟動時，就會首先執(zhí)行 switchLaunchThemeForNormalTheme(); 方法將主題從 LaunchTheme 切換到 NormalTheme 。

大概配置完就是如下樣子， 前面分析那么多其實就是為了告訴你，如果出現(xiàn)問題了，你可以從哪個地方去找到對應的點 。

講了那么多， Flutter 2.5 之后 provideSplashScreen 和 io.flutter.embedding.android.SplashScreenDrawable 就被棄用了，驚不喜驚喜，意不意外，開不開心 ？

通過源碼你會發(fā)現(xiàn)，當你設置了 splashScreen 的時候，會看到一個 log 警告：

為什么會棄用？

其實這個提議是在 這個 issue 上，然后通過 這個 pr 完成調(diào)整。

大概意思就是： 原本的設計搞復雜了，用 OnPreDrawListener 更精準，而且不需要為了后面 Andorid12 的啟動支持做其他兼容，只需要給 FlutterActivity 等類增加接口開關即可 。

也就是2.5之后 Flutter 使用 ViewTreeObserver.OnPreDrawListener 來實現(xiàn)延遲直到加載出 Flutter 的第一幀。

為什么說默認情況？ 因為這個行為在 FlutterActivity 里，是在 getRenderMode() == RenderMode.surface 才會被調(diào)用，而 RenderMode 又和 BackgroundMode 有關心 。

所以在 2.5 版本后， FlutterActivity 內(nèi)部創(chuàng)建完 FlutterView 后就會執(zhí)行一個 delayFirstAndroidViewDraw 的操作。

這里主要注意一個參數(shù)： isFlutterUiDisplayed 。

當 Flutter 被完成展示的時候， isFlutterUiDisplayed 就會被設置為 true。

所以當 Flutter 沒有執(zhí)行完成之前， FlutterView 的 onPreDraw 就會一直返回 false ，這也是 Flutter 2.5 開始之后適配啟動頁的新調(diào)整。

看了這么多，大概可以看到其實開源項目的推進并不是一帆風順的，沒有什么是一開始就是最優(yōu)解，而是經(jīng)過多方嘗試和交流，才有了現(xiàn)在的版本，事實上開源項目里，類似這樣的經(jīng)歷數(shù)不勝數(shù)：

25.Flutter的ListView監(jiān)聽滾動事件之ScrollController

對于滾動的視圖，我們經(jīng)常需要監(jiān)聽它的一些滾動事件，在監(jiān)聽到的時候去做對應的一些事情。

比如視圖滾動到底部時，我們可能希望做上拉加載更多；

比如滾動到一定位置時顯示一個回到頂部的按鈕，點擊回到頂部的按鈕，回到頂部；

比如監(jiān)聽滾動什么時候開始，什么時候結束；

在Flutter中監(jiān)聽滾動相關的內(nèi)容由兩部分組成：ScrollController和ScrollNotification。

ScrollController

在Flutter中，Widget并不是最終渲染到屏幕上的元素（真正渲染的是RenderObject），因此通常這種監(jiān)聽事件以及相關的信息并不能直接從Widget中獲取，而是必須通過對應的Widget的Controller來實現(xiàn)。

ListView、GridView的組件控制器是ScrollController，我們可以通過它來獲取視圖的滾動信息，并且可以調(diào)用里面的方法來更新視圖的滾動位置。

另外，通常情況下，我們會根據(jù)滾動的位置來改變一些Widget的狀態(tài)信息，所以ScrollController通常會和StatefulWidget一起來使用，并且會在其中控制它的初始化、監(jiān)聽、銷毀等事件。

我們來做一個案例，當滾動到1000位置的時候，顯示一個回到頂部的按鈕：

jumpTo(double offset)、animateTo(double offset,...)：這兩個方法用于跳轉到指定的位置，它們不同之處在于，后者在跳轉時會執(zhí)行一個動畫，而前者不會。

ScrollController間接繼承自Listenable，我們可以根據(jù)ScrollController來監(jiān)聽滾動事件。

當前文章：flutter做壁紙,flutter設置背景圖片
轉載來源：http://muchs.cn/article0/phghoo.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供動態(tài)網(wǎng)站、商城網(wǎng)站、關鍵詞優(yōu)化、用戶體驗、品牌網(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)