StatefulWidget 需要借助于 State 对象，在特定的阶段来处理用户的交互或其内部数据的变化，并体现在 UI 上。这个特定的阶段，就涵盖来一个组件从加载到卸载的全过程，即生命周期。Flutter 中的 Widget 也存在生命周期，并且通过 State 来体现。
而 App 则是一个特殊的 Widget。除了需要处理视图显示的各个阶段（即视图的生命周期）之外，还需要应对应用从启动到退出所经历的各个状态（App 的生命周期）。
State 生命周期
State 的生命周期，指的是在用户参与的情况下，其关联的 Widget 所经历的，从创建到显示再到更新最后到停止，直至销毁等各个过程阶段。State 的生命周期可以分为 3 个阶段：创建（插入视图树）、更新（在视图树中存在）、销毁（从视图树中移除）。
创建
State 初始化时会依次执行：构造方法 -> initState -> disChangeDependencies -> build，随后完成页面渲染。
初始化过程中每个方法的意义如下：
- 构造方法是 State 生命周期的起点，Flutter 会通过调用 StatefulWidget.createState() 来创建一个 State。可以通过构造方法，来接收父 Widget 传递的初始化 UI 配置数据。这些配置数据，决定了 Widget 最初的呈现效果。
- initState，会在 State 对象被插入视图树的时候调用。这个函数在 State 的生命周期中只会被调用一次，所以可以在这里做一些初始化工作，比如为状态变量设定默认值。
- didChangeDependencies 则来专门处理 State 对象依赖关系变化，会在 initState() 调用结束后，被 Flutter 调用。
- build，作用是构建视图。经过以上步骤，Framework 认为 State 已经准备好了，于是调用 build。可以在这个函数中，根据父 Widget 传递过来的初始化配置数据，以及 State 的当前状态，创建一个 Widget 然后返回。
更新
Widget 的状态更新，主要由 3 个方法触发：setState、didchangeDependencies 与 didUpdateWidget.
如上三个方法对应的调用场景：
- setState：当状态数据发生变化时，通过调用这个方法告诉 Flutter：“这儿的数据变了，请使用更新后的数据重建 UI！”。
- didChangeDependencies：State 对象的依赖关系发生变化后，Flutter 会回调这个方法，随后触发组建构建。典型的场景是，系统语言 Locale 或应用主题改变时，系统会通知 State 执行 didChangeDependencies 回调方法。
- didUpdateWidget：当 Widget 的配置发生变化时，比如，父 Widget 触发重建（即父 Widget 的状态发生变化时），热重载时，系统会调用这个函数
一旦这三个方法被调用，Flutter 随后就会销毁老 Widget，并调用 build 方法重建 widget。
销毁
组件销毁比较简单。比如组件被移除，或是页面销毁的时候，系统会调用 deactivate 和 dispose 这两个方法，来移除或销毁组件。
具体调用机制如下：
- 当组件的可见状态发生变化时，deactivate 函数会被调用，这时 State 会被暂时从视图树中移除。值得注意的是，页面切换时，由于 State 对象在视图树中的位置发生了变化，需要先暂时移除后再重新添加，重新触发组件构建，因此这个函数也会被调用。
- 当 Sate 被永久地从视图树中移除时，Flutter 会调用 dispose 函数。而一旦到这个阶段，组件就要被销毁了，所以我们可以在这里进行最终的资源释放、移除监听、清理环境，等等。
从功能、调用时机和调用次数的纬度总结这些方法如下；
| 方法名 | 功能 | 调用时机 | 调用次数 |
|---|---|---|---|
| 构造方法 | 接收父Widget传递的初始化UI配置数据 | 创建State时 | 1 |
| initState | 与渲染相关的初始化工作 | 在State被插入视图树时 | 1 |
| didChangeDependencies | 处理State队形依赖关系变化 | initState后及State对象依赖关系变化时 | >= 1 |
| build | 构建视图 | State准备好数据需要渲染时 | >= 1 |
| setState | 触发视图重建 | 需要刷新UI时 | >= 1 |
| didUpdateWidget | 处理Widget的配置变化 | 父Widget setState触发子Widget重建时 | >= 1 |
| deactivate | 组件被移除 | 组件不可视 | >= 1 |
| dispose | 组件被销毁 | 组件被永久移除 | 1 |
App 生命周期
视图的生命周期，定义了视图的加载到构建的全过程，其回调机制能够确保我们可以根据视图的状态选择合适的时机做恰当的事情。App 的生命周期，则定义了 App 从启动到退出的全过程。
在原生 Android、iOS 开发中，有时需要在对应的 App 生命周期事件中做相应处理，比如 App 从后台进入前台、从前台退到后台，或是在 UI 绘制完成后做一些处理。
在原生开发中，可以通过重写 Activity、ViewController 生命周期回调方法，或是注册应用程序的相关通知，来监听 App 的生命周期并做相应的处理。而在 Flutter 中，我们可以利用 WidgetsBindingObserver 类，来实现同样的需求。
WidgetsBindingObserver 中具体回调函数有如下一些方法：
abstract class WidgetsBindingObserver {
// 页面 pop Future<bool> didPopRoute() => Future<bool>.value(false); // 页面 push Future<bool> didPushRoute(String route) => Future<bool>.value(false); // 系统窗口相关改变回调，如旋转 void didChangeMetrics() { } // 文本缩放系数变化 void didChangeTextScaleFactor() { } // 系统亮度变化 void didChangePlatformBrightness() { } // 本地化语言变化 void didChangeLocales(List locale) { } //App 生命周期变化 void didChangeAppLifecycleState(AppLifecycleState state) { } // 内存警告回调 void didHaveMemoryPressure() { } //Accessibility 相关特性回调 void didChangeAccessibilityFeatures() {} } 其他回调相对简单，可以查看官方文档
生命周期回调
didChangeAppLifecycleState 回调函数中，有一个参数类型为 AppLifecycleState 的枚举类，这个枚举类是 Flutter 对 App 生命周期状态的封装。它的常用状态包括 resumed、inactive、paused 这三个。
- resumed：可见的，并能响应用户的输入；
- inactive：处在不活动状态，无法处理用户响应；
- paused：不可见并不能响应用户的输入，但是在后台继续活动中。
案例分享：在 initState 时注册来监听器，在 didChangeAppLifecycleState 回调方法中打印来当前的 App 状态，最后在 dispose 时把监听器移除：
class _MyHomePageState extends State with WidgetsBindingObserver { ... @override @mustCallSuper void initState() { super.initState(); WidgetsBinding.instance.addObserver(this); // 注册监听器 } @override @mustCallSuper void dispose() { super.dispose(); WidgetsBinding.instance.removeObserver(this); // 移除监听器 } @override void didChangeAppLifecycleState(AppLifecycleState state) async { print("$state"); if (state == AppLifecycleState.resumed) { // do sth } } } 尝试这切换一下前、后台，观察控制台输出的 App 状态，可以发现：
- 从后台切入前台，控制台打印的 App 生命周期变化如下：AppLifecycleState.paused -> AppLifecycleState.inactive -> AppLifecycleState.resumed;
- 从前台退回后台，控制台打印的 App 生命周期变化则变成了：AppLifecycleState.resumed -> AppLifecycleState.inactive -> AppLifecycleState.paused
帧绘制回调
除了需要监听 App 的生命周期回调做相应的处理之外，有时候还需要在组件渲染之后做一些与显示安全相关的操作。
在 iOS 开发中，可以通过 dispatch_async(dispatch_get_main_queue(),^{...}) 方法，让操作在下一个 RunLoop 执行；在 Android 开发中，可以通过 View.post() 插入消息队列，来保证在组件渲染后进行相关操作。
在 Flutter 中实现同样的需求会更简单： 依然使用万能的 WidgetsBinding 来实现。
WidgetsBinding 提供了单次 Frame 绘制回调，以及实时 Frame 绘制回调两种机制，来分别满足不同的需求：
- 单次 Frame 绘制回调，通过 addPostFrameCallback 实现。它会在当前 Frame 绘制完成后进行回调，并只会回调一次，如果要再次监听则需要再设置一次。
WidgetsBinding.instance.addPostFrameCallback((_){ print(" 单次 Frame 绘制回调"); // 只回调一次 }); - 实时 Frame 绘制回调，则通过 addPersistentFrameCallback 实现。这个函数会在每次绘制 Frame 结束后进行回调，可以用作 FPS 检测。
WidgetsBinding.instance.addPersistentFrameCallback((_){ print(" 实时 Frame 绘制回调"); // 每帧都回调 });