一. Flutter的渲染流程
1.1. Widget - Element - RenderObject关系
1.2. Widget是什么？
官方对Widget的说明：
- Flutter的Widgets的灵感来自React，中心思想是构造你的UI使用这些Widgets。
- Widget使用配置和状态，描述这个View（界面）应该长什么样子。
- 当一个Widget发生改变时，Widget就会重新build它的描述，框架会和之前的描述进行对比，来决定使用最小的改变（minimal changes）在渲染树中，从一个状态到另一个状态。
自己的理解：
- Widget就是一个个描述文件，这些描述文件在我们进行状态改变时会不断的build。
- 但是对于渲染对象来说，只会使用最小的开销来更新渲染界面。
1.3. RenderObject
官方对RenderObject的描述：
- 渲染树上的一个对象。
- RenderObject层是渲染库的核心。
Flutter引擎渲染的时候，其实渲染的是RenderObjectTree，但是widget和RenderObject并不是一一对应的，为什么呢？因为有些widget其实就是一个盒子，将其他widget装到一起的。
就比如我们常用的 Text 继承于 StatelessWidget，我们知道，只要继承于StatelessWidget或者继承于StatefulWidget，就要看它的build方法，看过build方法之后我们发现它最后返回一个RichText，这个RichText继承于MultiChildRenderObjectWidget这才是最终渲染的widget。
1.4. Element是什么？
官方对Element的描述：
- Element是一个Widget的实例，在树中详细的位置。
- Widget描述和配置子树的样子，而Element实际去配置在Element树中特定的位置。
Element其实就相当于React中的虚拟DOM，我们先来理解一下前端里面的虚拟DOM。
当我们书写js生成的HTML代码，这时候会直接操作真实的DOM，操作真实DOM是非常消耗性能的，所以React和Vue都有虚拟DOM的概念，什么意思呢？就是当我们通过js操作HTML，我们会先去操作虚拟DOM，虚拟DOM中通过diff算法，判断哪些DOM需要修改，甚至不需要修改，最后把虚拟DOM打个补丁到真实DOM上，这样做的好处就是我们可以以最小的开销来更新真实的DOM。
我们再看一下上面的三棵树，Widget就相当于HTML代码，Element就相当于虚拟DOM，Render就相当于真实DOM。
当我们创建一个Widget的时候，我们也许就不需要创建一个新的Render对象，我们先去看看保存的Element的类型和key是否一致，如果一致，就直接修改属性即可，这样我们就没必要创建新的Render Object，也许只是修改其中某个属性就行，这样就做到了以最小的开销来更新Render Object。
二. 源码查看对象的创建过程
我们先给widget做个分类：
这些是组件Widget，不会生成RenderObject
Container()
Text()
HYHomeContent()
这些是渲染Widget，会生成RenderObject
Padding()
Row()
我们这里以Padding为例，Padding是用来设置内边距，我们看看这个Widget最后怎么生成RenderObject的。
2.1. Widget
Padding是一个Widget，并且继承自SingleChildRenderObjectWidget
继承关系如下：
Padding -> SingleChildRenderObjectWidget -> RenderObjectWidget -> Widget
Container继承关系如下：
Container -> StatelessWidget -> Widget
我们之前在创建Widget时，经常使用StatelessWidget和StatefulWidget，这种Widget只是将其他的Widget在build方法中组装起来，并不是一个真正可以渲染的Widget（在之前的课程中其实有提到）。
在Padding的类中，我们找不到任何和渲染相关的代码，这是因为Padding仅仅作为一个配置信息，这个配置信息会随着我们设置的属性不同，频繁的销毁和创建。
问题：频繁的销毁和创建会不会影响Flutter的性能呢？
- 并不会，答案在我的另一篇文章中；
- https://mp.weixin.qq.com/s/J4XoXJHJSmn8VaMoz3BZJQ
那么真正的渲染相关的代码在哪里执行呢？
- RenderObjectWidget
2.2. RenderObjectWidget
我们来看Padding里面的代码，有一个非常重要的方法：
- 这个方法其实是来自RenderObjectWidget的类，在这个类中它是一个抽象方法；
- 抽象方法是必须被子类实现的，但是它的子类SingleChildRenderObjectWidget也是一个抽象类，所以可以不实现父类的抽象方法；
- 但是Padding不是一个抽象类，必须在这里实现对应的抽象方法，而它的实现就是下面的实现；
@override
RenderPadding createRenderObject(BuildContext context) {
return RenderPadding(
padding: padding,
textDirection: Directionality.of(context),
);
}
上面的代码创建了什么呢？RenderPadding
RenderPadding的继承关系是什么呢？
RenderPadding -> RenderShiftedBox -> RenderBox -> RenderObject
我们来具体查看一下RenderPadding的源代码：
- 如果传入的_padding和原来保存的value一样，那么直接return；
- 如果不一致，调用_markNeedResolution，而_markNeedResolution内部调用了markNeedsLayout；
- 而markNeedsLayout的目的就是标记在下一帧绘制时，需要重新布局performLayout；
- 如果我们找的是Opacity，那么RenderOpacity是调用markNeedsPaint，RenderOpacity中是有一个paint方法的；
set padding(EdgeInsetsGeometry value) {
assert(value != null);
assert(value.isNonNegative);
if (_padding == value)
return;
_padding = value;
_markNeedResolution();
}
2.3. Element
我们来思考一个问题：
- 之前我们写的大量的Widget在树结构中存在引用关系，但是Widget会被不断的销毁和重建，那么意味着这棵树非常不稳定；
- 那么由谁来维系整个Flutter应用程序的树形结构的稳定呢？
- 答案就是Element。
- 官方的描述：Element是一个Widget的实例，在树中详细的位置。
我们再研究Padding是怎么创建Element的，我们进入Widget类里面，发现有个createElement()方法：
@protected
@factory
Element createElement();
因为Widget是个抽象类，所以createElement方法必须被它的子类实现。我们也可以得出一个结论，只要你是一个widget，无论是不是渲染的widget，都要实现createElement方法，只不过每个类实现的不一样。
我们发现，对于Padding，是父类SingleChildRenderObjectWidget实现了这个方法，最后返回的是SingleChildRenderObjectElement。
@override
SingleChildRenderObjectElement createElement() => SingleChildRenderObjectElement(this);
对于Container，也是它的父类StatelessWidget实现了createElement方法：
@override
StatelessElement createElement() => StatelessElement(this);
同理，StatefulWidget也实现了createElement方法：
@override
StatefulElement createElement() => StatefulElement(this);
它们返回的对象不同，一个是StatelessElement，一个是StatefulElement，只不过都继承于ComponentElement。它们的区别就是StatefulElement会多一个state属性。
小总结：
- 我们写一个widget
- 对于渲染widget会创建RenderObject
- 每一个widget都会创建一个Element对象
- 在创建完一个Element之后，Flutter引擎会调用mount方法来将Element插入到树中具体的位置
Element什么时候创建？
在每一次创建Widget的时候，会创建一个对应的Element，然后将该元素插入树中。
在SingleChildRenderObjectWidget中，我们可以找到如下代码：
- 在Widget中，Element被创建，并且在创建时，将this（Widget）传入了，Element就保存了对Widget的应用；
@override
SingleChildRenderObjectElement createElement() => SingleChildRenderObjectElement(this);
在创建完一个Element之后，Flutter引擎会调用mount方法来将Element插入到树中具体的位置，再Element类中我们会找到如下代码：
进入ComponentElement源码，查看ComponentElement的mount的执行过程，代码比较繁琐，可以直接看下面总结。
abstract class ComponentElement extends Element {
/// Creates an element that uses the given widget as its configuration.
ComponentElement(super.widget);
Element? _child;
bool _debugDoingBuild = false;
@override
bool get debugDoingBuild => _debugDoingBuild;
@override
// 1. 调用mount方法
void mount(Element? parent, Object? newSlot) {
super.mount(parent, newSlot);
assert(_child == null);
assert(_lifecycleState == _ElementLifecycle.active);
// 2. 调用_firstBuild
_firstBuild();
assert(_child != null);
}
void _firstBuild() {
// StatefulElement overrides this to also call state.didChangeDependencies.
// 3. 调用rebuild
rebuild(); // This eventually calls performRebuild.
}
/// Calls the [StatelessWidget.build] method of the [StatelessWidget] object
/// (for stateless widgets) or the [State.build] method of the [State] object
/// (for stateful widgets) and then updates the widget tree.
///
/// Called automatically during [mount] to generate the first build, and by
/// [rebuild] when the element needs updating.
@override
@pragma('vm:notify-debugger-on-exception')
// 6. 这是performRebuild
void performRebuild() {
assert(_debugSetAllowIgnoredCallsToMarkNeedsBuild(true));
// 8. 就是这个Widget
Widget? built;
try {
assert(() {
_debugDoingBuild = true;
return true;
}());
// 7. 调用build方法生成一个Widget
built = build();
assert(() {
_debugDoingBuild = false;
return true;
}());
debugWidgetBuilderValue(widget, built);
} catch (e, stack) {
_debugDoingBuild = false;
built = ErrorWidget.builder(
_debugReportException(
ErrorDescription('building $this'),
e,
stack,
informationCollector: () => <DiagnosticsNode>[
if (kDebugMode)
DiagnosticsDebugCreator(DebugCreator(this)),
],
),
);
} finally {
// We delay marking the element as clean until after calling build() so
// that attempts to markNeedsBuild() during build() will be ignored.
_dirty = false;
assert(_debugSetAllowIgnoredCallsToMarkNeedsBuild(false));
}
try {
_child = updateChild(_child, built, slot);
assert(_child != null);
} catch (e, stack) {
built = ErrorWidget.builder(
_debugReportException(
ErrorDescription('building $this'),
e,
stack,
informationCollector: () => <DiagnosticsNode>[
if (kDebugMode)
DiagnosticsDebugCreator(DebugCreator(this)),
],
),
);
_child = updateChild(null, built, slot);
}
}
/// Subclasses should override this function to actually call the appropriate
/// `build` function (e.g., [StatelessWidget.build] or [State.build]) for
/// their widget.
@protected
Widget build();
@override
void visitChildren(ElementVisitor visitor) {
if (_child != null) {
visitor(_child!);
}
}
@override
void forgetChild(Element child) {
assert(child == _child);
_child = null;
super.forgetChild(child);
}
}
// 4. 这是rebuild
void rebuild() {
assert(_lifecycleState != _ElementLifecycle.initial);
if (_lifecycleState != _ElementLifecycle.active || !_dirty) {
return;
}
Element? debugPreviousBuildTarget;
performRebuild();
}
/// Cause the widget to update itself.
///
/// Called by [rebuild] after the appropriate checks have been made.
@protected
// 5. 调用performRebuild
void performRebuild();
}
class StatelessElement extends ComponentElement {
/// Creates an element that uses the given widget as its configuration.
StatelessElement(StatelessWidget super.widget);
@override
// 9. 拿到widget,调用widget的build方法
// 这个widget就是创建element的时候传进来的widget
Widget build() => (widget as StatelessWidget).build(this);
@override
void update(StatelessWidget newWidget) {
super.update(newWidget);
assert(widget == newWidget);
_dirty = true;
rebuild();
}
}
上面1-9步，看起来比较复杂，其实就是：
mount方法 -> firstBuild -> rebuild -> performBuild -> build -> _widget的build
这里的_widget就是创建element的时候传进来的widget。
我们都知道build方法有个参数build(Build Context context)，所以这个context其实就是element，这个context最主要的作用就是告诉我们构建的element在树里面的哪个位置，之后可以沿着树去查找一些信息。
如果是statefulWidget，它里面的build方法如下：
@override
Widget build() => state.build(this);
我们发现，它之后调用了state.build(this)，而不是 (widget as StatelessWidget).build(this);
下面我们看看SingleChildRenderObjectElement的mount方法的调用过程。
在调用mount方法时，会同时使用Widget来创建RenderObject，并且保持对RenderObject的引用，创建完RenderObject之后再把RenderObject挂载到RenderObjectTree树的某个位置
@override
void mount(Element parent, dynamic newSlot) {
super.mount(parent, newSlot);
// 就是这行代码，创建RenderObject
_renderObject = widget.createRenderObject(this);
assert(() {
_debugUpdateRenderObjectOwner();
return true;
}());
assert(_slot == newSlot);
attachRenderObject(newSlot);
_dirty = false;
}
下面说一下StatefulElement，它是继承于ComponentElement的，所以ComponentElement有的方法，它都有。
StatefulElement(StatefulWidget widget)
// 1. 就是这里，调用了createState
: _state = widget.createState(),
super(widget) {
assert(() {
if (!state._debugTypesAreRight(widget)) {
throw FlutterError.fromParts(<DiagnosticsNode>[
ErrorSummary('StatefulWidget.createState must return a subtype of State<${widget.runtimeType}>'),
ErrorDescription(
'The createState function for ${widget.runtimeType} returned a state '
'of type ${state.runtimeType}, which is not a subtype of '
'State<${widget.runtimeType}>, violating the contract for createState.',
),
]);
}
return true;
}());
assert(state._element == null);
state._element = this;
assert(
state._widget == null,
'The createState function for $widget returned an old or invalid state '
'instance: ${state._widget}, which is not null, violating the contract '
'for createState.',
);
// 2. 然后将widget赋值给state里面的_widget
state._widget = widget;
assert(state._debugLifecycleState == _StateLifecycle.created);
}
上面主要做了两件事
- StatefulElement的构造器中调用了widget.createState()方法
- 将widget赋值给state里面的_widget，正是因为这样，我们在state里面才可以通过this.widget拿到对应的widget
总结：
- widget创建完之后，Flutter框架一定会根据widget创建一个element，创建完之后会调用element的mount方法，最后根据一系列的调用会调用widget的build(Build Context context)方法。
- 如果是renderElement，那么它的mount主要做的就是创建一个_renderObject
- 如果是StatefulElement，那么会调用调用了createState，然后将widget赋值给state里面的_widget
2.4. build的context是什么
在StatelessElement中，我们发现是将this传入，所以本质上BuildContext就是当前的Element。
Widget build() => widget.build(this);
我们来看一下继承关系图：
- Element是实现了BuildContext类（隐式接口）
abstract class Element extends DiagnosticableTree implements BuildContext
在StatefulElement中，build方法也是类似，调用state的build方式时，传入的是this。
Widget build() => state.build(this);
2.5. 创建过程小结
Widget只是描述了配置信息：
- 其中包含createElement方法用于创建Element；
- 也包含createRenderObject，但是不是自己在调用；
Element是真正保存树结构的对象：
- 创建出来后会由framework调用mount方法；
- 在mount方法中会调用widget的createRenderObject对象；
- 并且Element对widget和RenderObject都有引用；
RenderObject是真正渲染的对象：
- 其中有
markNeedsLayoutperformLayoutmarkNeedsPaintpaint等方法；
三. Widget的key
在我们创建Widget的时候，总是会看到一个key的参数，它又是做什么的呢？
3.1. key的案例需求
我们一起来做一个key的案例需求。
home界面的基本代码：
class _HYHomePageState extends State<HYHomePage> {
List<String> names = ["aaa", "bbb", "ccc"];
@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(
title: Text("Test Key"),
),
body: ListView(
children: names.map((name) {
return ListItemLess(name);
}).toList(),
),
floatingActionButton: FloatingActionButton(
child: Icon(Icons.delete),
onPressed: () {
setState(() {
names.removeAt(0);
});
}
),
);
}
}
注意：待会儿我们会修改返回的ListItem为ListItemLess或者ListItemFul。
3.2. StatelessWidget的实现
我们先对ListItem使用一个StatelessWidget进行实现：
class ListItemLess extends StatelessWidget {
final String name;
final Color randomColor = Color.fromARGB(255, Random().nextInt(256), Random().nextInt(256), Random().nextInt(256));
ListItemLess(this.name);
@override
Widget build(BuildContext context) {
return Container(
height: 60,
child: Text(name),
color: randomColor,
);
}
}
它的实现效果是每删除一个，所有的颜色都会发现一次变化。
- 原因非常简单，删除之后调用setState，会重新build，重新build出来的新的StatelessWidget会重新生成一个新的随机颜色。
3.3. StatefulWidget的实现（没有key）
我们对ListItem使用StatefulWidget来实现：
class ListItemFul extends StatefulWidget {
final String name;
ListItemFul(this.name): super();
@override
_ListItemFulState createState() => _ListItemFulState();
}
class _ListItemFulState extends State<ListItemFul> {
final Color randomColor = Color.fromARGB(255, Random().nextInt(256), Random().nextInt(256), Random().nextInt(256));
@override
Widget build(BuildContext context) {
return Container(
height: 60,
child: Text(widget.name),
color: randomColor,
);
}
}
我们发现一个很奇怪的现象，颜色不变化，但是数据向上移动了。
首先，我们知道，三个widget对应了三个StatefulElement，StatefulElement里面又有state指向对应的widget，然后我们调用setState的时候，widget树肯定全部都会重建，但是element不会重建，因为它会调用widget里面的canUpdate方法：
/// If the widgets have no key (their key is null), then they are considered a
/// match if they have the same type, even if their children are completely
/// different.
static bool canUpdate(Widget oldWidget, Widget newWidget) {
return oldWidget.runtimeType == newWidget.runtimeType
&& oldWidget.key == newWidget.key;
}
当从三个widget -> 两个widget的时候，会比较新旧widget的runtimeType和key，可以发现，最后肯定会返回true，所以三个state的前面两个不会重新创建，最后一个state没有对应的widget就会直接删掉(调用unmount)，这时候Element Tree里面就保留了前两个原来的element，然后将前两个element挂载到那两个新的widget上了，所以我们才看到删除最后一个的效果。
这里的意思其实就是state复用了，但是我们不希望这样，我们只需要绑定key就可以了。
3.4. StatefulWidget的实现（随机key）
我们使用一个随机的key，ListItemFul的修改如下：
class ListItemFul extends StatefulWidget {
final String name;
ListItemFul(this.name, {Key key}): super(key: key);
@override
_ListItemFulState createState() => _ListItemFulState();
}
home界面代码修改如下：
body: ListView(
children: names.map((name) {
return ListItemFul(name, key: ValueKey(Random().nextInt(10000)),);
}).toList(),
),
这一次我们发现，每次删除都会出现随机颜色的现象：
- 这是因为修改了key之后，Element会强制刷新，那么对应的State也会重新创建，这显然也不是我们想要的效果。
// Widget类中的代码
static bool canUpdate(Widget oldWidget, Widget newWidget) {
return oldWidget.runtimeType == newWidget.runtimeType
&& oldWidget.key == newWidget.key;
}
3.5. StatefulWidget的实现（name为key）
这次，我们将name作为key来看一下结果：
body: ListView(
children: names.map((name) {
return ListItemFul(name, key: ValueKey(name));
}).toList(),
),
达到了我们理想中的效果。
- 因为这是在更新widget的过程中根据key进行了diff算法
- 在前后进行对比时，发现bbb对应的Element和ccc对应的Element会继续使用，那么就会删除之前aaa对应的Element，而不是直接删除最后一个Element
总结：key的作用
- 指定name为key之后，进行diff算法的时候， 我们就可以指定删除哪个widget
- 我们使用随意的key，就可以实现强制刷新widget
- 开发中我们使用最多的就是指定name为key之后，达到复用的目的
3.6. Key的分类
Key本身是一个抽象，不过它也有一个工厂构造器，创建出来一个ValueKey，但是我们很少用ValueKey，我们一般用它的子类。
直接子类主要有：LocalKey和GlobalKey
- LocalKey，它应用于具有相同父Element的Widget进行比较，也是diff算法的核心所在；
- GlobalKey，通常我们会使用GlobalKey某个Widget对应的Widget或State或Element
3.6.1. LocalKey
LocalKey有三个子类
ValueKey：
- ValueKey是当我们以特定的值作为key时使用，比如一个字符串、数字等等
ObjectKey：
- 如果两个学生，他们的名字一样，使用name作为他们的key就不合适了
- 我们可以创建出一个学生对象，使用对象来作为key
UniqueKey：
- 使用随机数可以能随机到一样的数字，如果我们要确保key的唯一性，可以使用UniqueKey，它的本质是生成一个hashCode；
- 比如我们之前使用随机数来保证key的不同，这里我们就可以换成UniqueKey；
3.6.2. GlobalKey
GlobalKey可以帮助我们访问某个Widget的信息，包括Widget或State或Element等对象。
我们来看下面的例子：我希望可以在HYHomePage中直接访问HYHomeContent中name和_HYHomeContentState中的message。
直接看注释的步骤：
class HYHomePage extends StatelessWidget {
// 1. 创建一个GlobalKey
final GlobalKey<_HYHomeContentState> homeKey = GlobalKey();
@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(
title: Text("列表测试"),
),
// 3. 将homeKey传进去
body: HYHomeContent(key: homeKey),
floatingActionButton: FloatingActionButton(
child: Icon(Icons.data_usage),
onPressed: () {
// 4. 拿到_HYHomeContentState里面的message
print(homeKey.currentState.message); // abc
// 5. 调用_HYHomeContentState里面的test方法
homeKey.currentState.test() // test方法
// 6. 拿到HYHomeContent里面的name
print(homeKey.currentState.widget.name); // coderwhy
},
),
);
}
}
class HYHomeContent extends StatefulWidget {
final String name = "coderwhy";
// 2. 定义构造方法
HYHomeContent({Key key}): super(key: key);
@override
_HYHomeContentState createState() => _HYHomeContentState();
}
class _HYHomeContentState extends State<HYHomeContent> {
final String message = "abc";
void test() {
print("test方法")
}
@override
Widget build(BuildContext context) {
return Text(message);
}
}
