flutter 生命周期和树

程序的入口

类似iOS开发中的main方法一样

int main(int argc, char * argv[]) {
    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
    }
}

flutter工程也是通过main方法启动:

void main() => runApp(MyApp());

这里的runApp方法我们点击去看源码实现:

void runApp(Widget app) {
  WidgetsFlutterBinding.ensureInitialized()
    ..scheduleAttachRootWidget(app)
    ..scheduleWarmUpFrame();
}

看代码字面大致意思就是做了一系列的初始化操作,并将传入的app这个widget设置成了widget树的根节点.更深入的源码解析这里不做讨论.

Widget的生命周期

StatelessWidget

StatelessWidget比较简单我们一般只需要关注两个方法:

构造方法: 可以在这里初始化一些数据,做一些初始化操作
build方法: 布局业务代码

StatefulWidget

StatefulWidget不是单独使用的, 一个StatefulWidget会关联一个对应State.在开发层面上讨论StatefulWidget生命周期基本上看的就是state的生命周期
state各状态回调方法如下:
initState: 当widget第一次被插入到widget树中的时候会被调用.Flutter framework只会调用一次该回调.通常在此方法中做一些初始化操作.
dispose(): 与initState相对应,当state对象从树中被移除的时候回触发此回调.通常在此方法中释放一些资源.
reassemble(): 热重载回调, 只在开发模式下会触发.
didUpdateWidget(): 在widget重构时会触发该回调.
didChangeDependencies(): 当State对象的依赖发生变化时会被调用,最常见的就是当我们使用了InheritedWidget时, InheritedWidget发生改变时, 它的所有子widget都会触发该回调方法.
deactivate(): widget从树中被移除时会调用.
build():

initState()之后
调用setState()之后
调用didUpdateWidget()之后
调用didChangeDependencies()之后
widget被移除后重新插入widget树中

以上情况都会触发build回调方法.

Widget, Element, RenderObject

首先widget仅仅只是用来描述UI的. 而最终的Layout、渲染都是通过RenderObject来完成的. 负责在中间协调二者的就是Element

所以Flutter的UI系统包含三棵树：Widget树、Element树、渲染树.

image

Element树根据Widget树生成, 渲染树又依赖于Element树生成.

StatelessWidget 源码分析

当我们创建一个StatelessWidget时, flutter会在适当的时机调用createElement()方法创建一个StatelessElement. 并会将widget传递进去,让element持有.

abstract class StatelessWidget extends Widget {
  @override
  StatelessElement createElement() => StatelessElement(this);
}

在StatelessElement中,调用build()方法时会调用widget.build方法.

class StatelessElement extends ComponentElement {
  Widget build() => widget.build(this);
}

而这个widget.build方法正是暴露出来给开发者自己实现的回调:

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    // your code ...
  }
}

看到这里会有个疑问,2步widget.build(this)里的this是StatelessElement类型, 而3步中回调传递过来的是BuildContext类型的context. StatelessElement是否就是BuildContext呢?
我们看下继承关系:

class StatelessElement extends ComponentElement {}
abstract class ComponentElement extends Element {}
abstract class Element extends DiagnosticableTree implements BuildContext {}

StatelessElement 继承自ComponentElement, 而ComponentElement继承自Element. Element又实现了BuildContext接口.所以我们可以粗暴的认为build方法传过来的BuildContext就是这个widget对应的Element.

StatefulWidget

同StatelessWidget一样,在初始化一个StatefulWidget时, 内部也会调用createElement()方法, 创建一个StatefulElement.

abstract class StatefulWidget extends Widget {
  @override
  StatefulElement createElement() => StatefulElement(this);
}

构造StatefulElement和StatelessElement对比有部分差异,

创建StatefulElement时,内部调用了widget.createState()并持有它.这也解释了为什么我们实现一个继承于StatefulWidget时一定要实现它的createState方法.因为创建StatefulElement时会调用该方法来创建对应的state对象.

StatefulElement的build方法里直接调用的是state.build(),这也解释了为什么我们创建一个StatefulWidget时把布局的代码写在了state的build里,而不是widget的build里.

RenderObjectWidget

上面源码看了半天好像只看到了Widget和Element之间的关系.并没有提及到RenderObject.只有继承RenderObjectWidget的部件才会创建RenderObject, 而StatelessWidget和StatefulWidget是直接继承的Widget.

abstract class RenderObjectWidget extends Widget {
  @override
  RenderObjectElement createElement();

  @protected
  RenderObject createRenderObject(BuildContext context);
}

可以看到RenderObjectWidget除了createElement还多了一个createRenderObject方法

createRenderObject是何时调用的呢, 点进RenderObjectElement可以看到

RenderObjectElement内部会在mount方法里调用widget.createRenderObject. 至于mount何时调用,这个是Flutter framework内部自己控制的.我们不需要关心.

因为:StatelessWidget和StatefulWidget没有生成RenderObject的方法。所以他们只是个中间层，它需要实现build方法或者是state的build来返回子Widget.可以点击源码去看StatelessWidget里有定义build方法, StatefulWidget对应的State里也有build方法. 但是RenderObjectWidget里是没有build方法的.

暂时对flutter理解就是这么多.