Performance 在后续的内置flatter中重用小部件可以吗？

我一直在四处搜索，并没有找到这个问题的合适答案：在随后的构建调用中重用小部件可以吗？我的意思是，我创建了一个

StatefulWidget

，并在构建函数中保留了对返回的小部件的内部引用。在以后的构建中（如果我确定自上次构建以来没有任何更改），我将返回最后一个小部件，而不是构建一个新的小部件

我知道应该避免这种情况，创建简单的构建并优化失效过程，这样复杂的小部件就不会被频繁地重建。但在某些情况下，我发现这是一个很好的解决办法

特别是在阅读时，声明：

当再次遇到与前一帧相同的子窗口小部件实例时，重建所有子窗口小部件的遍历将停止。该技术在框架内大量用于优化动画，动画不会影响子树。请参阅TransitionBuilder模式和SlideTransition的源代码，它使用此原则避免在设置动画时重建其子代

因此，这样做应该是可以接受的：

抽象类SmartState扩展状态{
小部件_lastBuild；
T_-previousWidget；
bool应该重建（T previousWidget）；
小部件doBuild（BuildContext）；
@凌驾
@超级
小部件构建（构建上下文）{
最终T previousWidget=\u previousWidget；
_previousWidget=widget；
if（previousWidget！=null&&u lastBuild！=null&&！shouldRebuild（previousWidget））{
返回上次构建；
}
_lastBuild=doBuild（上下文）；
返回上次构建；
}
}

作为一个小背景，我打算在一个列表项中扩展这个类。列表本身有时会发生变化，并使用新项重建，尽管大多数项保持不变，但我只是重新排列、删除或添加了一些。还要注意，由于设计要求，我不得不将它们放在一个

Wrap

小部件中

---

那么有没有人有比这更好的解决方案呢。最重要的是，我想知道这样的重用被认为是好的还是好的实践。谢谢

您不必与框架抗争，Flatter内部使用canUpdate（）方法等方法负责重建。

以及减少生成方法调用的解决方案。实际上，您正在过度复杂化小部件实例化。在没有性能提升的情况下，我会说性能可能更差（请不要介意）。因为每当调用构建时，您总是向SmartState类抛出一个新对象，直到并且除非这些小部件具有常量构造函数（这有助于运行时最终对象），或者您可以从上面的链接中看到小部件是根据两个基键和运行时类型进行比较的，虽然我会说constConstructor的性能会更好，但dart和其他语言对对象的支持比const变量多。大多数对象处理任务由dart（）本身负责

所以，为了最终确定我的答案，你可以这样做，这可能会消除你的疑虑。在任何有状态的小部件中执行此操作，您可能会找到答案

  void initState() { 
    super.initState();
  print( SizedBox() == SizedBox());  //OutPut: false 
  }

一个快速的解决方案是创建这样的类

class WidgetConstant {
  static const SizedBox _sizedBox = SizedBox(
    height: 2,
  );

  WidgetConstant._();
  static Widget sizedBox() => _sizedBox;
}

现在使用下面的代码进行比较

void initState() { 
    super.initState();
  print( WidgetConstant.sizedBox() == WidgetConstant.sizedBox(););  //OutPut: true 
}

---

结论：颤振已经优化，所以请享受使用此高性能框架的乐趣，感谢您的详细回答。我理解你的意思，但我可以说，我真的看到在这个用例中使用SmartState类有很大的改进。我知道比较两个新实例化的小部件并不相等。我认为您误解了

canUpdate

方法的功能。它比较了两个给定的小部件，看看框架是否可以将它们视为等价物，就好像新的小部件是旧部件的替代品一样。此外，在我之前引用的文档中，它说“当再次遇到与前一个框架相同的子小部件实例时”，这意味着它实际上是同一个实例，不是新创建的（widgetA==widgetB）。所以在我的理解中，返回先前构建的小部件应该（并且实际上是）完成这个任务。