颤振性能:每个小部件上的填充与顶层列表视图上的填充

Question

场景1: A ListView有10个子小部件，每个小部件的对称水平填充值为20.0。

return ListView(
  children: <Widget>[
    Padding(
      padding: const EdgeInsets.symmetric(horizontal: 20.0),
      child: Widget1),
    Padding(
      padding: const EdgeInsets.symmetric(horizontal: 20.0),
      child: Widget2),
    // ...8 more like that...
  ],);

场景2: A ListView有10个子部件，没有任何填充。相反，将对称的水平填充20.0应用于ListView本身。

return Padding(
  padding: const EdgeInsets.symmetric(horizontal: 20.0),
  child: ListView(
    children: <Widget>[
      Widget1,
      Widget2,
    // ...8 more like that...
  ],),);

场景1中会有更多的开销(在UI线程中)吗？还是会保持原样。

PS:考虑每个小部件是不同的，ListView.builder不是一个选项。

Answer 1

根据我的观点，您应该使用列表视图的填充属性：-

return ListView(
  padding: const EdgeInsets.symmetric(horizontal: 20.0),
  children: <Widget>[
      Widget1,
      Widget2,
    // ...8 more like that...
  ],
);

在第一个场景中，假设您有10个子部件，那么10*2=20小部件将被呈现为在它们上存在填充，所以乘以2，而在第二个例子中，只有11个将被呈现。但是我共享的示例将只呈现10个小部件。

Ps：-忽略了listview小部件的计数(如果想考虑，只需在所有情况下添加1计数)。

Answer 2

这里所有的答案都是好的，但只能告诉你一件事。

//最好先来一次

场景2:显然，完成的工作量较少意味着代码具有更高的性能。这里我们有一个2 + 10 = 12小部件的直接呈现，所以每当呈现这些小部件时，就会有12个组件由颤振的Skia引擎呈现。现在，如果深入研究小部件的状态管理或更新，这意味着从根开始构建树，在每次构建方法的后续运行中，您只呈现12个组件。

鉴于

场景1:这里的性能问题是它在构建方法的一次运行中呈现1 + ( 2 * 10 ) = 21小部件。所以现在，如果我们从需要重建树的角度来看，它必须做更多的工作来删除9个小部件，而不是场景2，然后再多构建9个小部件。

PS。您还可以优化一些不需要使用const关键字一次又一次地重新构建的静态小部件。

我还想补充一件事--这不是一个很大的性能增量，我想说的是，您可能也无法用dev工具来验证boost。

Answer 3

一般来说，这种差别是如此的微不足道，所以它不应该成为你的决定因素。相反，您应该确定哪个方法对您的业务逻辑更有意义，或者提高您的代码可读性，或者两者兼而有之。

严格地说，直接向ListView添加填充会稍微好一些，因为所需的计算量会稍微少一些。另外，值得注意的是，Padding小部件实际上不会“绘制一个不可见的容器，画一些不可见的间隙，并在中间画它的子部件”--这不是它的工作方式。实际上，它的效率要高得多:简单地说，通过只遍历小部件树一次，小部件就被放置在一次O(n)操作中。当它下降时，它通过父母的约束，当它上升时，它超过了孩子的大小。在Padding小部件的情况下，它只是在传递时修改父部件的约束，因此实际上几乎没有任何开销需要担心。

还值得注意的是，ListView具有padding属性，因此直接使用它是您没有提到的第三个选项。请注意，ListView的填充属性的行为与使用Padding小部件包装它的行为不一样，您可能也需要担心SafeArea。你可以很容易地通过一些实验来解决这些问题。同样，所有3种方法的性能成本都很低，您应该选择对业务逻辑最有意义的方法。