flutter顶层页,flutter 蒙层

Flutter 启动页的前世今生适配历程

APP 启动页在国内是最常见也是必备的场景,其中启动页在 iOS 上算是强制性的要求,其实配置启动页挺简单,因为在 Flutter 里现在只需要:

创新互联建站主要从事网站设计制作、成都网站设计、网页设计、企业做网站、公司建网站等业务。立足成都服务陆川,十余年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:13518219792

一般只要配置无误并且图片尺寸匹配,基本上就不会有什么问题, 那既然这样,还有什么需要适配的呢?

事实上大部分时候 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 完全使用GetX 主题切换 以及 自创建Widget的颜色随主题变化方案

这篇将会解决手动切换主题以及跟随手机切换主题来更新UI(包括自己创建的Widget)

主题切换有个问题,就是如果是我们自定义或者在 build() 自己创建的部件是不会随着系统的主题切换而发生主题色变化的(实际测试中,如果页面在顶层(没有被push)切换主题并不会触发 build() 方法,(push之后的页面切换系统主题是可以触发 build() 的,而且会频繁触发好多次...),既然无法通过重新 build 更新组件的主题色,那么我们在切换主题后,强制触发整个app的 build() 就可以了)

Flutter组件(Widget)的局部刷新方式

Flutter中有两个常用的状态Widget分为StatefulWidget和StatelessWidget,分别为动态视图和静态视图,视图的更新需要调用StatefulWidget的setState方法,这会遍历调用子Widget的build方法。如果一个页面内容比较复杂时,会包含多个widget,如果直接调用setState,会遍历所有子Widget的build,这样会造成很多不必要的开销,所以非常有必要了解Flutter中局部刷新的方式:

globalkey唯一定义了某个element,它使你能够访问与element相关联的其他对象,例如buildContext、state等。应用场景:跨widget访问状态。

例如:可以通过key.currentState拿到它的状态对象,然后就可以调用其中的onPressed方法。

Flutter框架内部提供了一个非常小巧精致的组件,专门用于局部组件的刷新。适用于值改动的刷新。

实现原理:在 initState 中对传入的可监听对象进行监听,执行 _valueChanged 方法,_valueChanged 中进行了 setState 来触发当前状态的刷新。触发 build 方法,从而触发 widget.builder 回调,这样就实现了局部刷新。可以看到这里回调的 child 是组件传入的 child,所以直接使用,这就是对 child 的优化的根源。

可以看到 ValueListenableBuilder 实现局部刷新的本质,也是进行组件的抽离,让组件状态的改变框定在状态内部,并通过 builder 回调控制局部刷新,暴露给用户使用。

通过这个可以创建一个支持局部刷新的widget树,比如你可以在StatelessWidget里面刷新某个布局,但是不需要改变成StatefulWidget;也可以在StatefulWidget中使用做部分刷新而不需要刷新整个页面,这个刷新是不会调用Widget build(BuildContext context)刷新整个布局树的。

异步UI更新:

很多时候我们会依赖一些异步数据来动态更新UI,比如在打开一个页面时我们需要先从互联网上获取数据,在获取数据的过程中显示一个加载框,等获取到数据时我们再渲染页面;又比如我们想展示Stream(比如文件流、互联网数据接收流)的进度。当然StatefulWidget我们完全可以实现以上功能。但由于在实际开发中依赖异步数据更新UI的这种场景非常常见,并且当StatefulWidget中控件树较大时,更新一个属性导致整个树重建,消耗性能,因此Flutter专门提供了FutureBuilder和SteamBuilder两个组件来快速实现这种功能。

通常情况下,子Widget无法单独感知父Widget的变化,当父state变化时,通过其build重建所有子widget;

InheriteddWidget可以避免这种全局创建,实现局部子Widget更新。InheritedWidget提供了一种在Widget树中从上到下传递、共享数据的方式。Flutter SDK正是通过InheritedWidget来共享应用主题和Locale等信息。

InheritedWidgetData

TestData

InheritedTest1Page

provider是Google I/O 2019大会上宣布的现在官方推荐的管理方式,而ChangeNotifierProvider可以说是Provider的一种:

yaml文件需要引入provider: ^3.1.0

顶层嵌套ChangeNotifierProvider

创建共享数据类DataInfo:

数据类需要with ChangeNotifier 以使用 notifyListeners()函数通知监听者更新界面。

使用Provider.of(context)获取DataInfo

nextPage:

使用Consumer包住需要使用共享数据的Widget

RepaintBoundary就是重绘边界,用于重绘时独立于父视图。页面需要更新的页面结构可以用 RepaintBoundary组件嵌套,flutter 会将包含的组件独立出一层"画布",去绘制。官方很多组件 外层也包了层 RepaintBoundary 标签。如果你的自定义view比较复杂,应该尽可能的避免重绘。

以上总结了几种Flutter的局部刷新的方式,可根据实际需要使用不同的方式,最适合的才是最好的。

(1)Flutter记录之启动页

一年半前玩过flutter,忘光光...现在是时候重新拾取了。~

启动页一般只放图片或者加几行文字。

1、创建好flutter项目之后,在lib文件下面新建launch.dart或xx.dart.

2、在根目录下新建images文件夹,如已有直接放入图片

3、flutter_yijiake.iml中加入注入该图片,并注意空格

4、在根目录下的test/widget_test.dart中更改默认的启动页为当前的启动页路径

5、最后重新设置启动时的页面

6、非常简单的启动页面放logo图片

值得一说的是,flutter框架的UI组件需要已new 组件的形式展开。

Flutter中showDialog()后关闭Dialog

在耗时操作的时候,一般都要弹出一个加载框,然后在完成的时候再把加载框关掉,在Flutter中可以直接用showDialog()来弹出一个对话框。

这是一个简单的提示对话框,包含了关闭按钮,点击就能关闭。但一般的耗时操作完成,就需要我们自己把dialog关闭掉。

首先,开启dialog的时机。由于我们需要获取到BuildContext,所以就得等build()方法走完,这里可以用Future.delayed()来等创建好BuildContext再进行创建,或者用Timer来延迟操作,我选择了前者。

其中delayed()在initState()结尾来做就行,这里参考网友封装了一个LoadingDialog。

那么接下来要在什么时机关闭呢?

一开始,我理所当然的以为,是在异步方法结束后,去更新界面的时候关闭,也就是setState(() {})的时候,可是不管怎么尝试,用Navigator.pop()不行,用Navigator.of(context, rootNavigator: true).pop(result)也不行,用FlutterBoost.singleton.close(id)也不行,用FlutterBoost.singleton.closeCurrent()也不行,都会直接把非Dialog的页面也关闭掉,这让我百思不得其解,因为showDialog()的本质也是新建了一个Route出来,也就是最顶层的页面是弹出的Dialog,可是为什么关不掉呢。

一番思前想后,把showDialog的逻辑移到和异步逻辑同级,也就是setState(() {})外面,然后把showDialog()自身创建的BuildContext传进去就能正常关闭了。也就是,在setState(() {})的时候,其实用的context还是非Dialog页面的,所以关闭的当然就不是Dialog了。

持有Dialog自己的BuildContext,然后在异步以后调用就行了。

Flutter开发--如何布局?

相对于iOS开发,Flutter的布局更具有灵活性,每个页面设计都不一样,相同页面可选择的布局方式也不一样,如果单纯的说应该如何去布局,我觉得不现实,大家可以参考下 Flutter官方的布局教程 。接下来,笔者,通过项目中的一个页面,来一步一步的拆解布局的流程。整个过程,基本上按照拆解、组件封装、具体布局这三步来的。

根据设计图,可以看出整体可以分成两部分,上面一部分是系统介绍模块,下面一部分是真正的登录内容,因为涉及到叠加,因此考虑用Stack;

系统介绍模块部分:整体也是涉及到叠加,考虑用Stack,分为四部分。最底部渐变色背景用一个contanier,无须指定位置,全视图扩展;载放logo图标在上一层,用Image。最后两个Text同级放在最上层。Image,Text各用Positioned包裹去指定位置。

登录内容模块是最外层是一个Contanier容器,去控制背景色和圆角。然后是一个Column元素,逐行排列。

第一行为Image,

第二行为Text,

第三行可以看成一个小Column,分两块进行布局

第四行可以看成一个小Column,分两块进行布局

第五行可以看作一个TextButton,

第六行可以看作一个Row,分三块进行布局

通过上面这样一步一步的分析后,基本上对大致的布局有了一个了解,最外层的控件大致选对(只要能实现的话,就是复杂度以及效率的问题),然后一步一步的拆解每一行的元素,如果有重复的或者觉得可以封装出来的部分,则进行下一步。

每一行的拆解,大致也是按照这个思路来进行,因此笔者在这里就不做讲解了。

在做到第三第四行的时候,发现这两个很相似,而且设计到一些交互逻辑,笔者就想对第三第四行的这种展示进行封装,觉得今后的布局可能会用到,因此在这一步,可以先把这一块儿抽离出一个控件。利用TextField来实现这种输入操作,具体的实现笔者不再详细的描述了。

经过这一步,整体的规划设计图已经有了,各个组件也都有了,接下来的工作就是组装了。

具体布局设计到一些细节的地方,例如整体Column的居中对齐(crossAxisAlignment)、间隔(Padding或Container包裹,笔者更喜欢用SizedBox占位)、居左居右居中(Align)、点击事件(GestureDetector)以及圆角(BorderRadius)等一些特殊情况。

像第六行row是放在底部的,就可以在第六行前面增加一个Spacer()去填充空白区域。

对文字颜色大小等,可以用TextStyle直接设置。

对于输入框的删除按钮,可以用Offstage这种Flutter特有的控制显示隐藏的控件。


分享题目:flutter顶层页,flutter 蒙层
文章起源:http://hbruida.cn/article/dsiipjp.html