在Flutter中的Widget同Android中的Activity和iOS中的UIViewController一样,也是存在生命周期的,所谓的生命周期也就是回调函数,通过这些回调函数可以让我们知道当前Widget所处的状态;
生命周期的作用
当Widget出在不同的时间状态时,会有不同的生命周期回调函数执行,在这些回调函数中我们可以做不同的事情:
- 初始化数据
- 变量和常量的创建
- 网络请求的发送
- 监听
Widget的事件 - 内存的管理
- 数据或者监听者的销毁
- 定时器
TImer的销毁Widget的生命周期
众所周知,在Flutter中Widget分为:有状态和无状态两种,并且有状态Widget明显要比无状态Widget要复杂的多,那么他们的生命周期会不会有什么不同呢?StatelessWidget的生命周期
我们在界面上加载一个简单的StatelessWidget的页面,给页面传值title:

很明显,我们在Flutter中创建一个Widget的时候,使用的都是构造方法,比如此处的LessLifeCycleDemo的构造方法LessLifeCycleDemo(title: "无状态Widget生命周期"),而build是Widget渲染时会调用的方法;我们分别在两个方法中添加打印信息:
这是StatelessWidget的生命周期,其相对简单;我们接下来主要介绍一下StatefulWidget的生命周期;StatefulWidget的生命周期
我们编写如下代码,在我们已知的生命周期方法中添加打印信息:
最终打印顺序如下:
然后点击加号按钮:
在调用setState方法是,只有build方法会被触发执行;
目前我们使用到的生命周期的函数还比较少,除了目前所用的,还有其他周期函数:
didChangeDependencies():当State对象的依赖发生变化是被调用;典型的场景就是系统语言改变或者主题发生变化时,Flutter框架会通知Widget调用此回调;reassemble():此回调只在开发调试的过程中生效,在热重载hot reload时被调用,在Release模式下永远不会回调;didUpdateWidget():在Widget重新构建时,Flutter框架会调用widget.canUpdate来检测Widget树上同一位置的新旧两个节点,然后判断是否需要进行更新,如果返回true,则调用此回调;widget.canUpdate会在新旧widget的key和runtimeType同时相等时返回true;这个我们在后边渲染原理时会讲到;
deactivate():当State对象从树中被移除时,会调用此回调;在某些场景下,Flutter框架会将State对象重新插入到树中,比如包含此State对象的子树从树一个位置移动到另一个位置时(可通过GlobalKey来实现)。调用
initState()之后- 调用
didUpdateWidget()之后 - 调用
setState()之后 - 调用
didChangeDependencies()之后 - 把
State对象从树的一个位置移除后(会调用deactivate()),又重新插入到树的其他位置之后setState触发build的本质
我们都知道调用setState方法将会触发build方法的执行,那么为什么build方法会被执行呢?我们来看一下setState的源码:
我们可以看到setState方法的实现中,最重要的就是_element!.markNeedsBuild()方法,标记需要被渲染;那么_element是什么呢?我们从上文代码中可以看到:
_element本质上就是BuildContext,那么我们是否可以直接使用context调用markNeedsBuild方法来触发build呢?我们将代码修改如下:
运行结果:
build方法被触发;Android Studio中的一个bug
正常情况下,我们在编译器中打印的生命周期的信息只会执行一次,比如我们热重载的时候,方法执行如下:
但是,当我们重新执行项目的时候,却会出现下边的情况:
生命周期方法被调用了两次,这是Android Studio的一个bug,我们可以使用Xcode来验证一下,在Xcode中直接运行项目是不会出现这种情况的:
