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

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

創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),淮安企業(yè)網(wǎng)站建設(shè),淮安品牌網(wǎng)站建設(shè),網(wǎng)站定制,淮安網(wǎng)站建設(shè)報價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,淮安網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力。可充分滿足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學習、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。

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

事實上大部分時候 iOS 是不會有什么問題， 因為 LaunchScreen.storyboard 的流程本就是 iOS 官方用來做應(yīng)用啟動的過渡；而對于 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 ，其中和我們有關(guān)系的就是 provideSplashScreen 。

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

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

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

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

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

所以整體邏輯就是：

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

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

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

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

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

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

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

為什么會棄用？

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

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

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

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

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

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

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

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

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

Flutter 深色（暗黑）模式下 狀態(tài)欄字體顏色為白色

brightness: Brightness.light,（黑色）

brightness: Brightness.dark,（白色）

這種設(shè)置狀態(tài)欄字體顏色的方法僅在手機淺色模式下有效，當用戶選擇深色（暗黑）模式后，該方法失效，狀態(tài)欄字體顏色統(tǒng)一變?yōu)榘咨豢筛摹?/p>

Flutter 上字體的另類玩法：FontFeature

在以前的 《Flutter 上默認的文本和字體知識點》 和 《帶你深入理解 Flutter 中的字體“冷”知識》 中，已經(jīng)介紹了很多 Flutter 上關(guān)于字體有趣的知識點，而本篇講繼續(xù)介紹 Flutter 上關(guān)于 Text 的一個屬性： FontFeature ， 事實上相較于 Flutter ，本篇內(nèi)容可能和前端或者設(shè)計關(guān)系更密切 。

什么是 FontFeature ？ 簡單來說就是影響字體形狀的一個屬性 ，在前端的對應(yīng)領(lǐng)域里應(yīng)該是 font-feature-settings ，它有別于 FontFamily ，是用于指定字體內(nèi)字的形狀的一個參數(shù)。

我們知道 Flutter 默認在 Android 上使用的是 Roboto 字體，而在 iOS 上使用的是 SF 字體，但是其實 Roboto 字體也是分很多類型的，比如你去查閱手機的 system/fonts 目錄，就會發(fā)現(xiàn)很多帶有 Roboto 字樣的字體庫存在。

所以 Roboto 之類的字體庫是一個很大的字體集，不同的 font-weight 其實對應(yīng)著不同的 ttf ，例如默認情況下的 Roboto 是不支持 font-weight 為 600 的配置 ：

所以如下圖所示，如果我們設(shè)置了 w400 - w700 的 weight ，可以很明顯看到中間的 500 和 600 其實是一樣的粗細，所以在 設(shè)置 weight 或者設(shè)計 UI 時，就需要考慮不同平臺上的 weight 是否支持想要的效果 。

回歸到 FontFeature 上，那 Roboto 自己默認支持多少種 features 呢？ 答案是 26 種，它們的編碼如下所示，運行后效果也如下圖所示，從日常使用上看，這 26 種 Feature 基本滿足開發(fā)的大部分需求。

而 iOS 上的 SF pro 默認支持 39 種 Features ， 它們的編碼如下所示，運行后效果也如下圖所示，可以看到 SF pro 支持的 Features 更多。

所以可以看到，并不是所有字體支持的 Features 都是一樣的，比如 iOS 上支持 sups 上標顯示和 subs 下標顯示，但是 Android 上的 Roboto 并不支持，甚至很多第三方字體其實并不支持 Features 。

有趣的是，在 Flutter Web 有一個渲染文本時會變模糊的問題 #58159 ，這個問題目前官方還沒有修復，但是你可以通過給 Text 設(shè)置任意 FontFeatures 來解決這個問題。

最后，如果對 FontFeature 還感興趣的朋友，可以通過一下資料深入了解，如果你還有什么關(guān)于字體上的問題，歡迎留言討論。

基于網(wǎng)友的問題再補充一下拓展知識，畢竟這方面內(nèi)容也不多 。

事實上在 dart 里就可以看到對應(yīng) FontWeight 約定俗稱用的是字體集里的什么字體：

所以如果對于默認字體有疑問，可以在你的手機字體找找是否有對應(yīng)的字體， 比如雖然我們說 roboto 沒有 600 ，但是如果是 roboto mono 字體集是有 600 的 fontweight ，甚至還有 600 斜體： 。

另外注意這是 Flutter 而不是原生，具體實現(xiàn)調(diào)用是在 Engine 的 paragraph_skia.cc 和 paragraph_builder_skia.cc 下對應(yīng)的 setFontFamilies 相關(guān)邏輯，當然默認字體庫指定在 typography.dart 下就看到，例如 'Roboto' 、 '.SF UI Display' 、 '.SF UI Text' 、 '.AppleSystemUIFont' 、 'Segoe UI' ：

另外如果你在 Mac 的 Web 上使用 Flutter Web，可以看到指定的是 .AppleSystemUIFont ，而對于 .AppleSystemUIFont 它其實不算是一種字體，而是蘋果上字體的一種集合別稱：

[圖片上傳失敗...(image-40f5ce-1648368234737)]

還有，如果你去看 Flutter 默認自帶的 cupertino/context_menu_action.dart ，就可以看到一個有趣的情況：

當然，前面我們說了那么多，主要是針對英文的情況下，而在中文下還是有差異的 ，之前的文章也介紹過：

例如，在蘋果上的簡體中文其實會是 PingFang SC 字體，對應(yīng)還有 PingFang TC 和 PingFang HK 的繁體集，而關(guān)于這個問題在 Flutter 上之前還出現(xiàn)過比較有意思的 bug ：

當然后續(xù)的 #16709 修復了這個問題 ，而在以前的文章我也講過，當時我遇到了 “Flutter 在 iOS 系統(tǒng)上，系統(tǒng)語言是韓文時，在和中文一起出現(xiàn)會導致字體顯示異常" 的問題 ：

解決方法也很簡單，就是給 fontFamilyFallback 配置上 ["PingFang SC" , "Heiti SC"] 就可以了，這是因為韓文在蘋果手機上使用的應(yīng)該是 Apple SD Gothic Neo 這樣的超集字體庫，【廣】這個字符在這個字體集上是不存在的，所以就變成了中文的【廣】；

所以可以看到，字體相關(guān)是一個平時很少會深入接觸的東西，但是一旦涉及多語言和繪制，就很容易碰到問題的領(lǐng)域 。

Flutter開發(fā)--如何布局？

相對于iOS開發(fā)，F(xiàn)lutter的布局更具有靈活性，每個頁面設(shè)計都不一樣，相同頁面可選擇的布局方式也不一樣，如果單純的說應(yīng)該如何去布局，我覺得不現(xiàn)實，大家可以參考下 Flutter官方的布局教程 。接下來，筆者，通過項目中的一個頁面，來一步一步的拆解布局的流程。整個過程，基本上按照拆解、組件封裝、具體布局這三步來的。

根據(jù)設(shè)計圖，可以看出整體可以分成兩部分，上面一部分是系統(tǒng)介紹模塊，下面一部分是真正的登錄內(nèi)容，因為涉及到疊加，因此考慮用Stack；

系統(tǒng)介紹模塊部分：整體也是涉及到疊加，考慮用Stack，分為四部分。最底部漸變色背景用一個contanier，無須指定位置，全視圖擴展；載放logo圖標在上一層，用Image。最后兩個Text同級放在最上層。Image，Text各用Positioned包裹去指定位置。

登錄內(nèi)容模塊是最外層是一個Contanier容器，去控制背景色和圓角。然后是一個Column元素，逐行排列。

第一行為Image，

第二行為Text，

第三行可以看成一個小Column，分兩塊進行布局

第四行可以看成一個小Column，分兩塊進行布局

第五行可以看作一個TextButton，

第六行可以看作一個Row，分三塊進行布局

通過上面這樣一步一步的分析后，基本上對大致的布局有了一個了解，最外層的控件大致選對（只要能實現(xiàn)的話，就是復雜度以及效率的問題），然后一步一步的拆解每一行的元素，如果有重復的或者覺得可以封裝出來的部分，則進行下一步。

每一行的拆解，大致也是按照這個思路來進行，因此筆者在這里就不做講解了。

在做到第三第四行的時候，發(fā)現(xiàn)這兩個很相似，而且設(shè)計到一些交互邏輯，筆者就想對第三第四行的這種展示進行封裝，覺得今后的布局可能會用到，因此在這一步，可以先把這一塊兒抽離出一個控件。利用TextField來實現(xiàn)這種輸入操作，具體的實現(xiàn)筆者不再詳細的描述了。

經(jīng)過這一步，整體的規(guī)劃設(shè)計圖已經(jīng)有了，各個組件也都有了，接下來的工作就是組裝了。

具體布局設(shè)計到一些細節(jié)的地方，例如整體Column的居中對齊（crossAxisAlignment）、間隔（Padding或Container包裹，筆者更喜歡用SizedBox占位）、居左居右居中（Align）、點擊事件（GestureDetector）以及圓角（BorderRadius）等一些特殊情況。

像第六行row是放在底部的，就可以在第六行前面增加一個Spacer()去填充空白區(qū)域。

對文字顏色大小等，可以用TextStyle直接設(shè)置。

對于輸入框的刪除按鈕，可以用Offstage這種Flutter特有的控制顯示隱藏的控件。

當前題目：flutter深色設(shè)計,flutter 顏色
地址分享：http://chinadenli.net/article18/dsgpcdp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App開發(fā)、網(wǎng)站策劃、域名注冊、網(wǎng)站導航、虛擬主機、軟件開發(fā)

廣告

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