出現(xiàn)此情況的原因有兩種
創(chuàng)新互聯(lián)主營茂名網(wǎng)站建設的網(wǎng)絡公司,主營網(wǎng)站建設方案,重慶APP開發(fā),茂名h5微信小程序開發(fā)搭建,茂名網(wǎng)站營銷推廣歡迎茂名等地區(qū)企業(yè)咨詢
解決:
找到 \app\src\main\res\drawable\launch_background.xml 文件，這個里面初始化了布局標簽,只需要把圖片替換為我們自己的就可以。
或者根據(jù)不同手機的分辨率 在mipmap下放置圖片例如：
之后前往 styles.xml 文件設置啟動頁
重新打包就可以看到 剛剛設置的啟動頁了
效果例如：
[圖片上傳失敗...(image-7e5c2-1586668143446)]
至此可以流暢的打開啟動頁了
谷歌將在主題演講環(huán)節(jié)概述接下來一年為Android、谷歌助理（Google Assistant）以及其他眾多應用和服務推出的大量功能和改進。今年稍有不同，因為谷歌幾乎肯定會在主題演講中發(fā)布兩款新Pixel智能機，恰好在典型的智能機更新周期中增加一個更低成本的選項。谷歌還會在這個主題演講過程中公布大量AI改進、機器學習甚至出色的搜索技術。
中端手機Pixel 3A和Pixel 3A XL。本周以前，已經(jīng)有大量Pixel 3A、Pixel 3A XL的信息泄露，但是最后一波曝光基本確認了谷歌即將發(fā)布的新中端Pixel手機的所有信息，包括售價。Pixel 3A的起售價據(jù)稱為399美元，6英寸更大版Pixel 3A XL起售價為479美元。兩款新手機預計能夠以遠遠更低的價格提供比肩旗艦版Pixel 3的相機性能。谷歌在其它手機部分降低了成本，包括采用性能更低的處理器、手機材質從玻璃轉為塑料，去除無線充電功能。不過，新Pixel手機將重新配備耳機插口。
這是谷歌這些年來在手機定價上最為激進的一次，價格甚至低于一加手機，旨在打造一款年中熱門手機。Pixel 3A、Pixel 3A XL將分別獲得三年的系統(tǒng)和安全更新支持，并增加了Call Screen代接電話等功能。更全面預覽Android Q系統(tǒng)
谷歌已經(jīng)發(fā)布了幾個Android Q測試版本，但非常有可能把一些更為重大的功能留在I/O開發(fā)者大會的舞臺上宣布。作為下一個Android重大版本，Android Q將為用戶提供更為靈活的隱私控制，包括把應用追蹤用戶位置的能力限制在它們被活躍使用時。谷歌已經(jīng)在早期測試版本中增加了暗黑模式、色彩主題以及反應遠遠更快的共享菜單。Android Q還將為可折疊手機的未來奠定基礎。
谷歌似乎還在修復Pixel手機的手勢導航功能，甚至有跡象顯示谷歌會在你的手機插入外置顯示器后提供類似于三星DeX功能的PC模式。當然，Android Q的最終版本還包括更多功能。谷歌很可能會在今年夏季末向消費者推送Android Q更新。谷歌應該會在下周二公布更多信息，也有可能發(fā)布新的測試版本。
智能家居新品Nest Hub Max谷歌已經(jīng)在其Home Hub智能顯示器頁面上提前曝光了一款尺寸更大、使用Nest品牌的新產(chǎn)品。Nest Hub Max搭載10英寸顯示屏，內(nèi)置立體聲揚聲器。此外，它將運行與Home Hub一樣的系統(tǒng)，主打谷歌助理，提供可視化界面。它的售價目前還不清楚，但是7英寸Home Hub的售價為150美元。作為一款內(nèi)置相機的Nest品牌產(chǎn)品，它還非常有可能增加Home Hub所不具備的家居安全功能，因為后者并未配備相機。智能顯示器加智能相機聽起來非常不錯。
源碼分析：
分析源碼可得，TextField 是有狀態(tài) StatefulWidget，有豐富的屬性，自定義化較高，實踐中需要合理利用各種回調(diào)；
1、光標的相關屬性；cursorColor 為光標顏色，cursorWidth 為光標寬度，cursorRadius 為光標圓角；其中 Radius 提供了 circle 圓角和 elliptical 非圓角兩種；
2、textAlign 為文字起始位置，可根據(jù)業(yè)務光標居左/居右/居中等；注意只是文字開始方向；textDirection 問文字內(nèi)容方向，從左向右或從右向左；
3、maxLength 為字符長度，設置時默認是展示一行，且右下角有編輯長度與整體長度對比；與 maxLengthEnforced 配合，maxLengthEnforced 為 true 時達到最大字符長度后不可編輯；為 false 時可繼續(xù)編輯展示有差別；
4、設置 maxLength 之后右下角默認有字符計數(shù)器，設置 TextField.noMaxLength 即可只展示輸入字符數(shù)；
5、maxLines 為允許展現(xiàn)的最大行數(shù)，在使用 maxLength 時內(nèi)容超過一行不會自動換行，因為默認 maxLines=1，此時設置為 null 或固定展示行數(shù)即可自動換行；區(qū)別在于 null 會展示多行，而 maxLines 最多只展示到設置行數(shù)；
6、obscureText 是否隱藏編輯內(nèi)容，常見的密碼格式；
7、enableInteractiveSelection 長按是否出現(xiàn)【剪切/復制/粘貼】菜單；不可為空；
8、keyboardAppearance 為鍵盤亮度，包括 Brightness.dark/light 兩種，但僅限于 iOS 設備；
9、textCapitalization 文字大小寫；理論上 sentences 為每句話第一個字母大寫；characters為每個字母大寫；words 為每個單詞首字母大寫；但該屬性僅限于 text keybord，和尚在本地更換多種方式并未實現(xiàn)，有待研究；
10、keyboardType 為鍵盤類型，和尚理解整體分為數(shù)字鍵盤和字母鍵盤等；根據(jù)設置的鍵盤類型，鍵盤會有差別；
a. 數(shù)字鍵盤
--1-- datetime 鍵盤上可隨時訪問 : 和 /；
--2-- phone 鍵盤上可隨時訪問 # 和 *；
--3-- number 鍵盤上可隨時訪問 + - * /
b. 字母鍵盤
--1-- emailAddress 鍵盤上可隨時訪問 @ 和 .；
--2-- url 鍵盤上可隨時訪問 / 和 .；
--3-- multiline 適用于多行文本換行；
--4-- text 默認字母鍵盤；
11、textInputAction 通常為鍵盤右下角操作類型，類型眾多，建議多多嘗試；
12、autofocus 是否自動獲取焦點，進入頁面優(yōu)先獲取焦點，并彈出鍵盤，若頁面中有多個 TextField 設置 autofocus 為 true 則優(yōu)先獲取第一個焦點；
13、focusNode 手動獲取焦點，可配合鍵盤輸入等減少用戶操作次數(shù)，直接獲取下一個 TextField 焦點；
14、enabled 設為 false 之后 TextField 為不可編輯狀態(tài)；
15、decoration 為邊框修飾，可以借此來調(diào)整 TextField 展示效果；可以設置前置圖標，后置圖片，邊框屬性，內(nèi)容屬性等，會在后續(xù)集中嘗試；若要完全刪除裝飾，將 decoration 設置為空即可；
16、inputFormatters 為格式驗證，例如原生 Android 中通常會限制輸入手機號或其他特殊字符，在 Flutter 中也可以借此來進行格式限制，包括正則表達式；使用時需要引入 package:flutter/services.dart；
a. LengthLimitingTextInputFormatter 限制最長字符；
b. WhitelistingTextInputFormatter 僅允許輸入白名單中字符；如 digitsOnly 僅支持數(shù)字 [0-9]；
c. BlacklistingTextInputFormatter 防止輸入黑名單中字符；如 singleLineFormatter 強制輸入單行；
分析源碼 RegExp("[/]") 可以設置正則表達式；
17、onChanged 文本內(nèi)容變更時回調(diào)，可實時監(jiān)聽 TextField 輸入內(nèi)容；
18、controller 文本控制器，監(jiān)聽輸入內(nèi)容回調(diào)；
19、onTap 點擊 TextField時回調(diào)；
20、onEditingComplete 在提交內(nèi)容時回調(diào)，通常是點擊回車按鍵時回調(diào)；
21、onSubmit 在提交時回調(diào)，不可與 onEditingComplete 同時使用，區(qū)別在于 onSubmit 是帶返回值的回調(diào)；
問題小結：
當 TextField 設置 enableInteractiveSelection 屬性后長按會出現(xiàn)菜單，默認為英文，可通過設置 Flutter 國際化來處理；
（1）在 pubspec.yaml 中集成 flutter_localizations；
2）在 MaterialApp 中設置本地化代理和支持的語言類型；
（1）將 maxLength 設置為 null 僅使用 LengthLimitingTextInputFormatter 限制最長字符；
（2）設置 InputDecoration 中 decoration 屬性為空；但是底部有空余，只是隱藏而并非消失；
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ù)：
重慶分公司
重慶分公司
