Flutter - 生命周期

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> 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<MyHomePage> 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 绘制回调"); // 每帧都回调 });