3、布局性能：约束与尺寸传递机制，避免过深的Widget树，使用LayoutBuilder

布局性能，说白了就是Flutter渲染的第一道关卡。很多新手觉得布局嘛，不就是堆Widget吗？其实不然。我见过太多项目，卡顿的根源就是布局写得不够讲究。

今天咱们就聊聊三个核心问题：约束怎么传的、Widget树多深算深、以及LayoutBuilder这个神器怎么用。

3.1 约束与尺寸传递机制

Flutter的布局机制，我习惯叫它「自上而下约束，自下而上尺寸」。什么意思呢？

父Widget先告诉子Widget：「你最大能占多少，最小不能小于多少」。子Widget收到后，根据自己的内容算出一个尺寸，再告诉父Widget：「我就这么大，你看着办」。

举个例子：

Container(
  constraints: BoxConstraints(
    minWidth: 100,
    maxWidth: 200,
    minHeight: 50,
    maxHeight: 100,
  ),
  child: Text('Hello'),
)

这里Container给Text的约束是：宽度在100到200之间，高度在50到100之间。Text算完后，会返回一个实际尺寸。如果Text内容很少，可能只占100x50。如果内容很多，可能撑到200x100。

我在项目中遇到过一个问题：一个复杂的表单页面，某个输入框突然变得特别小。排查了半天，发现是外层Container给了个很紧的约束。嗯，这种问题其实很常见，你想想看，约束链一旦断了，整个布局就乱了。

3.2 避免过深的Widget树

Widget树太深，是性能杀手之一。为什么？因为每次重建时，Flutter都要遍历整棵树。树越深，遍历越慢。

我见过最夸张的一个项目，一个列表项嵌套了20多层Widget。说白了，就是各种Padding、Container、Column、Row套来套去。结果滑动列表时，帧率直接掉到30fps以下。

怎么避免？我给大家几个建议：

• 能用组合就别用嵌套：比如多个Padding可以合并成一个
• 善用const构造函数：如果Widget不会变，加个const，Flutter会复用实例
• 提取公共组件：重复的布局结构，抽成一个方法或Widget

举个例子，优化前：

Column(
  children: [
    Padding(
      padding: EdgeInsets.all(8),
      child: Container(
        padding: EdgeInsets.all(8),
        child: Text('Hello'),
      ),
    ),
    Padding(
      padding: EdgeInsets.all(8),
      child: Container(
        padding: EdgeInsets.all(8),
        child: Text('World'),
      ),
    ),
  ],
)

优化后：

Widget _buildItem(String text) {
  return Padding(
    padding: EdgeInsets.all(8),
    child: Container(
      padding: EdgeInsets.all(8),
      child: Text(text),
    ),
  );
}

Column(
  children: [
    _buildItem('Hello'),
    _buildItem('World'),
  ],
)

你看，代码更清晰了，Widget树也变浅了。虽然提取后还是两层，但至少可维护性提高了。

3.3 使用LayoutBuilder

LayoutBuilder是个好东西。它能在布局时拿到父Widget的约束，然后根据约束动态调整子Widget的布局。

我举个例子：

LayoutBuilder(
  builder: (context, constraints) {
    if (constraints.maxWidth > 600) {
      return _buildWideLayout();
    } else {
      return _buildNarrowLayout();
    }
  },
)

这段代码的意思是：如果父Widget宽度大于600，用宽屏布局；否则用窄屏布局。这在响应式设计中特别有用。

我曾经在一个电商项目中，用LayoutBuilder实现了商品列表的自适应布局。手机上是两列，平板上是三列，完全不用写MediaQuery。你想想看，多省事。

但要注意一点：LayoutBuilder的builder函数会在每次布局时重新调用。如果里面做了复杂计算，可能会影响性能。我建议只做简单的判断和布局切换，别在里面做网络请求或大量计算。

3.4 实战建议

说了这么多，总结几条实战经验：

1. 约束传递要清晰：每个Widget都要清楚自己收到的约束，别让约束链断裂
2. Widget树别太深：超过10层就要警惕，能用const就用const
3. LayoutBuilder是神器：响应式布局用它，比MediaQuery更灵活
4. 多测多调：用DevTools的Layout Explorer，直观看到每个Widget的约束和尺寸

最后说一句：布局性能优化，不是一蹴而就的事。我每次写完布局，都会用DevTools跑一遍性能分析。发现问题就改，改完再测。久而久之，你自然就形成肌肉记忆了。

好了，这一章就聊到这儿。下一章咱们聊聊「图片加载与缓存策略」，这也是个容易踩坑的地方。