Flutter之 State 生命周期

　　State 的生命周期，指的是在用户参与的情况下，其关联的 Widget 所经历的，从创建到显示，再到更新最后到停止，直至销毁等各个阶段

　　不同的阶段涉及到特定的任务处理

　　State 的生命周期流程如下图所示

　　file

　　由图可知：State 的生命周期可以分为三个阶段：创建（插入视图树）、更新（在视图树中存在）、销毁（从视图树中移除）

　　创建

　　State 初始化时会依次执行：构造方法 -> initState -> didChangeDependencies -> build，随后完成页面渲染

　　构造方法：State 生命周期的起点，Flutter 会通过调用 StatefulWidget.createState() 来创建一个 State。可以通过构造方法，来接收父 Widget 传递的初始化 UI 配置数据，而这些配置数据，决定了 Widget 最初的呈现状态

　　initState：在 State 对象被插入视图树时调用。在 State 的生命周期中只会被调用一次，因此可以在 initState 函数中做一些初始化操作

　　didChangeDependencies：专门用来处理 State 对象依赖关系变化，会在 initState() 调用结束后调用

　　build：构建视图。经过构造方法、initState、didChangeDependencies 后，Framework 认为 State 已经准备就绪，于是便调用 build。在 build 中，需要根据父 Widget 传递过来的初始化配置数据及 State 的当前状态，创建一个 Widget 然后返回

　　更新

　　Widget 的状态更新，主要由 setState、didChangeDependencies 和 didUpdateWidget 触发

　　setState：当状态数据发生变化时，可以通过调用 setState 方法告诉 Flutter 使用更新后数据重建 UI

　　didChangeDependencies：State 对象的依赖关系发生变化后，Flutter 会回调该方法，随后触发组件构建。State 对象依赖关系发生变化的典型场景：系统语言 Locale 或应用主题改变时，系统会通知 State 执行 didChangeDependencies 回调方法

　　didUpdateWidget：Widget 的配置发生变化时，或热重载时，系统会回调该方法

　　一旦这三个方法被调用，Flutter 随后便会销毁旧的 Widget，并调用 build 方法重建 Widget

　　销毁

　　组件销毁相对创建和更新而言更简单。比如页面销毁时或是组件被移除时，系统会调用 deactivate 和 dispose 这两个方法，来移除或销毁组件

　　当组件的可见状态发生变化时，deactivate 方法会被调用，这时 State 会被暂时从视图树中移除。 注意：页面切换时，由于 State 对象在视图树中的位置发生了变化，需要先暂时移除后再重新添加，重新触发组件构建，因此也会调用 deactivate 方法

　　当 State 被永久地从视图树中移除时，Flutter 会调用 dispose 方法，而一旦 dispose 方法被调用，组件就要被销毁了，因此可以在 dispose 方法中进行最终的资源释放、移除监听、清理环境等工作high/sentinel_nacos/src/main/java/com/springcloud/sentinel_nacos/controller/HelloController.java

　　***

　　@RestControlle

　　public class HelloController www.pingguoyul.cn{

　　@GetMapping(www.dayuzaixianyl.cn"/hello")

　　public String hello(HttpServletRequest request) www.jintianxuesha.com{

　　return www.zhuyngyule.cn"Hello, port is: " + request.getLocalPort(www.pingguoyul.cn);

　　}

　　}

　　1.4 配置Nacos配置中心

　　配置内容如图：

　　注意其中配置的Data ID和Group要和程序中配置的保持一致。格式选择JSON，填入的内容如下：

　　[

　　{

　　"resource": "/hello",

　　"limitApp": "default",

　　"grade": 1,

　　"count": 1,

　　"strategy": 0,

　　"controlBehavior"www.sanguoyoux.cn: 0,

　　"clusterMode": false

　　}

　　]

　　可以看到上面配置规则是一个数组类型，数组中的每个对象是针对每一个保护资源的配置对象，每个对象中的属性解释如下：

　　resource：资源名，即限流规则的作用对象。

　　limitApp：流控针对的调用来源，若为 default 则不区分调用来源。

　　grade：限流阈值类型，QPS 或线程数模式，0代表根据并发数量来限流，1代表根据QPS来进行流量控制。

　　count：限流阈值

　　strategy：判断的根据是资源自身，还是根据其它关联资源 (refResource)，还是根据链路入口

　　controlBehavior：流控效果（直接拒绝 / 排队等待 / 慢启动模式）

　　clusterMode：是否为集群模式

　　1.5 测试

　　正常启动子工程，打开浏览器访问几次http://localhost:10000/hello ，速度快一些可以发现已经限流了，限流后页面显示如下：

　　Blocked by Sentinel (flow limiting)

　　正面限流配置成功，这时我们打开Sentinel控制台，看一下流量规则限制，已经有一条数据了，是我们在Nacos中配置的数据，如图：

　　注意：

　　在Sentinel动态规则整合了Nacos以后，对于修改接口流量控制就有两个地方了，一个是Sentinel的控制台，还有一个是Nacos的控制台。

　　但是要谨记，在当前版本中，在Sentinel控制台中修改了规则，将不会同步至Nacos的配置中心，而在Nacos中修改了配置规则，则会通过在客户端的Listener来是同步Sentinel控制台。所以，在整合了Nacos做动态规则存储后需要注意两点：

　　Sentinel控制台中修改规则：仅存在于服务的内存中，不会修改Nacos中的配置值，重启后恢复原来的值。

　　Nacos控制台中修改规则：服务的内存中规则会更新，Nacos中持久化规则也会更新，重启后依然保持。

　　建议各位堵住最好在Nacos控制台做规则的修改操作，尽量避免直接在Sentinel控制台中直接做规则修改。