APP 启动页在国内是最常见也是必备的场景，其中启动页在 iOS 上算是强制性的要求，其实配置启动页挺简单，因为在 Flutter 里现在只需要：
创新互联提供高防服务器、云服务器、香港服务器、成都服务器托管等
一般只要配置无误并且图片尺寸匹配，基本上就不会有什么问题， 那既然这样，还有什么需要适配的呢？
事实上大部分时候 iOS 是不会有什么问题， 因为 LaunchScreen.storyboard 的流程本就是 iOS 官方用来做应用启动的过渡；而对于 Andorid 而言，直到 12 之前 windowBackground 这种其实只能算“民间”野路子 ，所以对于 Andorid 来说，这其中就涉及到一个点：
所以下面主要介绍 Flutter 在 Android 上为了这个启动图做了哪些骚操作～
在已经忘记版本的“远古时期” ， FlutterActivity 还在 io.flutter.app.FlutterActivity 路径下的时候，那时启动页的逻辑相对简单，主要是通过 App 的 AndroidManifest 文件里是否配置了 SplashScreenUntilFirstFrame 来进行判断。
在 FlutterActivity 内部 FlutterView 被创建的时候，会通过读取 meta-data 来判断是否需要使用 createLaunchView 逻辑 ：
是不是很简单，那就会有人疑问为什么要这样做？我直接配置 Activity 的 android:windowBackground 不就完成了吗？
这就是上面提到的时间差问题， 因为启动页到 Flutter 渲染完第一帧画面中间，会出现概率出现黑屏的情况，所以才需要这个行为来实现过渡 。
经历了“远古时代”之后， FlutterActivity 来到了 io.flutter.embedding.android.FlutterActivity ， 在到 2.5 版本发布之前，Flutter 又针对这个启动过程做了不少调整和优化，其中主要就是 SplashScreen 。
自从开始进入 embedding 阶段后， FlutterActivity 主要用于实现了一个叫 Host 的 interface ，其中和我们有关系的就是 provideSplashScreen 。
默认情况下它会从 AndroidManifest 文件里是否配置了 SplashScreenDrawable 来进行判断 。
默认情况下当 AndroidManifest 文件里配置了 SplashScreenDrawable ，那么这个 Drawable 就会在 FlutterActivity 创建 FlutterView 时被构建成 DrawableSplashScreen 。
DrawableSplashScreen 其实就是一个实现了 io.flutter.embedding.android.SplashScreen 接口的类，它的作用就是：
之后 FlutterActivity 内会创建出 FlutterSplashView ，它是个 FrameLayout。
FlutterSplashView 将 FlutterView 和 ImageView 添加到一起， 然后通过 transitionToFlutter 的方法来执行动画，最后动画结束时通过 onTransitionComplete 移除 splashScreenView 。
所以整体逻辑就是：
当然这里也是分状态：
当然这个阶段的 FlutterActivity 也可以通过 override provideSplashScreen 方法来自定义 SplashScreen 。
看到没有，做了这么多其实也就是为了弥补启动页和 Flutter 渲染之间， 另外还有一个优化，叫 NormalTheme 。
通过该配置 NormalTheme ，在 Activity 启动时，就会首先执行 switchLaunchThemeForNormalTheme(); 方法将主题从 LaunchTheme 切换到 NormalTheme 。
大概配置完就是如下样子， 前面分析那么多其实就是为了告诉你，如果出现问题了，你可以从哪个地方去找到对应的点 。
讲了那么多， Flutter 2.5 之后 provideSplashScreen 和 io.flutter.embedding.android.SplashScreenDrawable 就被弃用了，惊不喜惊喜，意不意外，开不开心 ？
通过源码你会发现，当你设置了 splashScreen 的时候，会看到一个 log 警告：
为什么会弃用？
其实这个提议是在 这个 issue 上，然后通过 这个 pr 完成调整。
大概意思就是： 原本的设计搞复杂了，用 OnPreDrawListener 更精准，而且不需要为了后面 Andorid12 的启动支持做其他兼容，只需要给 FlutterActivity 等类增加接口开关即可 。
也就是2.5之后 Flutter 使用 ViewTreeObserver.OnPreDrawListener 来实现延迟直到加载出 Flutter 的第一帧。
为什么说默认情况？ 因为这个行为在 FlutterActivity 里，是在 getRenderMode() == RenderMode.surface 才会被调用，而 RenderMode 又和 BackgroundMode 有关心 。
所以在 2.5 版本后， FlutterActivity 内部创建完 FlutterView 后就会执行一个 delayFirstAndroidViewDraw 的操作。
这里主要注意一个参数： isFlutterUiDisplayed 。
当 Flutter 被完成展示的时候， isFlutterUiDisplayed 就会被设置为 true。
所以当 Flutter 没有执行完成之前， FlutterView 的 onPreDraw 就会一直返回 false ，这也是 Flutter 2.5 开始之后适配启动页的新调整。
看了这么多，大概可以看到其实开源项目的推进并不是一帆风顺的，没有什么是一开始就是最优解，而是经过多方尝试和交流，才有了现在的版本，事实上开源项目里，类似这样的经历数不胜数：
下载了一个开源项目flutter-folio
编译的时候一直在说方法找不到。
Error: Method not found:
是cloud_firebase_web跳转找firebase_core的某个方法的时候说找不到。
按照网上说的在firebase包定义前面添加关键字dependency_overrides:也不行。
开始的时候尝试着自己修改方法名让它能够找到，一直搞不定。总感觉这个是系统自带的类库，不应该发生这么低级的错误了。
最后仔细看了一下他们的版本不对应，有可能是版本问题，cloud_firebase_web是1.0.7，使用工具跳转到firebase_core的时候是1.17.0
然后就尝试着手动修改firebase_core关联的包，不要让它自动匹配版本，而是强制使用某一个固定版本。
比如之前是这么写的：firebase_core: ^1.0.1，^含义是找到大于1.0.1小于2.0.0的最高版本
修改成：firebase_core: 1.4.0
具体有哪些版本可以去这个网站上找：
然后就可以了。
事后分析原因是：firebase_core虽然没有修改大版本号，当前依然是1.17.0。但是里面做了不兼容的改动，删除了某些方法，导致了找不到。而cloud_firebase_web当前的最高版本已经是3点几了，因此对应firebase_core版本的cloud_firebase_web在2或者3才兼容。
所以包管理真的是一件比较麻烦的事情。
本文对比的是 UIWebView、WKWebView、flutter_webview_plugin（在iOS中使用的是WKWebView）的加载速度，内存使用情况。
测试网页打开的速度，只需要获取 WebView 在开始加载网页和网页加载完成时的时间戳，时间戳的差即为打开网页的时间
为了使差异更明显，我们选择较为复杂的 新浪首页 进行加载的对比，为了减小网络对加载速度的影响，我们让手机连接同一个网络，分别进行 10 次测试然后取平均值，另外，我们需要关闭 WebView 的缓存，防止缓存对加载速度产生影响
下面使笔者进行 10 次测试所得到的数据
结果让我有点惊讶，一直以为 WKWebView 会是个王者。结果看，速度上 WKWebView 略慢一点，不过总体差异不大（该结果仅仅是测试新浪的结果，仅供参考啦）
在这里，笔者又加了一个测试，尝试记录从 viewController 的 viewDidLoad 到 webview 的 didFinish 时间，测试了新浪的数据，如下：
UIWebViewA ： 4970、3808、3815、4250、3556 avg(4079.8) （加载完所有页面）
UIWebViewB ： 4103、3124、3070、3256、2835 avg(3277.6)（加载sina完毕）
WKWebView ： 3672、3032、2892、2912、2739 avg(3049.4)
flutter_webView ： 4532、3901、4310、3496、3378 avg(3923.4)
其中可以看到，webView 有两行，UIWebViewB 的数据就是加载 sina 主站的时间；UIWebViewA 的数据是因为在加载完 sina 主站之后，新浪又加载了一个 ，所以导致总时间延长，不过即使按照 UIWebViewB 的数据来比较，也是 wkWebView 略胜一筹。
此处可以看出 flutter_webView 使用的是 wkwebView，所以它吃亏的主要原因是 flutter 包了一层。
结论：
速度（didStart - didFinish） UIWebView flutter_webview WKWebView
速度（viewDidLoad - didFinish）WKWebView UIWebView flutter_webview
这里查看内存使用的是 xcode 的 debug session 中的 memory。
首先看之前测试时，连续打开十次新浪的内存情况
接着我们在看一下打开淘宝首页的内存情况
从图上可以看出，WKWebView 在内存方面有很大的优势啊，UIWebView 的内存是真的伤啊，然后 debug 看了一下 flutter_webView，他使用的就是原生的 webView 。
他相比较原生 WKWebView 的内存开销稍大一点，从测试表现来看，一般大个 30 MB 左右。
结论：内存 WKWebView flutter_webview UIWebView
可以在 html5test 中对浏览器的兼容性进行评分，通过测试发现得分分别如下
因为 flutter 里使用的就是 WK，所以和原生的 WKWebView 一样都是 444 分，比 UIWebView 的 437 略胜一筹
结论：兼容性 WKWebView = flutter_webview UIWebView
UIWebView : 速度相比较 WKWebView 稍快一点，但是内存是一大硬伤，所以只要条件允许，就不推荐使用了
WKWebView : 速度略慢一点，不过差别不大，总体可以接受。是比UIWebView更好的选择，推荐使用。
flutter_webView_plugin ：在iOS中使用的就是原生的WKWebView，所以总体和 native WKWebView 表现差不多。如果是混编项目中，因为它被包了一层，所以页面加载上存在一定的劣势，所以混编项目中仍然推荐使用 WKWebView。不过如果从多端考虑、以及项目可迁移等，那么使用也未尝不可，就是维护成本要增加一些，需要维护两套 webView。这个就需要根据自己的情况自己取舍了。
环境准备阶段：
android-studio 版本：android-studio-ide-191.5977832-windows.exe 3.5.2
flutter版本：stable 版本 （完成系统环境变量 path配置）
dart版本：2.12.0 （完成系统环境变量 path配置）
完成相关软件安装。
配置flutter相关SDK及andriod studio路径：
flutter config --android-sdk="C:\Users\Administrator\AppData\Local\Android\Sdk"
flutter config --android-studio-dir="D:\Program Files\Android\Android Studio"
执行flutter doctor运行成功。
夜神模拟器地址：D:\Program Files\Nox\bin （完成系统环境变量 path配置）
andriod SDK tools：C:\Users\Administrator\AppData\Local\Android\Sdk\platform-tools （完成系统环境变量 path配置）
nox_adb.exe connect 127.0.0.1:62001
dart SDK:D:\software\dartsdk-windows-x64-release\dart-sdk\bin
将C:\Users\Administrator\AppData\Local\Android\Sdk\platform-tools 下面adb.exe 复制至D:\Program Files\Nox\bin覆盖
adb.exe，此外重新复制adb.exe命名为nox_adb.exe，替换原有的nox_adb.exe。
cdm 输入nox_adb version 及adb version发现版本一致。
启动野神模拟器，输入adb devices发现虚拟设备，执行flutter devices发现 127.0.0.1:62001 设备。
修改C:\learn_flutter\first_flutter\android\gradle\wrapper\gradle-wrapper.properties
distributionUrl=
修改C:\learn_flutter\first_flutter\android\build.gradle
buildscript {
ext.kotlin_version = '1.3.50'
repositories {
// google()
// jcenter()
maven { url ' ' }
maven { url ' ' }
maven { url ' ' }
}
}
allprojects {
repositories {
// google()
// jcenter()
maven { url ' ' }
maven { url ' ' }
maven { url ' ' }
}
}
修改：C:\win-flutter\flutter\packages\flutter_tools\gradle\flutter.gradle
buildscript {
repositories {
// google()
// jcenter()
maven { url ' ' }
maven { url ' ' }
maven { url ' ' }
}
dependencies {
classpath 'com.android.tools.build:gradle:4.1.0'
}
}
//private static final String DEFAULT_MAVEN_HOST = " ";
private static final String DEFAULT_MAVEN_HOST = " ";
修改：C:\win-flutter\flutter\packages\flutter_tools\gradle\resolve_dependencies.gradle
repositories {
google()
jcenter()
maven {
//url "$storageUrl/download.flutter.io"
url " "
}
}
执行 flutter run启动成功。
环境搭建坑点在于JDK兼容问题以及网络问题。
android做地理定位，直接可以用网络权限和gps权限就可以定位呗，获取经纬度网上cnsd有代码的。
下面这种情况下，为 InkWell 设置的 splashColor 不会生效：
需要用 Material 去除背景色，然后将颜色设置在 InkWell 外部：
在 Dialog builder 中使用 WillPopScope 禁用返回键返回：
注意：使用此方法同时也会禁用 iOS 上的手势滑动返回功能，推荐判断平台后再使用。
修改对话框中的复选框状态，最简便的方法是通过 Element 中的 markNeedsBuild 方法：
当然，更推荐的做法是通过 StatefulBuilder ，然后就可以在 Dialog 中调用 setState 方法了，不过在调用 setState 时需要判断 Dialog 是否已经关闭，否则会造成 setState() called after dispose() 的错误，可以通过添加一个标志位来解决，如下：
在 Web 中加载网络图片有时会失败，遇到这样的报错： Exception caught by image resource service... ，造成该错误的原因通常是，图片跨域了（见 跨域资源共享 ）。最简单的解决办法是， 使用 HTML 渲染加载 ，而不是默认的 CanvasKit。
Flutter 中所有的 list 默认都是没有 ScrollBar 的，必须使用 ScrollBar 组件。ScrollBar 组件通过监听 ScrollView 的 ScrollNotification 来刷新位置，所以 List 的长度必须是固定的。
当使用 WebView 等高度不定的组件时会出现内容被截断的情况，通常可以使用 NestedScrollView 来解决该问题，需要在 WebView 外部嵌套 SingleChildScrollView。
虽然使用了缓存，而且也是用 builder 加载图片的，但是发现一个现象：滑动屏幕后图片短暂消失并重新加载了。图片高度很高时这种现象更加明显，其原因是超出屏幕范围一定距离的组件被重新渲染了。解决方法是在 ListView 上设置 cacheExtent 参数:
该参数的作用是改变超出屏幕高度后继续渲染的范围（以像素为单位），比如设置成 9999 后意味着超出屏幕 10000 像素以内的内容都会被保留下来。
借助 IntrinsicHeight 组件：
另外，IntrinsicHeight 还可以用于 Dialog 或者 BottomSheet 中，使得其中的元素 显示内在元素的高度 ，从而避免元素因为约束的存在而不显示或者高度太高（比如在使用了 Column 或者 Row 的时候）。
在通过 Uri 的 queryParameters 获取 query 参数时，发现有些链接会抛出下面异常：
造成该异常的原因是 Uri 默认使用 utf-8 解码超链接字符串，如果链接中包含非 utf-8 字符，就会造成上面的错误，相关 issue 见： issue #31621 。目前该 issue 处于 open 的状态，暂时的解决办法是，在所有使用到 queryParameter 的地方用 try..catch 捕捉可能抛出的异常。
Flutter 开发非常依赖各种官方或第三方的插件，而在使用这些插件时多少都会遇到一些问题，大部分问题都可以通过搜索和查找 issue 来解决。这里记录下一些我在使用部分插件时遇到的问题及其解决方法。
目前该库没有图片加载完成的回调（见 issue #545 ），不过我们可以通过在 imageBuilder 中来添加回调：
这是一个应用内更新插件，安卓 10 以上安装时需要在 manifest 中添加以下内容：
目前功能最强大的 WebView 插件，基本能满足绝大部分移动端网页加载的需求，而且可定制化程度高。
一般通过 CookieManager 修改 Cookie，拦截请求并修改请求对象的 Header 不会生效。
InAppWebViewOptions 的 userAgent 只在 iOS 上生效，而 applicationNameForUserAgent 只在 Android 上生效，所以最好的做法是分平台设置 InAppWebViewOptions ，而且需要注意，由于设置 userAgent 后会覆盖默认的 UserAgent，所以如果需要在默认的 UserAgent 上添加其它参数，iOS 上需要通过 InAppWebViewController.getDefaultUserAgent() 获取默认 UserAgent 参数，而 Android 不需要添加。
如果图片源或者请求是 http 的，为了在 Android 上正常加载请求，必须在 AndroidInAppWebViewOptions 中将 mixedContentMode 设置为 AndroidMixedContentMode.MIXED_CONTENT_ALWAYS_ALLOW 。
当我们想要设置全屏图片的时候，由于默认的 Constraint 会将图片居中显示，所以图片四周会留有空隙。为了去除这个限制，我们需要 Xcode 中打开 LaunchScreen.storyboard，然后在 View Controller 的 View 和 LaunchImage 上的 Safe Area 去掉。
具体设置方法：右侧 Inspector 面板 Show the Size inspector 解选 Layout Margins 中的 Safe Area Relative Margins，拖动图片占满全屏，然后根据 View Controller Scene 的 Warning，更新 Constraint 就可以了。
在集成某些三方库之后，在使用命令行运行 iOS 模拟器的时候可能会遇到下面这个报错：
这是因为 iOS 模拟器未来将会兼容 arm64 架构，但是目前还不支持，所以我们需要修改 Build Setting 使得能够在 x86_64 的模拟器上运行，操作步骤见 这里 。
