做 Android 的朋友都知道，在 Android 中，限定子元素大小的方法有三种，分别是 match_parent、wrap_content、fixed size。如果使用 ConstraintLayout，还会有 match_constraint。
这些值被设置到子元素的 layout_width 和 layout_height，由父元素解析生成 LayoutParams 设置给子元素，并在父元素的 measure 过程中使用它们以及父元素得到的 measureSpec 来确定子元素的大小。虽然子元素的大小最终由父元素决定，但父元素几乎不会违背子元素对自身大小的期望。因此你可以认为在 Android 中子元素的大小可以由子元素自己决定。子元素想要什么大小，给自身的 layout_width 和 layout_height 指定不同的值即可。
而在 Flutter 中，就完全不一样了。Flutter 积极组合的设计，希望一切布局都尽量通过组合的方式来实现。组合优于继承这是真理，但 Flutter 却走向了极端。连指定子元素的大小、padding、margin、translate、background 等等都需要通过嵌套来实现，这就是导致嵌套地狱的根源。
以指定子元素的大小为例，你需要给子元素套一层 SizedBox，通过它来限定子元素的大小。基于此，你可以理解为在一般情况下，Flutter 中子元素的大小无法由子元素自己决定，始终由其父元素决定，这和 Android 有本质的区别。
Flutter 也没有提供 match_parent 来让子元素撑满父元素，wrap_content 来让子元素内容有多大就撑多大。但是它提供了 double.infinity。我们一般使用它来让子元素撑满父元素。但其实 double.infinity 也用来表示 wrap_content。这得从 Flutter 的布局过程说起。
Flutter 布局过程
Flutter 的布局过程总结起来就三句话：
- 父元素向子元素传递约束（BoxConstraint）
- 子元素根据父元素传递来的约束以及自身的内容属性测量自身，并向父元素反馈自身大小（Size）
- 父元素根据子元素的大小以及自身的布局属性决定自身的大小以及子元素的 offset
这里有一个很重要的点是，子元素的大小永远不能违背父元素的约束，否则就会抛异常。子元素为自身的 size 赋值时，会触发以下检测：
if (!constraints.isSatisfiedBy(_size!)) {
throw FlutterError.fromParts(<DiagnosticsNode>[
ErrorSummary('$runtimeType does not meet its constraints.'),
DiagnosticsProperty<BoxConstraints>('Constraints', constraints, style: DiagnosticsTreeStyle.errorProperty),
DiagnosticsProperty<Size>('Size', _size, style: DiagnosticsTreeStyle.errorProperty),
ErrorHint(
'If you are not writing your own RenderBox subclass, then this is not '
'your fault. Contact support: https://github.com/flutter/flutter/issues/new?template=2_bug.md',
),
]);
}
为了避免这个异常，子元素在设置自身 size 之前，会先尝试满足父元素的约束：
double contentWidth;
// calculate content width
double realWidth = constraints.constrainWidth(contentWidth);
这样就能保证设置的 size 永远满足父元素的约束，不引发异常。
当你使用 double.infinity 尝试撑满父元素时，这里的 contentWidth 值为 double.infinity，但 constraints.constrainWidth 会返回父元素的宽度，这就起到了 match_parent 的作用。这里的隐含意思是子元素的大小不可能真的为无限大，因为没有任何一个 UI 框架能渲染无限大的东西，因为那意味着无限大的资源消耗。
wrap_content 又是咋回事呢？其实也是同样的道理。
当父元素对子元素没有大小要求时，会向子元素传递宽松约束，即只限制最大的大小，一般为父元素的大小。意思是子元素想要多大就给多大，但不能超过自身大小。但有些 Widget 就没有这个限制，它们允许子元素的大小超过自己的大小，因此它们给子元素传递的最大大小为 double.infinity。但子元素测量自己时，发现父元素给的最大大小为 double.infinity，不可能真的将自身大小设置为 double.infinity，因为 Flutter 没法渲染无限大的东西。如果你尝试着这么做，同样会抛异常。所以一般情况下，子元素会直接将 double.infinity 当作 wrap_content 处理，向父元素反馈自己的内容大小。
所以总结下来就是：
- 自下而上的 double.infinity 代表 match_parent
- 自上而下的 double.infinity 代表 wrap_content
当然一切的原因都在于 Flutter 设计之初没有考虑像 Android 那样用 -1 来表示 match_parent，-2 来表示 wrap_content。如果这么做的话，就没有 double.infinity 什么事了。
多数时候你都可以使用 double.infinity 来达到 match_parent 的效果，但也不总是这样。你永远如法用它来自下而上的达到 wrap_content 的效果。因为它只能自上而下。真想让子元素自身大小为 wrap_content，那就结合支持 wrap_content 的 Widget 比如 Center 使用吧。或者使用 Flutter ConstraintLayout。它自带了 matchParent、wrapContent、fixedSize、matchConstraint 的支持。
