13518219792
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 开始之后适配启动页的新调整。
看了这么多，大概可以看到其实开源项目的推进并不是一帆风顺的，没有什么是一开始就是最优解，而是经过多方尝试和交流，才有了现在的版本，事实上开源项目里，类似这样的经历数不胜数：
ListView的基础创建使用有三种方式：
通过默认构造函数来创建列表，应用场景 = 短列表
这种方式创建的列表存在一个问题：对于那些长列表或者需要较昂贵渲染开销的子组件，即使还没有出现在屏幕中但仍然会被ListView所创建，这将是一项较大的开销，使用不当可能引起性能问题甚至卡顿。
长列表
列表子项之间需要分割线
ListView的进阶使用主要包括：下拉刷新 上拉加载
在Flutter中，ListView结合RefreshIndicator组件实现下拉刷新
通过包裹一层RefreshIndicator，自定义onRefresh回调方法实现
方式有两种：
通过ListView.controller属性可以判断ListView是否滑动到了底部，再进行上拉加载
NotificationListener是一个Widget，可监听子Widget发出的Notification
ListView在滑动时中会发出ScrollNotification类型的通知，可通过监听该通知得到ListView的滑动状态，判断是否滑动到了底部，从而进行上拉加载
NotificationListener有一个onNotification属性，定义了监听的回调方法，通过它来处理加载更多逻辑
不定期分享关于 安卓开发 的干货，追求 短、平、快 ，但 却不缺深度 。
onInteractionEnd 交互结束
onInteractionStart 交互开始
onInteractionUpdate 滑动时候一直会回调
focalPoint 是相对于屏幕左上角的偏移量。
localFocalPoint是相对于父容器区域左上角的偏移量。
scale缩放量。
horizontalScale水平缩放量。
verticalScale竖直缩放量。
rotation旋转量。------ 这里说明能监听到旋转量
还可以通过transformationController进行变换控制，有兴趣的可以自己研究。
参考文章
新建一个Flutter工程，android模块。
1，只有一个Activity组件，它是Dart层绘制Widget的容器。
2，Application配置FlutterApplication。
应用Application配置io.flutter.app.FlutterApplication类，App首次启动时，初始化。
调用FlutterMain.startInitialization()方法。
initConfig方法，从AndroidManfest.xml配置的applicaion节点获取meta-data数据，初始化以下默认值。
这些值都是使用中用到的name，例如，抽取apk中asset资源时，flutter_assets打包目录，打包产物data名称。
initResources方法， 初始化资源。
在Flutter打包apk的asset目录下，包括fluttter_asset目录/资源项，将资源从apk中抽取，保存在 Context.getDir("flutter", 0) 目录下。
/data/user/0/包名/app_flutter目录。
在目录中创建一个时间戳文件，根据apk版本和包信息记录的lastUpdateTime更新时间，第二次启动时，若apk未更新，不需要再次抽取。
加载so库，libflutter.so，System.loadLibrary()。
主页面继承FlutterActivity，配置启动模式singleTop。
FlutterActivity类在io.flutter.app包， (区别io.flutter.embedding.android包)， 组件生命周期委托给FlutterActivityDelegate类。
组件启动，onCreate方法。
FlutterMain.ensureInitializationComplete方法，确保资源成功抽取完成，创建FlutterView视图(io.flutter.view)，继承SurfaceView类，setContentView方法，设置组件主布局即FlutterView视图。
最后，根据Bundle路径，runBundle()加载运行，
调用FlutterView的runFromBundle方法，入口点在dart的main方法，
通过FlutterNativeView，调用FlutterJNI的native方法。
nativeRunBundleAndSnapshotFromLibrary方法。
任重而道远
在flutter开发过程中，发现Android手机在App首页点击物理返回按钮时，App会退出并且再次点开App时会重新启动，这代表了上次的退出直接杀死了App,和我们平常的退到手机桌面不同，所以开发了一个单独插件来处理这种情况。
使用步骤如下：
1、pubspec.yaml文件中引入依赖
2、引用插件
3、使用插件来退出App到桌面，并且保持App后台运行
可根据实际情况在_onWillPop方法中处理相关逻辑，比如连续两次点击物理返回按钮才退出到桌面等。
手势操作在 Flutter 中分为两类：
第一类是原始的指针事件（Pointer Event），即原生开发中常见的触摸事件，表示屏幕上触摸（或鼠标、手写笔）行为触发的位移行为；
第二类则是手势识别（Gesture Detector），表示多个原始指针事件的组合操作，如点击、双击、长按等，是指针事件的语义化封装。
指针事件表示用户交互的原始触摸数据，如手指接触屏幕 PointerDownEvent、手指在屏幕上移动 PointerMoveEvent、手指抬起 PointerUpEvent，以及触摸取消 PointerCancelEvent。在手指接触屏幕，触摸事件发起时，Flutter 会确定手指与屏幕发生接触的位置上究竟有哪些组件，并将触摸事件交给最内层的组件去响应。事件会从这个最内层的组件开始，沿着组件树向根节点向上冒泡分发。通过 hitTestBehavior 去调整组件在命中测试期内应该如何表现，比如把触摸事件交给子组件，或者交给其视图层级之下的组件去响应。关于组件层面的原始指针事件的监听，Flutter 提供了 Listener Widget，可以监听其子 Widget 的原始指针事件。
Listener(
child: Container(
color: Colors.black,
width: 300,
height: 300,
),
onPointerDown: (event) = print("down $event"),// 手势按下回调
onPointerMove: (event) = print("move $event"),// 手势移动回调
onPointerUp: (event) = print("up $event"),// 手势抬起回调
);
Gesture 是手势语义的抽象，而如果我们想从组件层监听手势，则需要使用 GestureDetector 。GestureDetector 是一个处理各种高级用户触摸行为的 Widget，与 Listener 一样，也是一个功能性组件。
GestureDetector(// 手势识别
child: Container(color: Colors.red,width: 50,height: 50),// 红色子视图
onTap: ()=print("Tap"),// 点击回调
onDoubleTap: ()=print("Double Tap"),// 双击回调
onLongPress: ()=print("Long Press"),// 长按回调
onPanUpdate: (e) {// 拖动回调
setState(() {
// 更新位置
_left += e.delta.dx;
_top += e.delta.dy;
});
},
),
