导语
相信读完本文你将收获：最详细的生命周期分析
作者：
引言
一次面试过程中：
面试官：小伙子，不错嘛，看你简历上写你熟悉Flutter framework层啊！
我：是的，是的（心虚）。
面试官：那好，那你和我说说State的生命周期吧。
就这？我不假思索的脱口而出：initState，build，deactive，dispose。
面试官：噢，就这几个么？
我(小心翼翼): .....哦 好像还有didChangeDependencies?
面试官：还有么？
我：还有么？？？
面试官：那你说说他们什么时候会被回调吧？
我：............. 你就在此处不要动。待我去给你买个橘子（康康源码）。
无论是原生还是Native，组件的生命周期一定是面试中必问的一个一个知识点，根据面试官的水平，程度可深可浅。但对于开发者而言，理解控件的生命周期回调过程，明白每个函数的回调时机，能加深我们对于framework层的理解，掌握到flutter背后的原理。
1、初识State的生命周期
以"Flutter 生命周期"为关键词，可以搜到相关很多博客，这张图就是被反复引用的一个流程图。咋眼一看，好像啥都有，但如果深究一下比如：为什么这些生命周期是如何被回调？图中说的“组件状态改变”调用didUpdateWidget()是什么状态改变？却又无法回答。下面我们从一个demo和大家重新认识Flutter的生命周期。
如图，是一个极为简单的demo，页面一开始展示一个Text（我是第一次build的Text）。下方有一个按钮，点击之后调用setState()切换到SecondWidget。
而第SecondWidget是一个StatefulWidget，里面只是简单的返回了一个Text（ 我是被包裹在Stateful中的Text）。我们以setState()过程为例关注SecondWidget的生命周期，分为三种情况。
情况1：第一次setState() -> State第一次展示
当我们第一次点击按钮调用setState()的时候，直接来看其实只是相当于将Container下面的child由Text更改为SecondWidget。
在原来我一直在错误的使用 setState()中分析过，调用setState()之后其实会对从当前节点开始，他的所有子孙节点调用updateChild(Element child, Widget newWidget, dynamic newSlot)。
总的来说，这个方法会根据之前挂载在UI树上的_child以及再次调用build()出来的newWidget对象，共有四种情况
- 如果之前的位置child为null
- A、如果newWidget为null的话，说明这个位置始终没有子节点，直接返回null即可。
- B、如果newWidget不为null，说明这个位置新增加了子节点调用inflateWidget(newWidget, newSlot)生成一个新的Element返回
- 如果之前的child不为null
- C、如果newWidget为null的话，说明这个位置需要移除以前的节点，调用
deactivateChild(child)移除并且返回null- D、如果newWidget不为null的话，先调用
Widget.canUpdate(child.widget, newWidget)对比是否能更新。这个方法会对比两个Widget的runtimeType和key，1、如果一致则说明子Widget没有改变，只是需要根据newWidget(配置清单)更新下当前节点的数据child.update(newWidget)；2、如果不一致说明这个位置发生变化，则deactivateChild(child)后返回inflateWidget(newWidget, newSlot)
对应到我们的demo中，对于Container而言，在调用setState()之前，他的child是Text所以满足不为空的条件，而setState将child改为了SecondWidget，但是Text和新生成的SecondWidget并非同一种类型，所以会走到条件D的case2中，执行两个流程1、Text的deactivateChild(child)；2、SecondWidget的inflateWidget(newWidget, newSlot),我们重点关注SecondWidget。
@protected
Element inflateWidget(Widget newWidget, dynamic newSlot) {
//创建一个element对象
final Element newChild = newWidget.createElement();
newChild.mount(this, newSlot);
return newChild;
}
一开始会先根据SecondWidget创建一个Element对象，之后调用newChild.mount(this, newSlot)。
@override
void mount(Element parent, dynamic newSlot) {
_parent = parent;
_slot = newSlot;
_depth = _parent != null ? _parent.depth + 1 : 1;
_active = true;
_firstBuild();
}
mount()这个过程即将widget插入UI树中，做一些标志位的赋值，之后调用_firstBuild()。
@override
void _firstBuild() {
assert(_state._debugLifecycleState == _StateLifecycle.created);
try {
_debugSetAllowIgnoredCallsToMarkNeedsBuild(true);
//首先调用initState()
final dynamic debugCheckForReturnedFuture = _state.initState() as dynamic;
return true;
}());
} finally {
_debugSetAllowIgnoredCallsToMarkNeedsBuild(false);
}
//其次调用didChangeDependencies()
_state.didChangeDependencies();
assert(() {
_state._debugLifecycleState = _StateLifecycle.ready;
return true;
}());
//在super中执行当前state的build
super._firstBuild();
}
这个方法在StateElement中被重写，是生命周期的关键所在。如字面意义，他表示第一次构建的时候调用的方法。在这个过程中我们清晰的看出State对象会经历三个回调：
1、_state.initState()
2、_state.didChangeDependencies()
3、 super._firstBuild()最终调用state.build(this)
这个过程结束之后SecondWidget生成的Element对象已经被我们插入到了UI树中，之后渲染流程中，将其展示到屏幕上。
总结：当我们一个StatefulWidget第一次被渲染到屏幕上时,在State中会经历initState()，didChangeDependencies()，build(BuildContext context)三个方法。
情况二：第二次setState() -> State被刷新
假如现在SecondWidget已经被渲染到屏幕上了之后，如果我们再次点击调用setState()。这时会发现，对于Container节点而言，他的child不为空，且始终都是SecondWidget，并且由于我们没指定key对象，所以Widget.canUpdate(child.widget, newWidget)是返回true，对应上面条件D的case1执行child.update(newWidget)
@override
void update(StatefulWidget newWidget) {
super.update(newWidget);
final StatefulWidget oldWidget = _state._widget;
_dirty = true;
_state._widget = widget;
try {
//1、先调用didUpdateWidget(oldWidget)
final dynamic debugCheckForReturnedFuture = _state.didUpdateWidget(oldWidget) as dynamic;
} finally {
_debugSetAllowIgnoredCallsToMarkNeedsBuild(false);
}
//2、调用rebuild()
rebuild();
}
这个过程也非常清晰，在第二次调用setState()中，state会经历两个回调：
1、_state.didUpdateWidget(oldWidget)
2、state.build(this)
但不仅如此，如果在SecondWidget中使用dependOnInheritedWidgetOfExactType()方法依赖了来自顶层的InheritedWidget数据之时。如果InheritedWidget发生了update()，会先调用所有依赖这个InheritedWidget对象中的didChangeDependencies()（详情可以学习InheritedWidget的依赖更新机制）。并且由于当前的widget一般作为子节点，所以也会执行上面的update()过程
总结：
- 如果第二次调用setState()，当前的state对象会走：1、didUpdateWidget()；2、build()
- 如果是依赖的顶层
InheritedWidget发生了改变，则会调用1、didChangeDependencies()； 2、didUpdateWidget()；3、build()
情况三：SecondWidget被移除 -> State被移除
第三种情况可以参考情况一种被移除的Text对象，我们提到，当一个State被移除的时候会调用其deactivateChild(Element child)方法
@protected
void deactivateChild(Element child) {
child._parent = null;
child.detachRenderObject();
owner._inactiveElements.add(child); // this eventually calls child.deactivate()
}
这个方法会将当前的对象添加到一个_inactiveElements集合中，并且最终调用deactivate()。
之后在下一帧绘制回调到finalizeTree()的时候，执行unmount()彻底清理。
@override
void unmount() {
super.unmount();
_state.dispose();
_state._element = null;
_state = null;
}
总结：
当当前的Widget从屏幕移除的时候回先调用deactivate()，之后在下一帧绘制之前清理UI树的时候被彻底清理，回调dispose()
总结
读完源码后，我给面试官这样说道：
state的生命周期其实可以用这么一张图理解：
- 1、第一次展示到屏幕上时会依次调用当前element的构造函数,initState,didChangeDependencies,build
- 2、如果只是自己发生了更新，则只会回调build。如果当前对象的父节点发生更新，则会调用didUpdateWidget和build。如果依赖的InheritedWidget发生了改变，则还会先回调didChangeDependencies。
- 3、当widget被移除的的时候，会依次调用deactive和dispose
面试官直呼内行，当即给了我ssp的offer。
结果收到offer邮件的时候，闹钟醒了.....
(to be continued )
最后
听说点赞的人面试，HR必发ssp offser哦
网友评论