去年做折叠屏适配的时候，我几乎被 Flutter 里那套布局原语逼到墙角。MediaQuery 拿到的宽度一变，所有 Row、Column 的比例都得重新算，代码里密密麻麻全是物理像素的分支判断。后来我把 cassowary 这个线性约束求解器搬进了布局层，做成一个基于响应式约束解算的渲染组件引擎，直接接管了页面里所有高维布局推算，顺带把鸿蒙系统上的折叠屏适配问题也一起解决了。这篇文章就把整个设计思路、落地过程和踩过的坑原原本本写出来。
需要提前说的是，如果你只是想在普通手机屏上写几个自适应页面，这套方案确实是杀鸡用牛刀。但凡是页面里存在强耦合的尺寸关系，比如"图片宽度等于容器宽度减去右侧文字最小宽度""两列必须等比拉伸但总量不能超过父级"，或者要在一套代码里同时支持展开态和折叠态的折叠屏设备，那传统布局模型怎么写都别扭，只有约束求解这一条路是正解。
1. 为什么会想到把约束求解器塞进布局系统
1.1 传统布局方案解决不了跨兄弟节点的耦合
Flutter 自带的布局模型走的是"约束向下传递、尺寸向上返回"的递归流程。父节点给子节点一个 BoxConstraints，子节点在约束范围内计算自己的尺寸，再把自己的尺寸告诉父节点。这种模型本身很好理解，但它有一个天然限制：任意两个节点之间的约束关系，只能通过它们共同的祖先来转述。这意味着当你想表达"A 控件的宽度是 B 控件宽度的 50%"，而 A 和 B 不是父子关系时，就必须到它们最近的公共父级里去手动计算这个值，然后作为约束传下去。
我最早遇到这个痛点是在做一个信息流的自适应卡片。卡片左侧有一个封面图，右侧有标题和摘要。设计要求封面图宽度和右侧文本区宽度必须维持某种比例，但文本区宽度又会因为不同字号的系统字体而变化。用传统写法，我需要先测文本宽度，再反推封面图宽度，然后重新 layout。这套逻辑在单个页面里写还能忍，但当十几个卡片组件都要这样做，你会发现代码里铺满了你并不想维护的"数学换算"。
当时我就在想，能不能换一种思路：不去计算每个控件的具体宽高，而是把所有控件尺寸之间的关系写成方程式，让求解器自己去推演。这就是 cassowary 进入我视野的契机。
1.2 cassowary 的核心价值：从动手计算变成提需求
cassowary 是一套基于线性等式和不等式约束的求解算法，最早就是为解决用户界面布局问题设计的。它的特点是你不用关心每个控件最终落在哪里，你只需要声明"这个控件的左边缘等于父容器左边缘加 16""那个控件的宽度是屏幕宽度的三分之一"这类关系，然后求解器会在所有关系同时成立的条件下，给每个变量求出一组最优解。
我第一次跑通这个流程时，最大的感受是：我终于可以从"计算者"变成"提需求的人"了。以前写布局，脑子里要做的是把 UI 设计稿翻译成具体的数值计算过程；现在写布局，脑子里想的是设计稿里每个元素之间到底是什么关系，然后把关系描述出来就行。
这个转变解决了一个很实际的问题：项目标题里说的"物理硬编码"。过去为了同时照顾不同屏幕和折叠形态，我得写死大量 px 阈值和 if-else。有了求解器，这些硬编码全部变成了约束方程，屏幕尺寸以变量的形式注入，方程成立的条件不变，布局就会自动给出新的解，不需要我再动一行逻辑。
后来我把这套东西扩展成一个完整的渲染组件引擎，核心就是一个自定义 RenderObject，在 layout 阶段调用 cassowary 求解，并把求解结果应用到子组件的尺寸和位置上。这个动作看似简单，但把两层系统嫁接起来，中间有不少坑，后面我会讲到。
2. 方案设计与核心模型拆解
2.1 变量、约束和权重是怎么组织的
在把 cassowary 嫁接到 Flutter 之前，得先把它的核心模型吃透。它组织问题的方式很清晰：所有可变的东西都是 Variable，包括控件的 x、y、width、height，也包括外部注入的屏幕宽度、安全区高度、折叠状态等。所有控件之间的关系都是 Constraint，分为等式约束和不等式约束。而为了让求解器在约束无法完全满足时有一个"最接近"的答案，每条约束还可以设置不同的优先级权重。
cassowary 的优先级分成强约束和弱约束，强约束必须满足，弱约束则尽可能满足。这个机制太重要了。比如你希望图片宽度等于文本宽度的一半，这是一个强约束；但同时你希望图片宽度至少 120，这是一个不等式强约束；最后你还希望图片宽度不超过屏宽的三分之一，这也是一个强约束。这些强约束之间如果矛盾，求解器会直接报错，所以通常会把"希望值"设成弱约束，把"边界值"设成强约束。
我在项目里的做法是把布局需求拆成三层：
- 第一层是结构性约束，比如"左边缘贴着父容器""顶部对齐"，这些设为最高优先级；
- 第二层是比例关系约束，比如"A 的宽度是 B 的两倍"，优先级中等；
- 第三层是偏置或者说期望值，比如"间距最好不大于 24"，优先级最低。
这样设计的好处是，当屏幕尺寸极端到已经没法维持理想比例时，求解器会优先保证结构不崩，再牺牲一点比例关系，而不是直接抛异常。
2.2 从求解结果到 RenderObject 的映射
模型层确定之后，最大的工程难点是让 Flutter 的渲染管线理解求解结果。Flutter 里自定义布局通常通过继承 RenderBox 来实现，核心是performLayout。我在这个函数里干的事有三步：第一步收集当前节点及其子节点相关的所有约束，第二步交给 cassowary 求解器求解出每个子节点的 offset 和 size，第三步根据结果设置每个子节点的大小和位置。
class CassowaryRenderBox extends RenderBox { CassowaryRenderBox({ required Map<String, Variable> variables, required List<Constraint> constraints, required List<RenderBox> children, }) : _variables = variables, _constraints = constraints, _children = children; // 核心：重写 performLayout @override void performLayout() { final solver = Solver(); // 注入外部变量 for (final entry in _variables.entries) { solver.addEditVariable(entry.value, EditPriority.required); } // 注入约束 for (final constraint in _constraints) { solver.addConstraint(constraint); } final solution = solver.solve(); for (final child in _children) { final left = solution.getValue(_variables['${child.key}.left']!); final top = solution.getValue(_variables['${child.key}.top']!); final width = solution.getValue(_variables['${child.key}.width']!); final height = solution.getValue(_variables['${child.key}.height']!); child.layout(BoxConstraints.tight(Size(width, height))); child.setOffset(Offset(left, top)); } size = computeSize(solution); } }这里有个很容易踩坑的逻辑点：BoxConstraints.tight并不是真的"强约束"，它只是告诉子树"你的尺寸必须固定在这个值上"。真正保证布局合理性的，是我们在求解前定义的那组约束。换句话说，Flutter 的约束传递机制变成了一个"传话筒"，真正的布局决策全部由 cassowary 算出，不会再让子组件自己决定一个意外尺寸。
2.3 响应式更新链路设计
仅有静态求解还不够，页面是会变的。设备尺寸变化、键盘弹出、折叠屏翻折，这些都会让布局重新推演。我的做法是把"可变外部输入"统一建模成一类变量，当外部事件发生时，不重建整个组件树，只更新这些变量的值，然后触发一次重新求解和重绘。
Dart 侧我用了一个简单的监听器模型。屏幕尺寸变化时，监听器会收到新的尺寸值，然后去修改对应 Variable 的值，接着调用markNeedsLayout。这样 Flutter 会在下一个 frame 里重新走一遍performLayout，而performLayout里会用新的变量值重新求解约束。
class WindowStateListener { void Function(double width, double height)? onChanged; void attach() { // 注册系统尺寸变化回调 } void handleChanged(double width, double height) { if (onChanged != null) { onChanged!(width, height); } } }这整个链路下来，页面等于被一个"全局状态驱动的约束网络"接管了。任何一处的变化都会被变量吸收，重新求解后自然传导到所有依赖它的控件上。这就是我理解的"响应式线性约束解算层"。
3. 鸿蒙适配：跨端差异和"超频"思路
3.1 鸿蒙与 Flutter 的对接层
这个项目要跑在鸿蒙系统上，首要解决的问题是 Flutter 引擎和鸿蒙系统之间的能力对接。鸿蒙侧的 Flutter SDK 已经能支持把 Flutter 页面编译成 ohos 目标，但一些系统能力接口和 Android 上完全不同。就拿获取窗口尺寸这件事来说，Android 上通常通过 View 的宽高或者 WindowManager 来拿，而鸿蒙上有自己的一套窗口管理接口。直接混用肯定不行，需要做一个适配层。
这个适配层我放在WindowStateListener里，它统一向布局引擎暴露一个方法：传入 windowWidth、windowHeight、dp 和折叠状态。底层真正调用的是鸿蒙系统接口还是 Android 系统接口，引擎完全不关心。这样跨端差异就被压缩到了一处，布局层永远只面对统一的数据结构。
cassowary 本身是纯 Dart 实现，不依赖任何 Flutter 引擎特性，所以在鸿蒙侧几乎没有额外工作量。真正麻烦的是后续的测量一致性，后面会在踩坑部分专门说。
3.2 折叠屏场景的约束化处理
折叠屏是这次适配里最棘手的地方，也是标题里"跨屏幕折叠"四个字想表达的重点。折叠屏设备至少存在三种形态：完全展开的大屏、折叠后的外屏、半折叠状态。用传统布局方案应对这些形态，通常要写三套 widget 布局或者用大段的if (isExpanded)分支。用约束引擎，局面就不同了。
我把折叠状态也建模成一个变量foldState，取值分别为展开态、折叠态和半折叠态。然后为不同状态准备不同的约束集合。比如展开态下，主内容区和辅助栏是左右排列，宽度比 7:3；折叠态下变成上下排列，高度比 5:2。这两个约束集合同时加到求解器里，但是在当前状态下把对应集合的约束设置成 required，另一个集合所有约束暂停。
实际用下来，切换约束集的方式比单求解器做 if-else 逻辑要稳定得多。单求解器支持的带条件的线性约束其实是有限制的，强制把所有模式塞进去反而容易让求解器算出违反直觉的结果。干脆用两套快照，切换时重新求解，代码结构也清晰。
void switchToExpanded() { _collapsedConstraints.forEach((c) => _solver.removeConstraint(c)); _expandedConstraints.forEach((c) => _solver.addConstraint(c)); markNeedsLayout(); }3.3 性能层面的"超频"优化
"超频"这个说法，是我给这套适配方案起的代号。含义有两层：一层是说传统方式下，面对一种新屏幕形态，开发者就得加班加点写硬编码，等于人在超频；另一层是说这套引擎通过缓存和增量求解，把布局计算本身也做了超频优化。
具体做了三件事。第一，约束求解结果缓存。只要变量值和约束集合没有变化，上一次求解出来的变量值直接复用，不重复调用 solver。第二，变量分桶。把不参与折叠切换的静态布局单独拎出来，折叠切换时只重新计算动态区域，静态区域不做 diff。第三，监听器节流。折叠屏翻折动作往往伴随着连续中间帧，如果每一帧都触发求解，即使求解器再快也会卡顿，我在监听器上加了一个 50ms 的节流窗口，只在折叠状态稳定后触发。
这三招做完之后，页面在折叠态切换时基本能稳定在 60 帧，偶尔复杂页面掉到 45 帧左右，但相比之前重新 build 整棵组件树已经提升非常明显。
4. 实操记录：接入步骤与关键代码
4.1 依赖引入和初始化
集成 cassowary 的第一步是把依赖加到项目里。Flutter 项目可以直接在 pubspec.yaml 里加cassowary依赖。它是纯 Dart 包，所以在 Android、iOS、鸿蒙上的行为完全一致，不需要额外写平台通道。
dependencies: flutter: sdk: flutter cassowary: ^0.2.4初始化时我一般会在页面 State 里创建一个 CassowaryLayoutController，它持有 Solver 实例和所有外部变量的引用。这个控制器负责接收窗口变化事件、切换约束集合、触发重新布局。页面销毁时关闭监听，释放求解器。
有一点值得提：不要把 Solver 实例在 State 里直接满天飞，因为你很可能需要在多个页面共享同一套约束模板。我的做法是设计了一个LayoutSpec的概念，一个 spec 就是一组变量声明加上一组约束构建函数，页面只需要把自己的元素映射到 spec 上即可。
4.2 自定义 RenderObject 的核心实现
前面提到的 CassowaryRenderBox 是一个最简原型，真正落地时它远没有这么简单。因为我需要支持子组件数量不固定的场景，而且不同子组件可能挂在不同的约束分组里，所以实际代码里我会先对子组件做一次分组遍历，把每个子组件的 left、top、width、height 变量建立成可查找的字典，然后根据配置的 LayoutSpec 去添加约束。
performLayout里还有几个必须处理的细节：
- 子组件可能因为内容多少而产生自然尺寸，比如文本的高度。这种情况下不能简单地把文本对象当普通 box 处理，需要用 TextPainter 预先测量自然尺寸，再把这个值作为约束的下边界。
- 当求解器给出的宽度为负数时，需要加一层防御性判断，直接把尺寸钳制为 0，因为布局上不存在负宽度。
- 求解过程中如果抛异常，不能让它直接崩掉整个 UI，要在外层抓住，退回用上一次成功求解的缓存结果。
@override void performLayout() { try { _solveAndLayout(); _lastSolution = _solutionCache; } catch (e) { if (_lastSolution != null) { _applySolution(_lastSolution!); } else { rethrow; } } }这样即便约束不小心写矛盾了，页面也只会"冻"在上一个可用状态，而不是白屏，排查起来轻松得多。
4.3 屏幕变化监听与动态求解
为了让引擎对窗口变化有响应，我在页面生命周期里注册了监听器。Flutter 里可以用WidgetsBindingObserver的didChangeMetrics，鸿蒙侧还有自己独立的窗口回调，但统一都收敛到WindowStateListener。收到新尺寸后，控制器会更新对应变量的值，再 callmarkNeedsLayout。
过程中一个容易忽略的问题是：屏幕尺寸变化不只是宽高变化，还包含 safe area 的变化。折叠屏从展开态翻到折叠态，安全区高度会变，如果约束里用的 top 直接绑定到屏顶，内容就会被摄像头挖孔区遮挡。正确做法是把 safeAreaTop、safeAreaBottom 也建模成变量，参与约束求解。
所以监听器里我实际注入的变量远不止宽度和高度，还有：
windowWidth windowHeight safeAreaTop safeAreaBottom safeAreaStart safeAreaEnd foldState这些变量统一作为约束方程的输入，才会让布局在折叠过程和各种异形屏环境下都保持正确。我强烈建议任何做类似方案的人都把 safe area 纳入约束体系，不要拿到尺寸就直接当可用区域，否则后面一定会被硬件环境教做人。
5. 踩坑实录：常见问题和排查思路
5.1 约束无解导致的布局崩溃
最常遇到的坑是约束集合里隐藏了矛盾条件，导致求解器直接抛异常。举例来说，你同时写了"A 的宽度 >= B 的宽度 + 100"和"B 的宽度 >= 容器宽度 - 200"，当容器宽度为 120 时，这两条约束几乎不可能同时满足。cassowary 遇到强约束矛盾时会抛出未解异常。
排查这类问题我总结了一个套路。先给每个子模块写一个极小规模的测试页，在测试页里打印所有变量的解，一旦出现异常，就逐个注释掉约束，定位是哪一对约束打架。更实用的预防手段是：把那些"理想比例"约束的优先级降为 weak，把"结构必需"约束保持为 required。这样即使比例关系在极端宽度下无法维持，也只是比例妥协，不会出现整体不可解。
这里还要提醒一个细节：flutter 的 layout 阶段如果抛异常，可能出现非常难查的"越界"提示，因为异常会被引擎捕获后中断当前 frame。所以在performLayout外面包一层 try-catch 能救你很多次。
5.2 求解结果抖动和权重玄学
权重设置不当会出现布局抖动的现象。原因是 cassowary 对弱约束是尽力满足，当权重间的区分度不大时，每次求解得到的值可能在小数位上有微小的差距，反映到 UI 上就是文字像素级的横移。
我遇到一次很奇葩的问题：某个弹窗宽度在连续两次 layout 中老是少一像素，看起来就像在闪烁。查了半天才发现是两条弱约束的权重都是 1，求解器在它们的中间值附近随机取舍。解决办法是给不同层级的弱约束设置数量级差异，比如权重 1、10、100，不要用相邻整数。
const lowPriority = 1.0; const mediumPriority = 50.0; const highPriority = 1000.0;另外，求解结果尽量在应用前做一次取整。UI 上大多数时候不需要亚像素精度，取整还能顺带避免纹理模糊和栅格化不齐的问题。
5.3 双端渲染不一致
鸿蒙侧跑和 Android 侧跑，同样的约束方程可能得出不同的最终视觉效果。最常见的根源是字体测量误差。鸿蒙的 TextPainter 在测量某些中文字体时，和 Android 系统排版存在细微差异，导致文本控件的自然宽度差一两像素，进而通过约束方程传导到其他控件的尺寸上。
排查思路是先判断是不是文本测量导致的。把约束中涉及文本宽度的变量手动固定成某个值，如果布局不再不一致，基本可以锁定是测量问题。我的处理方式是在文本控件外面套一层"测量补偿"，在外面减去系统间字体的 delta 值，保证进入约束系统的宽度值是统一口径。
这类双端差异一般不会造成功能问题，但如果你的布局约束写得很紧凑，一像素误差会沿着传递链放大成明显的错位。所以建议在关键控件的约束上留出 2-4 像素的冗余量，换稳妥。
6. 最后说点个人感受
做完这个引擎之后，我再回头看传统 Flutter 布局，忽然意识到一个本质上的不同：传统布局是"递归决策"，每个节点只根据父级决策做自己的判断，无法全局最优；cassowary 这套约束方案是"全局求解"，所有变量放在一起算一个全局最优解。这两种方向各有各的适用场景，不是说要全盘替换，而是说当布局复杂度到了一个阈值，全局求解带来的收益会远超递归模型。
我个人在实际操作中最得益的，是"提需求"替代"动手算"带来的心智负担下降。以前面对折叠屏的各种形态，我要在脑子里模拟每种状态下控件位置的变化；现在只需要把约束关系维护好，其余交给求解器。这个转变不是偷懒，而是把工程能力和算法能力的时间花费重新分配了一下。
另外还有一个小建议：如果你真的打算引入这种方案，不要让内部实现细节扩散到业务层。我把求解器完全封装在组件引擎内部，业务层只看到一组可配置的属性，比如"排列方向""比例关系""优先级"。这样做的好处是维护边界清晰，团队里其他人不需要理解单纯形法也能使用，而真正的线性约束知识只留在引擎维护者脑子里就够了。
后续我还打算把这套引擎扩展到更多动态场景，比如键盘弹起时多个区域的联动压缩、拖拽手柄时的自定义弹性布局，这些都是传统布局写起来极难受的地方。就目前来说，这套基于 cassowary 的布局引擎在我手上已经稳定跑了两个大版本，如果你在处理类似的复杂自适应布局，我建议真的花点时间试试这条路。
