开发者在进行Flutter开发时，大部分工作基本上少不了与StatelessWidget和StatefulWidget打交道。大家是否真的了解StatelessWidget和StatefulWidget?
讨论
我阅读了很多网上的文章，大部分会讲解两者的使用上的区别，一部分文章有解释这两者的区别。但是他们的解释有的是字面解释，有的是浅尝辄止，有的甚至是有一定的误导。
列出网上一些文章中的解释：
- 如果我们的Widget是StatelessWidget，那么当他的内容被创建出来之后，就不能再改变了。相反StatefulWidget就可以。
- 无状态Widget，就是说一旦这个Widget创建完成，状态就不允许再变动。有状态Widget，就是说当前Widget创建完成之后，还可以对当前Widget做更改，可以通过setState函数来刷新当前Widget来达到有状态。
- StatelessWidget是一个不需要状态更改的widget，它没有要管理的内部状态。StatefulWidget是可变状态的widget。
如果你对上述一些观点很认同的话，我觉得阅读本篇文章应该可以给你提供一个不一样的理解视角。
Widget
我们要比较StatelessWidget和StatefulWidget的区别，我们得先知道什么是Widget。
官方对Widget的解释是：
A widget is an immutable description of a part of a user interface.
即Widget是部分界面的不可变的描述信息。
重要的事情说三遍：
Widget是不可变的;
Widget是不可变的;
Widget是不可变的。
我们从代码上看看Widget如何实现的不可变。Widget的代码如下：
@immutable
abstract class Widget extends DiagnosticableTree {
const Widget({ this.key });
final Key? key;
// 省略...
}
我们可以看到Widget左上角有一个@immutable注解，这个注解的意思是所有的属性必须是final修饰，也就是Widget一旦初始化以后，其属性将不可变。
接下来我们再看看StatelessWidget和StatefulWidget的官方解释和相关代码：
StatelessWidget --- A widget that does not require mutable state.
abstract class StatelessWidget extends Widget {
const StatelessWidget({ Key? key }) : super(key: key);
@override
StatelessElement createElement() => StatelessElement(this);
@protected
Widget build(BuildContext context);
}
StatefulWidget --- A widget that has mutable state.
abstract class StatefulWidget extends Widget {
const StatefulWidget({ Key? key }) : super(key: key);
@override
StatefulElement createElement() => StatefulElement(this);
@protected
@factory
State createState();
}
Widget总结
- StatelessWidget和StatefulWidget没有本质区别，他们的所有属性都是不可变的。它们都没法更新，除非用一个新的Widget去替换它们。
- StatefulWidget拥有一个可变的State。
这样我们就得到了一个结论：StatelessWidget和StatefulWidget的区别就在这个可变的State了。
新的问题又来了，这个State扮演了什么作用呢？
State
我们进行界面的修改，一般会调用state.setState()方法。那这个方法是如何实现界面元素修改的呢？
void setState(VoidCallback fn) {
final dynamic result = fn() as dynamic;
_element!.markNeedsBuild();
}
setState方法很简单:
- 执行传入的函数;
-
_element调用了markNeedsBuild方法。
void markNeedsBuild() {
if (dirty)
return;
_dirty = true;
owner!.scheduleBuildFor(this);
}
-
_element把自己的_dirty属性设置为true; -
BuildOwner调用
scheduleBuildFor方法。
void scheduleBuildFor(Element element) {
if (!_scheduledFlushDirtyElements && onBuildScheduled != null) {
_scheduledFlushDirtyElements = true;
// 1
onBuildScheduled!();
}
_dirtyElements.add(element);
element._inDirtyList = true;
}
-
BuildOwner调用
onBuildScheduled方法；
内容回顾：
onBuildScheduled方法是在WidgetsBinding的initInstances中初始化的,一系列调用后最后调用的就是scheduleFrame请求Native Platform要刷新界面。
- 将element加入到dirtyElements中。
在合适的时候Flutter Engine会回调SchedulerBinding的handleDrawFrame方法，最后会调用BuildOwner的buildScope方法。
void buildScope(Element context, [ VoidCallback? callback ]) {
int dirtyCount = _dirtyElements.length;
int index = 0;
while (index < dirtyCount) {
_dirtyElements[index].rebuild();
}
}
遍历dirtyElements元素，每个element调用rebuild。
rebuild的作用是什么？没错，就是我们开头提到的对界面元素进行更新的操作。
刷新渲染的具体逻辑，我将会在后续文章中详细介绍，这里没法详细展开。
结论
StatelessWidget和StatefulWidget的本质区别就是能否自我重新构建(self rebuild)。
一些思考
- 既然StatefulWidget的主要作用只是为了赋予了其自我重新构建(self rebuild)的能力，那为什么需要State呢？
Widget依赖于构造函数和Build方法中的
BuildContext中的外部信息，如果是外部触发的Build(例如：祖先Widget build)，所有信息都是完整的。如果self rebuild则无法获取更新后的外部信息，所以需要内部维护一份不依赖于外部的信息，State就是这个作用。
- 既然StatefulWidget的功能更完善，为什么又提供一个StatelessWidget呢？
这个问题其实等同于为什么官方要限制我们使用self rebuild？每次Build都需要新建和销毁大量的Widget，Element Tree的diff，甚至繁重的渲染和重绘。官方推荐使用StatelessWidget，其实就是为了性能的考虑而对开发者进行的一些约束，限制开发者无节制的使用self rebuild造成的性能降低。
- 可不可以在开发中全部都使用StatefulWidget？
当然可以，但是不推荐，理由见上个问题。
- 可不可以在开发中全部都使用StatelessWidget？
如果是显示简单的不变的内容可以这样使用，但是这种场景太少了。至少在App应用中不太可能。
- 开发中如何选择StatelessWidget还是StatefulWidget？
首选StatelessWidget，当无法满足需求的时候用VS Code或者Android Stutio的快捷键将其变成StatefulWidget。
实战分享
我们前面比较了StatelessWidget和StatefulWidget的区别，进行了一些分析，到底如何写出更好更优化的代码，现在我们就用Flutter官方的计数器Demo来练练手。
通过前面的分析，我们知道点击FloatingActionButton会调用_MyHomePageState的setState进行rebuild。如下图所示：
细心的你可能发现问题了，我只是想修改Scaffold->Body->Center->Column->第二个Text中的文字。而Build的起点是Scaffold，这么长的构建链条相当于修改一个文字，把整个页面都重新构建了一次。就显然是一个无法忽视的问题。
注意：真实的Build链条不是我上面列的这么短，因为Scaffold等都进行了封装，真实的Build得进入他们的
build方法去了解，真实的Build链条比我们代码中看到的Scaffold->Body->Center->Column->第二个Text这个逻辑复杂多了。
修改的思路就是我们只需要在第二个Text上封装一个StatefulWidget，让这个StatefulWidget的setState去触发第二个Text的文字修改。
我们抽提一个CounterText：
class CounterText extends StatefulWidget {
final _CounterTextState state = _CounterTextState();
CounterText({
Key key,
}) : super(key: key);
@override
_CounterTextState createState() => state;
}
class _CounterTextState extends State<CounterText> {
int _counter = 0;
void _incrementCounter() {
setState(() {
_counter++;
});
}
@override
Widget build(BuildContext context) {
return Container(
child: Text(
'$_counter',
style: Theme.of(context).textTheme.headline4,
),
);
}
}
CounterText的使用：
MyHomePage({Key key, this.title}) : super(key: key);
final String title;
@override
_MyHomePageState createState() => _MyHomePageState();
}
class _MyHomePageState extends State<MyHomePage> {
CounterText counterText = CounterText();
@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(
title: Text(widget.title),
),
body: Center(
child: Column(
mainAxisAlignment: MainAxisAlignment.center,
children: <Widget>[
Text(
'You have pushed the button this many times:',
),
counterText,
],
),
),
floatingActionButton: FloatingActionButton(
onPressed: counterText.state._incrementCounter,
tooltip: 'Increment',
child: Icon(Icons.add),
),
);
}
}
这样就改造完成了。
总结：
我们需要对StatelessWidget和StatefulWidget有一个全面的了解，才能正确的使用他们。欢迎一起探讨和学习。
