Flutter笔记(三)：设置白色状态栏

在App设计中状态栏纯色的这种设计很常见，但是如果状态栏需要为白色的时候就必须为黑色字体。在Android中已经有很多成熟的方案来处理这种情况，那我们现在看看在Flutter中这种情况该怎么处理。

公司专注于为企业提供成都网站设计、做网站、微信公众号开发、商城开发，成都微信小程序，软件定制网站开发等一站式互联网企业服务。凭借多年丰富的经验，我们会仔细了解各客户的需求而做出多方面的分析、设计、整合，为客户设计出具风格及创意性的商业解决方案，创新互联建站更提供一系列网站制作和网站推广的服务。

这里的ThemeData即为控制App的主题，primarySwatch设置即可控制主题的各类颜色，但是这里的颜色是需要MaterialColor，但是纯色种的黑色和白色不是MaterialColor。所以不能设置primarySwatch为Colors.white。

注：MaterialColor包含以下这些

那么就只能使用其他方式设置主题为白色。即为设置

此时我们可以看到App的状态栏如下所示（Android）

虽然AppBar变成了白色，但是状态栏是灰色显然不是我们想要的。

尝试设置文字颜色，AppBar的Brightness有两种模式light和dark

这个和SystemUiOverlayStyle的light和dark刚好相反

然后设置状态栏颜色

设置为红色之后，得到以下的样式，可以看到状态栏为红色了，文字为白色

那么接下来我们只需要将状态栏设置为白色或者透明，状态栏文字设置为黑色。

最后得到以下视图

注：使用PreferredSize包裹，可以更得心应手哦！

SystemUiOverlayStyle在设置时其实有很多系统或者版本的限制

[Flutter]使用主题

flutter设置沉浸式状态栏

）

Flutter状态管理（五）：Redux

Flutter状态管理系列：

Flutter状态管理（一）：ScopedModel

Flutter状态管理（二）：Provider

Flutter状态管理（三）：BLoC（Business Logic Component）

Flutter状态管理（四）：ReactiveX之RxDart

Flutter状态管理（五）：Redux

有做过H5前端开发的朋友应该很早就接触过这个，Redux在React/VUE中，与在Flutter/Dart中概念一样，没有任何区别；唯一的区别只是使用上的不同。

它主要由三部分组成：

下图是一个完整的数据触发及更新流程：

我们看到上面整个数据流，都是单向的，由View发起，最后到View的更新；

为啥这样设计？

小节二介绍了Redux最基本的原理，但是，如何用Redux来做一些异步操作，比如：加载数据、请求API等？这里就引出来了Redux的中间件（Middleware），中间件能够让我们使得action在到达reducer之前，做些其它“动作”！有了中间件，我们不但可以请求API，还可以改变action，使得分发到其它reducer中去；

上图是有Middleware的流程图。

Redux在Flutter中的使用与在JavaScript中的使用方式稍微有点不同，为啥？

因为JavaScript是弱类型语言，而Dart是强类型语言，这就使得在JS中每个reducer可以独立管理，而在Flutter中需要由一个大对象来管理！

无论在JS中还是在Flutter中，通常都将action、reducer、store各自建一目录，放在redux目录下，目录结构如下：

ReduxPage在build中，也可以直接用StoreBuilder（参考ReduxPage2中写法），因为StoreBuilder也是InheritedWidget。

正因为Redux在Flutter中与在JS中不同，因此，在Flutter中，建议：

Flutter （三） 状态管理

Flutter （二）布局

Flutter （三） 状态管理

Flutter （四） Map转模型

Flutter （五） 网络请求

Flutter （六） 保留界面状态

Flutter （七） 混合开发 [配置]

Flutter （八） 混合开发 [Flutter完整项目嵌入到原生]

Flutter的setState（状态刷新）

Flutter有两个常用的状态类：

标记为dirty，执行的markNeedsBuild，定义在Element类中：

当前Element节点被标记为dirty，同时调用owner的scheduleBuildFor方法：

将element元素添加到全局的“脏”链表里。

BuildOwner用来管理哪些需要更新的Widget。这个owner最开始被初始化的地方在WidgetsBinding的initInstances方法中，随后初始化了onBuildScheduled方法，对应执行的是_handleBuildScheduled，定义在WidgetsBinding类中：

ensureVisualUpdate 方法定义在SchedulerBinding类中：

在提交下一帧绘制的时候会调用到scheduleFrame方法，提交给引擎绘制，看看scheduleFrame方法，也定义在SchedulerBinding类中：

提交给引擎绘制之后，会收到onDrawFrame的回调，最终执行到_handleDrawFrame方法中，对应的是handleDrawFrame方法，定义在SchedulerBinding类中：

在RendererBinding的initInstances方法中添加了一个回调到这个List中，对应的是RenderBinding的drawFrame方法，对应的节点进行绘制渲染操作。

WidgetsBinding中的drawFrame方法：

看看这里的buildScope方法，定义在BuildOwner方法中。在上面 scheduleBuildFor 方法介绍中有提到："scheduleBuildFor 是把一个 element 添加到 _dirtyElements 链表，以便当[WidgetsBinding.drawFrame]中调用 buildScope 的时候能够重构 element。onBuildScheduled()是一个 BuildOwner 的回调"。在 drawFrame 中调用 buildOwner.buildScope(renderViewElement)更新 elements。

_dirtyElements列表在遍历的过程中执行rebuild方法，此时将所有标记为dirty的Element节点依次执行rebuild，preformRebuild，build，updateChild，update方法，执行界面更新。完成build，update操作完成之后，后续会将需要绘制的RenderObject添加到需要layout的列表中，等待绘制渲染。所有绘制完成之后将_dirtyElments列表清空，_inDirtyList标记位置为false。

提交给引擎绘制渲染

看看super.drawFrame()，这里就执行到了RendererBinding类中，定义如下：

这里就是将最终需要绘制渲染的画面提交给引擎的地方了，绘制完成之后就在界面显示更新后的视图了。