我自己写过不少 Compose 界面，大部分时间都在跟 Row、Column、Box 打交道，但一旦遇到不规则排布需求，比如热门话题标签、图片瀑布流、自适应换行的弹窗提示区，内置布局立刻就有点兜不住了。Jetpack Compose 自定义布局这种话题，看起来像是给轮子发明者准备的进阶课，其实只要你写过一次，就会发现它没有想象中那么神秘，本质就是“自己决定每个子组件怎么测量、怎么摆放”。这篇文章我会把整套逻辑从设计思路到落地方案拆开讲，包含可以照着改的代码，也把我踩过的几个坑一并放进来，希望能帮你少走点弯路。
1. 自定义布局到底解决了什么问题
1.1 内置布局的边界在哪里
很多人刚接触 Compose 时会有一种错觉：布局不就 Row、Column、Box 三板斧吗？确实，大多数业务界面都可以通过嵌套这三个容器完成。但只要稍微做一点特殊排布，你就会发现它们很难应付。
举个很常见的场景：显示一组标签，标签数量不定，宽度各不相同，而且要在固定宽度内从左到右排列，一行放不下时自动换到下一行。如果直接用 Row 包起来，内容一旦超出屏幕宽度就会溢出；如果给每个子项固定占比，又没办法适应不同文字长度。你可能会说用 FlowRow，没错，新版 Material 里提供了 FlowRow，但它的行为是固定的，对称对齐、间距规则、行高策略都写死了。假如你想做“每一行子项之间间距相等，但行与行之间间距不同”的自定义规则，或者想控制每个子项按自身最大尺寸占据特殊位置，内置组件就不太好实现了。
再比如统计图表里的坐标轴刻度文字，需要围绕一个中心点按角度分布，或者让文字标签自动避开重叠区域，这种布局已经超出常规线性排列的范畴。还有带展开收起动画的段落容器、需要让某个子项悬浮在整体区域某个百分比位置的容器，也都是内置布局很难覆盖的。这些场景才是 Jetpack Compose 自定义布局真正发挥价值的地方。
1.2 自定义布局的本质与使用场景
从原理上讲，Compose 里所有布局组件最终都做了同一件事：测量子组件，然后把它们放到父组件指定的坐标位置上。Row 只是规定“从左到右横向累积摆放”，Column 规定“从上到下纵向累积摆放”，Box 规定“所有子组件叠在同一个区域里”。
自定义布局的本质，就是绕过这些既定规则，自己写一套“测量和摆放逻辑”。你可以让一个子组件占据可用宽度的 1/3，也可以让后一个子组件依赖前一个子组件的测量结果动态决定位置，还可以把一个子组件按比例映射到整个布局区域内。只要绘制流程还遵循 Compose 的约束规则，你就能通过自定义布局实现各种很灵活的效果。
我用这个思路做过一个小项目：模拟用户画像卡片，里面有一组能力标签，需要围绕头像按弧形排列。以前用 Canvas 自己画需要手动计算每一个文字的坐标，而且文字测量、换行、缩放都得处理一遍。后来用自定义布局重新实现，子组件仍然是普通 Text，布局逻辑只需要计算角度、半径和每个子组件的测量宽高，然后通过 place 放到对应位置。整体代码量不但没有增加，文字本身还自动获得了系统的手势、辅助功能和主题样式。这也是自定义布局最吸引人的一点：它不影响子组件本身的能力，只是重新决定“它们站在哪里”。
2. 从零开始认识 Layout 可组合项
2.1 拆解 Layout 函数签名
Compose 提供一个最底层的布局原语，名字就叫Layout。它是所有布局容器的基础，很多你看得到的 Row、Column 内部也是封装它实现的。我们先看它最核心的签名，不用背，理解参数含义就行。
@Composable fun Layout( modifier: Modifier = Modifier, content: @Composable () -> Unit, measurePolicy: MeasurePolicy )content就是你需要布局的子组件列表，通常是从外部传入的 lambda，里面可能包含多个子组件。modifier用于给整个布局附加外边距、背景、点击事件等。真正核心的是measurePolicy，它决定了这个布局怎么应对约束、怎么测量孩子、怎么安放孩子。
实际使用中，通常不会直接写一个MeasurePolicy对象，而是用 Kotlin 的 lambda 语法简化：
Layout( content = { Text("A") }, modifier = Modifier.padding(16.dp) ) { measurables, constraints -> val placeables = measurables.map { it.measure(constraints) } layout(placeables.sumOf { it.width }, placeables.maxOf { it.height }) { placeables.forEach { it.placeRelative(0, 0) } } }这里传进去的 lambda 前两个参数分别是List<Measurable>和Constraints，分别代表子组件列表和父组件对当前布局施加的约束条件。lambda 执行到最后必须调用layout(width, height) { ... }来声明当前布局的实际尺寸，同时在这个Placeable.PlacementScope里放置所有子组件。如果不调用layout，或者调用次数不对，直接会导致运行时异常。
2.2 MeasurePolicy 中的 measure 是怎么回事
MeasurePolicy的核心方法就是measure，我的理解它就像一份布局合同的执行入口：
- 先接收所有孩子的测量句柄。
- 根据父级约束和策略，给每个孩子分配测量约束。
- 得到每个孩子测量后的
Placeable对象。 - 计算当前布局的宽高。
- 调用
layout声明尺寸，并放置每个Placeable。
这里面最容易被忽略的一点是，你必须在layout的放置代码块中，对每一个测量过的孩子都调用一次place或placeRelative。少放置一个不会编译报错，但运行时会直接崩溃，错误信息通常类似于The following children are not placed。多放置理论上不会崩，但会出现绘制重叠和奇怪的触摸事件错乱，所以我每次都会在心里给自己强调一遍：测量列表和放置列表必须一一对应。
另一个要注意的是，measure方法内部不应该执行任何与绘制无关的副作用，比如网络请求、数据库写入、remember里的状态变更。因为布局阶段可能因为动画、手势等原因被多次调用，一旦塞入副作用，就会造成不可预知的状态错乱。正确做法是让measure保持纯粹：只根据输入计算尺寸和位置，把结果返回给调用方。
2.3 必须理解的 constraints min/max 机制
Constraints是理解 Compose 布局的关键，它本质上是一个带有四个数值的约束框：最小宽度、最大宽度、最小高度、最大高度。
Constraints( minWidth = 0, maxWidth = 300, minHeight = 0, maxHeight = 300 )意思是：当前布局的宽度必须在 0 到 300 之间，高度也必须在 0 到 300 之间。如果父级是固定宽度，minWidth和maxWidth会相等，这时你测量出的孩子宽度也被锁死在这个范围内。如果父级是Box包裹，可能约束是 0 到无穷大，这种时候你就得自己决定尺寸。
我在实际排查过很多次之后发现，大多数自定义布局的“神秘异常”都出在约束处理上。比如用measurable.measure(constraints)直接把父约束传给孩子，孩子就会被迫填满整个可用空间，得到的结果往往不是你想要的。更合理的做法通常是这样：
val childConstraints = Constraints( minWidth = 0, minHeight = 0, maxWidth = constraints.maxWidth, maxHeight = constraints.maxHeight )也就是把最小宽度和最小高度放宽为 0，允许孩子按自己的内容尺寸去测量。等孩子测量出实际大小后，再由你的布局逻辑决定如何在空间内排列。
一个很容易混淆的点是Constraints里可能出现Infinity。当父组件是横向滚动列表时，横向约束的最大宽度可能是无限的；当父组件是纵向滚动列表时，纵向最大高度可能是无限的。如果你的布局代码没处理无穷值，比如直接拿constraints.maxWidth去参与数学运算并取整，就可能得到异常尺寸甚至无穷大。因此，在写自定义布局时，我习惯先打印一次约束，确认当前上下文的边界条件，再决定测量策略。
3. 手把手实现一个自适应流式布局
3.1 需求拆解和测量策略设计
理论讲太多容易飘，我们用实操来验证。目标是实现一个简单但完整可用的流式布局，我暂且叫它FlowLayout，它可以接收任意多个子组件，在宽度有限时自动换行。用起来大概是这样：
FlowLayout( horizontalSpacing = 8.dp, verticalSpacing = 12.dp, modifier = Modifier.padding(16.dp) ) { repeat(20) { Text("标签 $it", Modifier.background(Color.LightGray)) } }实现前先做需求拆解，这一步特别重要，直接决定代码结构。我需要明确三点：
- 每个子项测量时能获得多大的可用空间？我决定给每个子项单个子约束，最大宽度不超过父布局最大宽度，最小为 0。
- 一个子项放不下当前行时怎么办？换新行，新行从布局最左侧开始。
- 换行后的行高如何计算？新行的起点要累加上一行的最大高度，再加上纵向间距。
思路确定后，就可以开始写测量逻辑。留一个变量rowWidth记录当前行已占宽度，rowHeight记录当前行最大高度，再维护一个总高度totalHeight用于计算最终布局高度。宽度方面，最终布局宽度直接取父级约束的最大宽度，不需要自己计算，因为流式布局就是填满可用宽度的。
3.2 放置阶段与换行算法
代码是最好理解的载体，我先给出一个精简版本，再逐行解释。
@Composable fun FlowLayout( horizontalSpacing: Dp = 0.dp, verticalSpacing: Dp = 0.dp, modifier: Modifier = Modifier, content: @Composable () -> Unit ) { val horizontalPx = with(LocalDensity.current) { horizontalSpacing.toPx() } val verticalPx = with(LocalDensity.current) { verticalSpacing.toPx() } Layout( modifier = modifier, content = content ) { measurables, constraints -> // 给每个子项一个宽松的约束，让它们按内容自然测量 val childConstraints = Constraints( minWidth = 0, minHeight = 0, maxWidth = constraints.maxWidth, maxHeight = constraints.maxHeight ) val placeables = measurables.map { it.measure(childConstraints) } // 记录每个子项的位置信息 data class Position(val x: Float, val y: Float) val positions = mutableListOf<Position>() var x = 0f var y = 0f var rowHeight = 0f var totalHeight = 0f placeables.forEach { placeable -> if (x > 0f && x + placeable.width > constraints.maxWidth) { // 当前行放不下，换行 x = 0f y += rowHeight + verticalPx totalHeight = y + placeable.height rowHeight = 0f } positions.add(Position(x, y)) x += placeable.width + horizontalPx rowHeight = maxOf(rowHeight, placeable.height.toFloat()) totalHeight = maxOf(totalHeight, y + rowHeight) } val layoutWidth = constraints.maxWidth val layoutHeight = totalHeight.coerceAtLeast(0f).roundToInt() layout(layoutWidth, layoutHeight) { positions.forEachIndexed { index, position -> placeables[index].placeRelative( x = position.x.roundToInt(), y = position.y.roundToInt() ) } } } }换行算法说穿了就是“贪心”策略：能放下就放在当前行，放不下就换一行。代码里的x是当前水平位置，rowHeight是当前行里所有子项的最大高度。当新子项加入后发现x + placeable.width超过constraints.maxWidth，就把x重置为 0，y往下推进一行。
一个我实际测试中遇到的细节：如果子项本身宽度已经超过constraints.maxWidth，比如图片宽度是 500，而父布局只有 300，那它会不断触发换行条件。更稳妥的做法是先判断子项宽度是否直接超过最大宽度，如果确实超过了，就把子项约束里的最大宽度设置成父布局最大宽度，强制它缩放或换行，否则流式布局会退化成每行只有一个子项，看起来还行，但子项可能溢出到屏幕外。文本子项自带换行能力不会溢出，但图片和自定义绘制就可能出问题，所以我在真实项目中会更谨慎地处理这种边界。
3.3 给布局加上间距与对齐规则
上面的代码已经实现了最基本的流式换行，但距离可用还有点差距。产品经理经常会加一句“子项最好按不同方式对齐”，这个需求在前端里就是 flex-wrap 加上 justify-content 的排列策略，在 Compose 自定义布局里需要自己实现。
我在自己项目里加了一个alignment参数，用来控制每一行内各个子项的对齐方式。比如按左对齐、居中对齐、右对齐三种策略。实现思路很直接：先扫描出每一行的起止索引，然后在放置阶段根据每行剩余空间调整x的初始偏移。假设当前行总宽度是rowUsedWidth，剩余空间是constraints.maxWidth - rowUsedWidth，那么右对齐时x从剩余空间开始；居中对齐时x从剩余空间的一半开始。
这里要注意的是，放置阶段和测量阶段虽然可以共用位置数据，但如果你需要在放置前知道每一行的剩余空间，就必须在测量阶段先把行信息计算好。所以我通常会把换行结果先缓存到一行data class LineInfo里，包括这条线上的子项索引范围、行内最大高度、行内已用宽度，然后等到layout块里再根据alignment决定每个子项的具体偏移量。
更复杂一点的场景是行内交叉轴对齐，也就是垂直方向的对齐。例如一行里既有高个子图片，又有小文字标签，你可以让文字底部和图片底部对齐，也可以让文字居中。这个策略如果写到放置阶段，会让代码很啰嗦，我的做法是给每个子项传一个verticalAlign的自定义修饰符，把参数存到LayoutParentData类型里，然后在布局中读取它。这部分属于进阶玩法，代码结构会稍微复杂，但核心思路依然是：先在测量阶段拿到每个孩子的宽高，再在放置阶段按照对齐规则计算y偏移。
3.4 从布局里返回尺寸时的边界条件
在写FlowLayout的时候，还有一个特别值得说的部分：如何计算最终布局的宽高。我见过不少初学者直接把所有子项测量后的宽高丢进layout(width, height)，不考虑父级约束，结果要么布局一直填充不到预期区域，要么直接崩溃。layout函数本身会强制校验最终尺寸是否满足父级约束，如果你传入的宽度超过父级最大宽度，或者小于父级最小宽度，运行时就会被纠正甚至直接报错。
这也是为什么上面代码里我把layoutWidth直接取constraints.maxWidth而不是自己做累加。因为流式布局的设计目标就是填满整个宽度，这样最稳妥。高度方面，因为父级如果给了固定高度，比如Modifier.height(200.dp)，constraints.maxHeight就会等于minHeight等于 200，这时我计算出的totalHeight可能小于 200，也会被系统强制拉伸到 200，导致子项并没有填满到预期高度、底部留白。这种情况需要在测量子项时就把多余空间分配给每个子项，或者让布局在高度不匹配时主动调整孩子的位置。实际项目里我更倾向于把高度控制交给父容器，自定义布局尽量做到“量入为出”。
4. 自定义布局的高阶配套能力
4.1 Modifier.layout 的微观定制
除了最底层的Layout可组合项，Compose 还提供Modifier.layout这个修饰符，它可以让你在不改变整体布局结构的情况下，对某个子组件进行微调。两者最大的区别在于：Layout是容器级，影响所有子组件；Modifier.layout是单节点级，只影响它修饰的那个组件。
举个例子，我在做一个卡片时，需要让标题文字在某些状态下稍微偏几个像素，又不想影响整体布局。这时就可以写：
Text( text = "标题", modifier = Modifier .layout { measurable, constraints -> val placeable = measurable.measure(constraints) layout(placeable.width, placeable.height) { placeable.placeRelative(placeable.x, placeable.y + 2) } } )这个修饰符在测量时拿到的是原组件的测量结果，然后我又把它原样放置回去，只是y方向偏移了一点。看起来很简单，但它其实是侵入式布局控制的最便捷入口。你还可以在这里做更极端的事，比如把测量后的宽高放大，再在放置时手动调整子项位置，实现类似“扩展点击区”的效果。不过我提醒一句，过度使用Modifier.layout会让布局树的可读性变差，因为它把一个本应统一的布局逻辑分散到了单个节点上。我的习惯是只用来做小范围微调，真正的复杂容器逻辑仍然放到Layout里。
4.2 自定义对齐线实现子项对齐
Compose 内置了对齐线，比如FirstBaseline、LastBaseline，它们可以让文本在不同字号下仍然保持基线对齐。如果你做过自定义布局，很可能碰到这种情况：一行里有不同大小的文字，单纯的上边缘对齐会让视觉上显得不整齐，因为它们基准线不同。
自定义布局也可以通过对齐线解决这个问题。做法是先定义一条自定义的AlignmentLine，然后在子组件的Modifier.layout里通过layout块的参数返回这条线的位置。举个例子：
private val TagAlignmentLine = object : AlignmentLine { override val label = "TagAlignmentLine" override val resetValue = Int.MIN_VALUE }然后在子项放置时：
layout(placeable.width, placeable.height) { placeable.placeRelative(0, 0) TagAlignmentLine.place(placeable.height / 2) }父布局在测量时就能通过placeable[TagAlignmentLine]拿到这个值，进而让多个子项以水平中线对齐。在我做标签云的项目里，这个特性帮了大忙，文字大小不一致导致的凌乱感一下就被消除了。
但要特别注意，AlignmentLine是有方向感的东西，不是随便给个值就完事。它必须是相对于该子项顶部的位置，而且父布局在读取时要确保该子项已经被放置。如果你在measure阶段就读取值，很可能拿到的是resetValue。我踩过这个坑，后来把所有读取操作都切到了放置阶段之后，才算稳定。
4.3 与 Intrinsic 配合提升外部测量准确性
Compose 里有一个常见但很多人没太搞懂的概念：固有尺寸测量（Intrinsic Measurement）。当父布局需要在没有确定尺寸的情况下预先测量子项时，比如实现“文本框高度自适应内容，但又要最多占可用宽度一半”这类需求，它会调用IntrinsicWidth或IntrinsicHeight。
如果你自定义布局没有妥善处理这两种测量方法，外部布局在测量它时就会使用默认实现，返回的结果通常不够准确，导致外层布局出现奇怪的换行或高度异常。我记得有次某个自定义卡片组件嵌套在流式布局里，外层怎么测都多出几像素高度，查了半天才发现是卡片内部的固有高度实现没有覆写，返回了一个非常保守的默认值。
处理方式是在MeasurePolicy里覆写相关方法，比如minIntrinsicWidth、maxIntrinsicWidth、minIntrinsicHeight、maxIntrinsicHeight。实际项目里我不太建议一开始就纠结固有尺寸，除非你确认外部容器真的有这种测量需求。大多数情况下，先确保常规测量正确，然后针对具体问题再优化固有测量。
5. 排坑实录与性能实践
5.1 子项被拉伸、无限宽高问题
我自己用自定义布局翻车最多的，就是约束传递不正确。最典型的是直接拿父级constraints去测量孩子，这样孩子会被迫填满整个父布局。比如做一个封面卡片，所有子项都变成了宽高各占一半，完全失去了各自的内容尺寸。
解决这个问题需要明确一件事：父级约束是给“当前布局”的约束，不是给“每个子项”的约束。你需要根据布局策略手动构造子项约束，常见做法是保留最大尺寸，把最小尺寸清零：
val childConstraints = constraints.copy(minWidth = 0, minHeight = 0)另一个让我头疼的问题是无限宽高。父级是LazyRow时，横向最大宽度可能是无限大，如果子项测量约束也传成无限大，文本、图片这类会努力撑满无限空间的内容就会出问题。这时最稳妥的办法是把无限值限制到一个合理大数，或者根据需求强制设置子项最大尺寸。
val maxChildWidth = if (constraints.maxWidth == Constraints.Infinity) { someReasonableWidth } else { constraints.maxWidth }5.2 测量次数异常与副作用控制
自定义布局如果出现性能问题，常见原因不是测量算法复杂，而是测量次数过多。Compose 的布局阶段是自顶向下的，父布局测量时可能会触发子布局多次测量，尤其是在嵌套自定义布局或者配合Modifier.layout时，一个节点的测量次数会指数上升。
我的排查经验是：不要在measure里写打印日志，你可能会看到成百上千行输出，这既是性能问题，也是数据噪音。需要观察时，可以加一个CompileTimeOnly级别的 debug 变量，用if (Const.ENABLE_DEBUG)包裹，然后通过sideEffect打印最终结果。更优雅的方式是用LayoutInspector直接查看每个节点测量后的尺寸，比用日志来猜测高效得多。
副作用控制也是关键。如果你在measure阶段直接调用mutableState更新值，会导致组合阶段和布局阶段互相触发，轻则卡顿，重则无限循环。我个人的原则是：测量阶段只做数学运算和条件判断，所有需要记忆的状态统一放到外层，通过参数传入布局。这样能最大程度保证布局的可预测性。
5.3 子项没有放在预期位置或者重叠了怎么办
子项重叠在自定义布局中很常见，尤其是需要计算y偏移的时候。我遇到过一个典型场景：每个子项高度不同，第二行第一个子项总是从第一行的起始位置开始放，看起来像是被“吸”到了顶部。原因是行高变量没有正确累积，我在换行时只更新了x，忘了把y累计到上一行，导致所有行都堆叠在y=0上。
排查这种问题，我通常会给每个子项临时加一个不同颜色的背景，再用LayoutInspector查看实际的坐标值。肉眼观察颜色很容易发现重叠和顺序错乱。坐标偏差通常集中在三类问题里：
- 换行条件写错，导致换行过早或过晚。
- 行高变量更新时机不对，导致
y计算错误。 - 间距值没有换算成像素，导致宽度计算偏差或负值。
尤其是 Dp 转 Px 这一步，很多人会忘记乘密度。with(LocalDensity.current) { 8.dp.toPx() }这个转换在自定义布局里几乎是必写的，漏掉之后在低密度设备上看起来正常，在高密度设备上就会出现莫名其妙的间距错乱。
6. 这段实践让我总结的几条经验
最后说几句我实际用下来觉得最有价值的经验。第一，刚开始写自定义布局时，千万别一上来就追求通用封装。先把一个最简单的场景写通，再去抽象参数、对齐策略、内置测量逻辑。第二，尽量多给布局加一点防御性代码，比如处理无限约束、处理子项宽度超过父布局、处理总高度计算为 0 这些边界情况，这些逻辑虽然平时走不到，但一旦触发就是线上问题。第三，要养成在布局阶段打印关键数据的习惯，但记得只保留一份，不要在生产环境打开。
另外一个很实际的经验是，自定义布局跟状态管理的配合要谨慎。不要在布局里读取大量State，因为每次状态变化都可能触发重新测量，这在普通场景下无所谓，但如果是长列表里的每个 item 都包含一个自定义布局，频繁读取状态就会让滑动时的性能明显下降。我遇到过类似场景，后来把一部分状态提升到了父节点，用参数传递代替直接的 State 读取，卡顿立刻改善。
Jetpack Compose 自定义布局能玩的东西远不止我今天写的这些，比如配合 Canvas 做绘制、配合动画做子项重排、把布局算法抽成可以跨项目复用的工具库，这些都是可以继续深入的方向。希望这篇内容能让你对它的核心机制不再发怵，拿起编辑器亲手搭一个简单的自定义布局试试。毕竟这种东西，光看永远觉得复杂，动手写完第一个版本之后，后面的路就顺了。
