Flutter性能对比：ListView子组件加padding与顶层加padding的开销差异

场景1的UI线程开销会明显高于场景2，二者开销并不一致，更推荐使用场景2的实现方式，具体原因如下：

• 组件树节点数量带来的固定开销
  场景1给10个子组件分别嵌套了独立的Padding组件，相比场景2的外层统一加Padding，会多生成10套Padding对应的Widget、Element、RenderPadding实例。就算EdgeInsets.symmetric使用了const修饰，也只能优化Widget重复构建的开销，无法抵消这些新增节点在布局、绘制全链路的处理成本。
• 重复布局计算带来的额外开销
  场景2只需要在外层Padding处完成1次水平边距的尺寸约束计算，ListView的可用宽度直接扣除左右20dp边距后，所有子组件都可以复用同一个可用宽度约束。而场景1中每个子组件对应的RenderPadding都需要单独执行1次水平边距的约束调整计算，10次重复的同质计算逻辑会带来额外的UI线程运算开销，后续如果子组件数量进一步增加，二者的性能差距会被拉得更大。

内容的提问来源于stack exchange，提问作者ark-tik