Flutter(九)--Flutter中Widget刷新逻辑+源
2020-07-04 本文已影响0人
Henry________
Flutter中Widget刷新逻辑+源码解读
前言
我们都知道StatefulWidget可以进行页面刷新操作，而StatelessWidget并不具备这项功能，依旧在最开始抛出两个问题:
- 为什么只有StatefulWidget可以做页面更新操作？
- setState()之后是否是所有的组件都会重新创建？
首先我们看一下setState(fn)都做了什么~
abstract class State<T extends StatefulWidget>...{
void setState(VoidCallback fn) {
...
final dynamic result = fn() as dynamic;
_element.markNeedsBuild();
}
}
//在Element类中
{
void markNeedsBuild() {
...
if (dirty) //如果是已经标记为脏，则直接结束
return;
_dirty = true;
owner.scheduleBuildFor(this);
}
}
//owner属于BuildOwner类
class BuildOwner {
void scheduleBuildFor(Element element) {
...
_dirtyElements.add(element);
}
void buildScope(Element context, [ VoidCallback callback ]) {
...
while (index < dirtyCount) {
_dirtyElements[index].rebuild();
}
}
}
//而rebuild最终还是会回到我们熟悉的performRebuild方法里,除了最基本的build方法。
void performRebuild() {
...
built = build();
...
_child = updateChild(_child, built, slot);
}
目前还有一个问题buildScope这个方法是否是Flutter隐式调用的呢？有答案的同学可以指教指教。目前没找到调用的位置。
- 经过一系列调用，最终会到达到
updateChild这个方法里，目前为止当前包含当前Widget的Element就会进入到updateChild更新流程里。 -
_dirty这个参数的使用，我认为是非常优化的。即使你做出重复刷新的操作也不会导致页面的重复刷新。
在StatelessElement中并没有找到setState等刷新方法，所以无法支持刷新，回答了之前的问题一。虽然依旧可以以类似的方式实现为StatefulWidget的子类，但是会有问题，这里就不具体说明，可以参考Flutter文档Why is the build method on State, and not StatefulWidget?
现在来看看updateChild都做了什么~
// 只有类型相同且key相同的就是可以刷新的
static bool canUpdate(Widget oldWidget, Widget newWidget) {
return oldWidget.runtimeType == newWidget.runtimeType
&& oldWidget.key == newWidget.key;
}
Element updateChild(Element child, Widget newWidget, dynamic newSlot) {
//如果在widgetTree中当前widget被删除则直接结束,并在ElementTree中也删除它
if (newWidget == null) {
deactivateChild(child);
return;
}
...
Element newChild;
if (child != null) {
...
if (hasSameSuperclass && child.widget == newWidget) {
//如果相同则不进行updata操作
newChild = child;
} else if (hasSameSuperclass && Widget.canUpdate(child.widget, newWidget)) {
//如果可以更新则进行update操作
child.update(newWidget);
newChild = child;
}else{
//inflateWidget中会执行createElement这里就不多赘述了
newChild = inflateWidget(newWidget, newSlot);
}
}
}
void update(covariant Widget newWidget) {
...
_widget = newWidget;
}
Element inflateWidget(Widget newWidget, dynamic newSlot) {
...
final Element newChild = newWidget.createElement();
newChild.mount(this, newSlot);
}
- 其实update在很多类中都有实现，但是基本上都是大差不差。
- 通过调试发现widget的对比是通过widget的hash值来进行的，所以任何改动都会导致hash值不同。
- updateChild这个方法没有什么好说的，只是在canUpdate中发现如果不使用key，导致这个判断
oldWidget.key == newWidget.key默认为true。如果不想要进行复用的Widget则使用不同的key就可以实现。 -
update要注意方法中的_widget = newWidget，更新后会持有newWidget。 -
inflateWidget在遇到需要创建新的Element的时候，看到了上一篇遇到过的createElement,mount也佐证了之前的Widget创建到Element的创建过程。
通过对刷新部分的源码阅读发现，并不是所有的Widget都被会刷新、重新创建，某些可以更新的Widget还是可以update后复用的；某些hash值没有发生变化的则直接复用。
后序
- 整个源码阅读下来依旧发现Element这个中间者的设计是多么的巧妙，以及diff算法虽然看起来很简单但是其中逻辑是非常严谨的。
- 在这两部分的源码阅读发现，如果带着问题去阅读源码，不仅可以快速找到问题的原因；还能提高源码的阅读速度，因为可以排除一些无关的方法，不会毫无头绪。值得推荐。
