Question

在性能方面，使用StatelessWidget与function returning a Widget有什么区别吗？

我至少知道flutter's repo issue中指出的与性能无关的差异。

事实是，我有一些同事声称functional widgets在性能方面是最差的，但是在阅读了一些有关该主题的知识后，我找不到任何可以断言该结论的结论性文件，因此对此事的澄清将非常受欢迎！

据我所知，它们之间的唯一区别在于使用const Widget的情况，这似乎可以避免重建阶段。

Answer 1

首先，我想指出一个包可用于通过函数functional_widget

来制作StatelessWidget

获得性能不一定是正确的。这取决于您如何使用小部件，主要取决于您如何使用它们来管理状态。

默认情况下，与不利用其功能的应用程序中的功能相对时，类可能会降低性能。

真正的问题是：他们的力量是什么？

简单：类可以彼此独立更新。功能不能

类可能会部分更新小部件树。

考虑一个可重建每一帧并返回其子级的小部件：

class InfiniteLoop extends StatefulWidget {
  const InfiniteLoop({Key key, this.child}) : super(key: key);
  final Widget child;
  @override
  _InfiniteLoopState createState() => _InfiniteLoopState();
}

class _InfiniteLoopState extends State<InfiniteLoop> {
  @override
  Widget build(BuildContext context) {
    WidgetsBinding.instance.addPostFrameCallback((_) => setState(() {}));

    return widget.child;
  }
}

现在，如果我们将整个应用程序包装在该小部件中，会发生什么？

void main() => runApp(InfiniteLoop(child: MyApp()));

没事

当然，您将拥有一个经常在树中重建的小部件。但实际上，build的{{1}}方法仅被调用一次。

那是因为当窗口小部件的实例不变时，Flutter能够中止树的重建。

班级可能会滥用此优化。

使用类，可以巧妙地将窗口小部件树的重建分成独立的部分。

列出一个类允许的所有潜在优化因素是不合理的，因为太多了。

下面的示例是一个小部件，它使用MyApp并将其格式化为int。问题是，如果Text通过了更改，则此窗口小部件将仅重建：

int

之所以可行，是因为Flutter使用class Counter extends StatelessWidget { const Counter({Key key, this.value}) : super(key: key); final int value; @override Widget build(BuildContext context) { return Text(value.toString()); } @override bool operator ==(Object other) => identical(this, other) || (other is Counter && other.value == value); @override int get hashCode => value.hashCode; }运算符来知道小部件是否应该更新（因此，==构造函数是一个很好的优化因素）。

这不是唯一的解决方案，但这是函数无法完成的一个很好的例子。

StatelessWidget与在性能方面返回Widget的函数

1 个答案: