SWT 里做桌面界面最容易被低估的往往不是控件而是布局。RowLayout 这个名字听起来平平无奇——不就是一行一行排吗可我带过的几个项目里真正把 RowLayout 用明白的人并不多更多人是在 GridLayout 里绕不出来之后才回头发现这个被冷落的类。RowLayout 是 SWT 提供的行式布局管理器它把子控件按水平方向或垂直方向依次排开空间不够时自动换行配合 RowData 还能做固定宽高、动态隐藏这类操作。它最擅长的场景是工具条、按钮栏、标签加输入框这种顺着一个方向排的需求代码量比 GridLayout 少一大截可读性也好。但它有几个坑比如 RowData 改完不生效、wrap 打开后容器高度算不对、justify 和 fill 一起用出现诡异拉伸。这篇内容就是把这些年踩过的、看别人踩过的坑串起来从参数语义讲到实操代码再到排查手段适合刚接触 SWT 的新手也适合写过一段时间但总觉得布局不太听话的老手对照着看。1. 为什么在 SWT 里我会先考虑 RowLayout1.1 RowLayout 到底替你做了什么事SWT 的布局体系和 Swing 差别很大。Swing 的布局管理器是建议性的容器总会尽量接受而 SWT 的布局是命令式的你给 Composite 设了布局它就在每次 layout 时把子控件的 x/y/width/height 硬算出来并直接 setBounds。RowLayout 干的活本质上是三步第一逐个询问子控件的首选尺寸preferred size第二按主方向依次累加宽度或高度和间距第三遇到容器边界就换行最后算出整个 Composite 需要多大。这套逻辑听着简单但它的价值在于你不用关心坐标。想象一下手写 setBounds 排十个按钮窗口一拉宽就得重算一遍还得处理不同字体、不同 DPI 下的文字宽度差异——RowLayout 用 computeSize 帮你把这层屏蔽掉了。控件自己知道我这段文字需要多宽布局管理器只负责摆放职责切得很干净。我在实际项目里最常用它的两个地方一是对话框底部的确定/取消按钮区二是每行两三个控件的简易表单。这两类需求的共同点是元素数量少、方向单一、不需要严格列对齐。只要满足这三点RowLayout 的性价比就是最高的。1.2 和 FillLayout、GridLayout 的取舍逻辑很多人一上来就用 GridLayout理由是万能。这话没错但万能意味着你得为每个控件写 GridData一个简单的三按钮对话框要写三段 layoutData代码噪音很大。我在评审代码时看到过一段 30 行的 GridLayout 配置只为了排两个按钮这就是典型的过度设计。FillLayout 是最省事的但它只做等分填充所有子控件尺寸一样按钮会被拉成同样宽的方块文字短的按钮留一堆空白视觉上很难看。RowLayout 正好卡在两者中间它尊重控件的首选尺寸pack 为 true 时又能通过 fill 让高度统一还能用 RowData 单独指定某个控件的宽度。下面这张表是我自己在选型时的判断依据贴在工位上那种布局适用场景不适用场景代码量FillLayout完全等分的网格、图片平铺控件尺寸需要差异化极少RowLayout工具条、按钮栏、单行表单、流式标签需要列对齐、跨行合并少GridLayout复杂表单、需要列宽一致、跨列简单单行排列多FormLayout需要相互锚定、绝对定位式布局快速搭建、元素多多选型的关键判断只有一句如果你需要第 2 列和第 5 列左边缘对齐就别用 RowLayout。RowLayout 没有列的概念它只能保证按顺序排对齐靠控件自身宽度凑控件文字一变就全乱了。反过来如果你只是从左到右排一排排不下就换行RowLayout 是眼下最省事的选择。还有一点值得说RowLayout 支持嵌套。你可以外层用 GridLayout 划区域某个格子里的 Composite 单独用 RowLayout 排按钮。这种混用在真实项目里非常常见也是最容易出问题的地方——外层布局计算尺寸时会调用内层 Composite 的 computeSize而内层 Composite 的 computeSize 又依赖它自己的布局。如果内层用了 wrap 且没有明确的宽度约束计算就可能陷入我不知道我多宽布局就不知道给我多宽的循环。2. 先把 RowLayout 的几个开关参数吃透2.1 type 与 wrap一行还是多行这是两件事type决定主方向wrap决定空间不够时要不要换行这两个参数是完全独立的但新手经常把它们混为一谈。layout.type SWT.HORIZONTAL时控件从左往右排设成SWT.VERTICAL时控件从上往下排这时候wrap的含义变成一列排不下就往右边开新列。垂直模式用得少但在做标签云、图标面板时挺顺手。wrap true的默认状态是打开还是关闭取决于你用的构造函数版本我见过很多代码不显式设置结果在不同 SWT 版本上表现不一致。稳妥做法是永远显式写出来别依赖默认值。wrap false时控件排不下会直接溢出容器边界超出部分被裁剪掉用户看不到。这个行为在窗口缩小的时候特别容易暴露工具条右边的按钮突然消失了新手会以为是控件没创建其实是布局把它摆到了可视区外面。我在排查这类问题时习惯先把窗口拉大看一眼如果按钮又出现了那基本就是 wrap 和溢出问题。还有个小细节wrap true时换行位置是按控件整体计算的不会把控件拆成两半。所以当某个控件的宽度超过容器宽度时它会独占一行并且被截断这时候再怎么调整 spacing 也没用得回头检查这个控件的宽度来源。2.2 pack、fill、justify、center 的联动关系这四个布尔值互相影响单独看文档描述很容易犯迷糊我按自己的理解重新讲一遍。pack true默认表示控件用自己算出来的首选尺寸也就是文字多宽就多宽。pack false表示控件可以被拉伸到填满分配到的空间。注意pack 为 false 只是允许拉伸真正拉不拉还看 fill 和 justify。fill true是在交叉轴方向填满。水平排列时它让所有控件的高度都等于这一行的行高垂直排列时让所有控件的宽度都等于列宽。这个参数在工具条里特别有用——按钮、下拉框、输入框高度不一致时打开 fill 立刻整齐。justify true是在主轴方向均分剩余空间。水平排列时它把行内多余的横向空间平均分给各个控件之间的间隙。这个效果在只有两个控件、窗口很宽的时候特别明显两个控件会分别贴到左右边缘。很多确定/取消按钮区想要的就是这个效果比手工塞一个空 Label 占位优雅得多。center true让整行内容在容器里居中前提是内容没有把容器填满。这四个参数的组合里最容易出错的是justify fill同时打开控件既被横向撑开又被纵向撑满视觉上变成一堆等大的方块如果你本意是做工具条这个效果会很突兀。我的经验是工具条用 packtrue filltrue按钮区用 packtrue justifytrue表单行用 packfalse filltrue。2.3 margin 与 spacing留白不是随便给的marginWidth和marginHeight是容器四周的内边距spacing是控件之间的间隙。三个值默认都是 3 像素。默认的 3 像素在高分屏上看起来非常挤因为 SWT 的像素单位在某些平台上不做缩放适配。我一般会把工具条设成 marginWidth6~8、spacing6对话框按钮区设成 marginWidth10、marginHeight8、spacing8。这个量级在现代屏幕上比较舒服也不会让对话框显得空荡。接口和实现的一个小技巧spacing允许设为负数。负数意味着控件之间重叠。我见过一个用两个 Label 叠出文字带阴影效果的做法就是用 spacing-1 配合同一个位置的两个 Label 实现的。这种用法比较偏门但在做自定义视觉元素时确实能用。还有一点容易被忽略margin 和 spacing 都参与 computeSize 计算。也就是说你给容器加了 margin容器的首选尺寸会相应变大如果外层布局给的空间是固定的内层控件的可用空间就变小了。调试控件被压扁的问题时先数一数这层容器套了几层 margin经常能发现问题。3. RowData真正决定控件尺寸的地方3.1 width 与 height 的覆盖语义以及那个著名的缓存坑RowData 是 RowLayout 的布局数据类它有三个字段width、height、exclude。前两个的语义很容易误解——它们不是我要多宽而是在布局计算时忽略控件自己算出来的尺寸改用我指定的值。这个区别很重要。你设rowData.width 100控件就会被当成 100 像素宽参与排版哪怕它的文字实际需要 150 像素结果就是文字被截断。反过来说你不设或者设成SWT.DEFAULT控件就用自己算的尺寸。正因为它是一个覆盖值修改它之后必须触发重新布局否则界面上什么都不会变。我踩过最典型的一个坑是这样的程序运行时根据配置动态改按钮宽度代码里写了button.getLayoutData().width 120界面纹丝不动。原因有两个层面——一是没调用layout()二是 RowLayout 内部对每行的计算结果有缓存光调layout()有时候不够。正确的刷新姿势是RowData data (RowData) button.getLayoutData(); data.width 120; // flushCache 为 true 才会丢弃内部缓存并重新计算 button.getParent().layout(true, true);layout(boolean changed, boolean all)这两个参数里第二个才是是否丢弃缓存。很多代码习惯只写layout()等价于layout(false, false)缓存在的时候修改布局数据就是白改。我现在的习惯是任何在运行时修改布局数据的代码后面都跟一句layout(true, true)多一次重算的开销远比界面不刷新、调试半小时要划算。3.2 exclude比 setVisible(false) 更干净的隐藏方式exclude true的作用是这个控件还在 Composite 里但布局时当它不存在。它和control.setVisible(false)的区别在于setVisible(false) 的控件仍然占位只是看不见界面上会留一个空洞而 exclude 会把位置让出来后面的控件往前补。做权限相关的界面时这个特性特别好用。比如某个按钮当前用户没权限直接 exclude整个工具条自动收紧不会留白。相比创建时就不 addexclude 的好处是控件对象还在后续权限变化时只需翻转这个布尔值再 layout 一次。坑在于exclude 只影响布局控件本身还是可见的。如果你忘了同时调 setVisible(false)会出现控件被排除出布局但仍然画在原来的位置上跟别的控件叠在一起的诡异画面。我的做法是封装一个小工具方法两件事一起做private static void setExcluded(Control control, boolean excluded) { RowData data (RowData) control.getLayoutData(); if (data null) { data new RowData(); control.setLayoutData(data); } data.exclude excluded; control.setVisible(!excluded); control.getParent().layout(true, true); }还有一点exclude 的控件如果之前被布局过它会保留上一次的 bounds。所以刷新之后最好确认一下必要时手动 setBounds 或者干脆把它 dispose 掉重建。我一般只在频繁切换且重建成本高的场景才用 exclude其余情况直接 dispose 更省心。3.3 用空 Label 做弹性占位把按钮推到右边RowLayout 没有 GridLayout 里那种弹簧spacer概念但如果想让左边的按钮靠左、右边的按钮靠右可以用一个空的 Label 撑开中间Composite bar new Composite(parent, SWT.NONE); RowLayout layout new RowLayout(SWT.HORIZONTAL); layout.wrap false; layout.pack false; layout.fill true; layout.spacing 6; layout.marginWidth 8; layout.marginHeight 6; bar.setLayout(layout); Button left new Button(bar, SWT.PUSH); left.setText(新建); Label spacer new Label(bar, SWT.NONE); RowData spacerData new RowData(); spacerData.width 1; // 起始宽度很小 spacer.setLayoutData(spacerData); Button right new Button(bar, SWT.PUSH); right.setText(设置);这里的关键是pack false只有允许拉伸spacer 才会在布局时被撑开。但 RowLayout 对普通 Label 的拉伸行为和 GridLayout 的 grabExcessSpace 不完全一样它把剩余空间按比例分配给可拉伸的控件。如果同时存在多个 packfalse 的控件剩余空间会被它们瓜分spacer 就不一定吃得满。所以更可靠的做法是用justify true加一个占位控件或者干脆监听容器的 resize 事件手动计算 spacer 的宽度bar.addListener(SWT.Resize, e - { int used left.computeSize(SWT.DEFAULT, SWT.DEFAULT).x right.computeSize(SWT.DEFAULT, SWT.DEFAULT).x layout.spacing * 3 layout.marginWidth * 2; int remain Math.max(1, bar.getClientArea().width - used); spacerData.width remain; bar.layout(true, true); });这段代码看起来笨但我实测下来最稳尤其在嵌套布局里比依赖 stretch 分配可靠得多。代价是每次 resize 都重算一次不过工具条里的控件就那么几个开销可以忽略。4. 一步步搭一个自适应工具条4.1 骨架代码与参数说明说一千道一万不如完整跑一遍。下面这段是我常用的工具条模板直接可以抄public class ToolBarDemo { public static void main(String[] args) { Display display new Display(); Shell shell new Shell(display); shell.setText(RowLayout Toolbar); shell.setSize(600, 200); Composite bar new Composite(shell, SWT.BORDER); bar.setLayoutData(new GridData(SWT.FILL, SWT.TOP, true, false)); RowLayout layout new RowLayout(SWT.HORIZONTAL); layout.wrap true; // 窗口变窄时换行不裁剪 layout.pack true; // 控件用首选尺寸 layout.fill true; // 高度统一视觉整齐 layout.justify false; // 工具条不需要均分 layout.center false; layout.marginWidth 8; layout.marginHeight 6; layout.spacing 6; bar.setLayout(layout); for (String text : new String[]{新建, 打开, 保存, 另存为, 导出}) { Button btn new Button(bar, SWT.PUSH); btn.setText(text); } Text search new Text(bar, SWT.BORDER | SWT.SEARCH); search.setMessage(搜索); RowData searchData new RowData(); searchData.width 160; search.setLayoutData(searchData); shell.setLayout(new GridLayout()); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }几点说明。外层 Shell 用 GridLayout 只是为了让工具条贴顶这个和 RowLayout 不冲突属于典型的嵌套混用。搜索框用 RowData 指定了 160 像素宽因为 Text 的默认 computeSize 只按内容算空的时候会窄到几乎看不见。fill true在这里的作用是让按钮和搜索框高度一致。如果你把 fill 关掉按钮高度是它自己文字高度加边框搜索框高度是另一套算法两者会差几个像素肉眼能看出来不齐。4.2 尺寸计算过程复盘工具条宽度 600margin 左右各 8可用 584。五个按钮的文字宽度假设中文按钮默认字体约 14px 一个字加上按钮内边距大概各 70~80取 75五个共 375。搜索框 160。spacing 有 6 个间隔5 个控件加搜索框共 6 个间隔 5 个5×630。合计 37516030565小于 584能排下不换行。把窗口拉到 450 宽可用变成 434565 排不下wrap 生效搜索框会被挤到第二行。这时候容器高度变成两行高度加间距工具条整体变高。如果外层 Shell 的布局没有为这个变化留空间比如工具条所在的 GridData 设了固定高度第二行就会被裁掉。这个推演过程很土但非常有用。我遇到布局问题时第一反应就是拿计算器把宽度加一遍看看到底是排不下还是算错了。大部分奇怪的布局表现一算就水落石出。4.3 窗口缩放时的表现调试调试 RowLayout 的自适应我有两个固定动作。第一个是临时给容器加个背景色bar.setBackground(display.getSystemColor(SWT.COLOR_YELLOW))缩放窗口时一眼就能看出容器实际占了多大、控件有没有溢出。颜色对比比看边框直观得多尤其是控件背景被系统主题覆盖的时候。第二个是打印 clientAreabar.addListener(SWT.Resize, e - { Rectangle area bar.getClientArea(); System.out.println(client area.width x area.height computed bar.computeSize(SWT.DEFAULT, SWT.DEFAULT)); });对比实际区域和计算尺寸如果 computed 明显大于 client说明内容排不下被裁了如果 computed 远小于 client说明有本该填充的空间没填上。这两个数字一对比问题方向就定了。还有一个现象值得单独说在某些平台上拖动窗口边缘连续缩放时控件会闪烁。这不是 RowLayout 的问题是 SWT 的 paint 和 layout 节奏问题。缓解办法是在 Resize 事件里做防抖或者给容器开双缓冲SWT.DOUBLE_BUFFERED但 Composite 未必支持。我一般不做额外处理因为正常用户不会长时间拖着窗口边缘来回拉。5. 换行wrap与容器尺寸的纠缠5.1 wrap 打开后容器高度为什么算不对这是 RowLayout 最容易出问题的地方我专门花时间研究过源码层面的原因。RowLayout 计算高度时需要知道按当前宽度能排几行而当前宽度来自哪里来自父容器给的 wHint。如果父容器在计算尺寸时传的是SWT.DEFAULTRowLayout 就不知道宽度约束只能按所有控件排一行来算高度。于是就会出现实际显示时换成了三行但容器只预留了一行的高度后两行被裁掉。解决办法是给组件明确的宽度约束。常见的两种做法一是把工具条放进 GridLayout 的单元格并且设置GridData(SWT.FILL, ..., true, false)让 GridLayout 在布局时传入明确的宽度。GridLayout 在布局阶段是知道列宽的所以传给子容器的 wHint 是准确值RowLayout 就能算对行数。二是自己接管监听容器的宽度变化手动调layout()。前提是容器的宽度已经确定不能是跟着内容走的模式。这两种做法的本质是一样的必须有一方先确定宽度。width 和 height 在 wrap 场景下不能同时是自由的否则就是死循环。5.2 和 ScrolledComposite 一起用时要注意什么ScrolledComposite 的场景更麻烦因为它内部的内容content尺寸决定了滚动条。如果 content 用了 RowLayout 且 wraptrue你需要告诉它宽度就是可视区宽度别自己无限延伸。标准写法是ScrolledComposite sc new ScrolledComposite(parent, SWT.V_SCROLL | SWT.H_SCROLL); sc.setExpandHorizontal(true); sc.setExpandVertical(true); Composite content new Composite(sc, SWT.NONE); RowLayout layout new RowLayout(SWT.HORIZONTAL); layout.wrap true; content.setLayout(layout); // ... 添加控件 sc.setContent(content); sc.setMinSize(content.computeSize(SWT.DEFAULT, SWT.DEFAULT)); // 关键可视区宽度变化时重新约束 content 宽度并更新最小高度 sc.addListener(SWT.Resize, e - { int width sc.getClientArea().width; Point size content.computeSize(width, SWT.DEFAULT, true); content.setSize(size); sc.setMinSize(size); });这里computeSize(width, SWT.DEFAULT, true)的第三个参数传 true 很重要意思是忽略缓存重新算。如果传 falsecontent 之前算过的高度会被复用窗口变宽后行数变少高度却还是旧值下面会多出一大块空白。我遇到过一个更隐蔽的情况内容里有一个动态增删的控件增删之后调了content.layout()但 ScrolledComposite 的 minSize 没更新滚动条长度还是旧的。这类问题的通用解法是任何影响内容尺寸的操作之后都重新走一遍computeSize → setMinSize的流程。写成一个 refresh 方法每次改完都调比到处补漏强。5.3 控件数量多的时候RowLayout 的性能表现RowLayout 的布局算法是逐行扫描每确定一个控件的位置都要和当前行剩余宽度比较行数多的时候复杂度接近 O(n × 行数)。控件数量在几十个的时候完全感觉不到上百个开始有轻微延迟上千个就会明显卡顿尤其是 resize 的时候连续触发。如果你的场景是几百个标签流式排列我建议换成自定义的虚拟布局只对可视区内的控件做位置计算其余的不参与。或者干脆用 Table/Tree 的虚拟模式。RowLayout 的设计目标是少量控件的方向性排列把它当流式布局引擎用属于用错了工具。还有一个隐藏的性能点在 layout 过程中创建控件。有些人会在 Resize 事件里根据宽度动态创建或销毁控件然后立刻 layout。这个循环里每一轮都触发 computeSize而 computeSize 会走控件的文字测量成本不低。我做过一次压测两百个按钮在 resize 里反复重建拖窗口能明显感到掉帧。正确做法是控件只创建一次通过 exclude 或者 RowData 控制显示避免重复创建。6. 常见问题排查速查与实操心得6.1 现象、原因、解决对照表现象最可能的原因处理方式改了 RowData.width 界面没反应没触发重算或缓存未清调layout(true, true)控件排到容器外看不见wrapfalse 且总宽度超出打开 wrap 或减小控件宽度换行后下半部分被裁掉容器高度按单行计算父布局传入明确宽度约束控件高度参差不齐fillfalse打开 fill或统一 RowData.height按钮之间间距过大justifytrue 且容器过宽关掉 justify或改用占位控件控件消失在界面上excludetrue 但没 setVisible(false)两件事一起做文字被截断RowData.width 小于实际文字宽度去掉宽度覆盖或加大数值放入 ScrolledComposite 后滚动条不对minSize 没随内容更新重新 computeSize 并 setMinSize这张表我基本是照着排错顺序写的。遇到布局问题先看是不是没刷新再看是不是算不对最后才看参数配错。实际经验里前两类占了七八成。6.2 几条不那么像文档的心得第一条先让容器有明确尺寸再谈内部布局。我见过太多人对着内层的一堆 RowLayout 参数调了半天最后发现是外层容器根本没有合适的大小内层怎么调都是错的。调试顺序应该是由外向内而不是盯着一层死磕。第二条别用 RowLayout 做需要列对齐的东西。有一次我看到一个表单标签宽度靠 RowData.width 一个个写死成 80看着挺整齐但换个语言环境、换个字体全部错位。这种需求就应该用 GridLayout 的列宽统一或者用 FormLayout 锚定。RowLayout 的对齐是凑出来的不是算出来的凑出来的东西经不起变化。第三条能不用 exclude 就不用。它看起来很方便但它是布局层面的状态和控件的可见性、父容器的刷新时机都有微妙的交互。我现在的默认策略是需要隐藏就 dispose需要复现就重建。只有那种频繁切换、重建成本确实高的场景才考虑 exclude并且封装成统一方法避免散落在各处。第四条给每个 RowData 都显式赋值别依赖 null 判断。SWT 的布局代码里到处是data null的判断行为是当作默认值处理。但一旦你在某处 new 了一个 RowData 只设了 widthheight 就是SWT.DEFAULT值为 -1这个 -1 参与某些计算时会有意外。我的习惯是写完 setLayoutData 就顺手把两个字段都写清楚哪怕写SWT.DEFAULT。第五条切换主题或字体后重新验证一遍。SWT 的控件尺寸和字体强相关系统字体放大到 125% 之后原来刚好排得下的工具条可能就换行了原来设了固定宽度的输入框可能就截断文字了。这不是 bug是固定宽度覆盖的固有代价。所以我在用 RowData.width 时会尽量留 15% 的余量而不是卡着字数算。第六条验收的时候用小窗口试一次。布局问题几乎全在小窗口下暴露正常尺寸下什么都看不出来。我的习惯是开发完一个界面把窗口拉到 400 像素宽、再拉到最大两个极端各看一眼。这一分钟能省掉后面很多返工。最后再分享一个小技巧如果你不确定某个布局参数该不该开别猜写个十行的小 demo 单独试。SWT 布局的交互远比文档描述的复杂有些组合的效果只有跑起来才知道。我自己的工程里有个LayoutLab目录专门放这种一次性的验证代码攒了二十多个文件每次遇到拿不准的组合就翻出来改一改。比在网上翻帖子快得多也比凭记忆猜靠谱得多。
SWT 里做桌面界面最容易被低估的往往不是控件而是布局。RowLayout 这个名字听起来平平无奇——不就是一行一行排吗可我带过的几个项目里真正把 RowLayout 用明白的人并不多更多人是在 GridLayout 里绕不出来之后才回头发现这个被冷落的类。RowLayout 是 SWT 提供的行式布局管理器它把子控件按水平方向或垂直方向依次排开空间不够时自动换行配合 RowData 还能做固定宽高、动态隐藏这类操作。它最擅长的场景是工具条、按钮栏、标签加输入框这种顺着一个方向排的需求代码量比 GridLayout 少一大截可读性也好。但它有几个坑比如 RowData 改完不生效、wrap 打开后容器高度算不对、justify 和 fill 一起用出现诡异拉伸。这篇内容就是把这些年踩过的、看别人踩过的坑串起来从参数语义讲到实操代码再到排查手段适合刚接触 SWT 的新手也适合写过一段时间但总觉得布局不太听话的老手对照着看。1. 为什么在 SWT 里我会先考虑 RowLayout1.1 RowLayout 到底替你做了什么事SWT 的布局体系和 Swing 差别很大。Swing 的布局管理器是建议性的容器总会尽量接受而 SWT 的布局是命令式的你给 Composite 设了布局它就在每次 layout 时把子控件的 x/y/width/height 硬算出来并直接 setBounds。RowLayout 干的活本质上是三步第一逐个询问子控件的首选尺寸preferred size第二按主方向依次累加宽度或高度和间距第三遇到容器边界就换行最后算出整个 Composite 需要多大。这套逻辑听着简单但它的价值在于你不用关心坐标。想象一下手写 setBounds 排十个按钮窗口一拉宽就得重算一遍还得处理不同字体、不同 DPI 下的文字宽度差异——RowLayout 用 computeSize 帮你把这层屏蔽掉了。控件自己知道我这段文字需要多宽布局管理器只负责摆放职责切得很干净。我在实际项目里最常用它的两个地方一是对话框底部的确定/取消按钮区二是每行两三个控件的简易表单。这两类需求的共同点是元素数量少、方向单一、不需要严格列对齐。只要满足这三点RowLayout 的性价比就是最高的。1.2 和 FillLayout、GridLayout 的取舍逻辑很多人一上来就用 GridLayout理由是万能。这话没错但万能意味着你得为每个控件写 GridData一个简单的三按钮对话框要写三段 layoutData代码噪音很大。我在评审代码时看到过一段 30 行的 GridLayout 配置只为了排两个按钮这就是典型的过度设计。FillLayout 是最省事的但它只做等分填充所有子控件尺寸一样按钮会被拉成同样宽的方块文字短的按钮留一堆空白视觉上很难看。RowLayout 正好卡在两者中间它尊重控件的首选尺寸pack 为 true 时又能通过 fill 让高度统一还能用 RowData 单独指定某个控件的宽度。下面这张表是我自己在选型时的判断依据贴在工位上那种布局适用场景不适用场景代码量FillLayout完全等分的网格、图片平铺控件尺寸需要差异化极少RowLayout工具条、按钮栏、单行表单、流式标签需要列对齐、跨行合并少GridLayout复杂表单、需要列宽一致、跨列简单单行排列多FormLayout需要相互锚定、绝对定位式布局快速搭建、元素多多选型的关键判断只有一句如果你需要第 2 列和第 5 列左边缘对齐就别用 RowLayout。RowLayout 没有列的概念它只能保证按顺序排对齐靠控件自身宽度凑控件文字一变就全乱了。反过来如果你只是从左到右排一排排不下就换行RowLayout 是眼下最省事的选择。还有一点值得说RowLayout 支持嵌套。你可以外层用 GridLayout 划区域某个格子里的 Composite 单独用 RowLayout 排按钮。这种混用在真实项目里非常常见也是最容易出问题的地方——外层布局计算尺寸时会调用内层 Composite 的 computeSize而内层 Composite 的 computeSize 又依赖它自己的布局。如果内层用了 wrap 且没有明确的宽度约束计算就可能陷入我不知道我多宽布局就不知道给我多宽的循环。2. 先把 RowLayout 的几个开关参数吃透2.1 type 与 wrap一行还是多行这是两件事type决定主方向wrap决定空间不够时要不要换行这两个参数是完全独立的但新手经常把它们混为一谈。layout.type SWT.HORIZONTAL时控件从左往右排设成SWT.VERTICAL时控件从上往下排这时候wrap的含义变成一列排不下就往右边开新列。垂直模式用得少但在做标签云、图标面板时挺顺手。wrap true的默认状态是打开还是关闭取决于你用的构造函数版本我见过很多代码不显式设置结果在不同 SWT 版本上表现不一致。稳妥做法是永远显式写出来别依赖默认值。wrap false时控件排不下会直接溢出容器边界超出部分被裁剪掉用户看不到。这个行为在窗口缩小的时候特别容易暴露工具条右边的按钮突然消失了新手会以为是控件没创建其实是布局把它摆到了可视区外面。我在排查这类问题时习惯先把窗口拉大看一眼如果按钮又出现了那基本就是 wrap 和溢出问题。还有个小细节wrap true时换行位置是按控件整体计算的不会把控件拆成两半。所以当某个控件的宽度超过容器宽度时它会独占一行并且被截断这时候再怎么调整 spacing 也没用得回头检查这个控件的宽度来源。2.2 pack、fill、justify、center 的联动关系这四个布尔值互相影响单独看文档描述很容易犯迷糊我按自己的理解重新讲一遍。pack true默认表示控件用自己算出来的首选尺寸也就是文字多宽就多宽。pack false表示控件可以被拉伸到填满分配到的空间。注意pack 为 false 只是允许拉伸真正拉不拉还看 fill 和 justify。fill true是在交叉轴方向填满。水平排列时它让所有控件的高度都等于这一行的行高垂直排列时让所有控件的宽度都等于列宽。这个参数在工具条里特别有用——按钮、下拉框、输入框高度不一致时打开 fill 立刻整齐。justify true是在主轴方向均分剩余空间。水平排列时它把行内多余的横向空间平均分给各个控件之间的间隙。这个效果在只有两个控件、窗口很宽的时候特别明显两个控件会分别贴到左右边缘。很多确定/取消按钮区想要的就是这个效果比手工塞一个空 Label 占位优雅得多。center true让整行内容在容器里居中前提是内容没有把容器填满。这四个参数的组合里最容易出错的是justify fill同时打开控件既被横向撑开又被纵向撑满视觉上变成一堆等大的方块如果你本意是做工具条这个效果会很突兀。我的经验是工具条用 packtrue filltrue按钮区用 packtrue justifytrue表单行用 packfalse filltrue。2.3 margin 与 spacing留白不是随便给的marginWidth和marginHeight是容器四周的内边距spacing是控件之间的间隙。三个值默认都是 3 像素。默认的 3 像素在高分屏上看起来非常挤因为 SWT 的像素单位在某些平台上不做缩放适配。我一般会把工具条设成 marginWidth6~8、spacing6对话框按钮区设成 marginWidth10、marginHeight8、spacing8。这个量级在现代屏幕上比较舒服也不会让对话框显得空荡。接口和实现的一个小技巧spacing允许设为负数。负数意味着控件之间重叠。我见过一个用两个 Label 叠出文字带阴影效果的做法就是用 spacing-1 配合同一个位置的两个 Label 实现的。这种用法比较偏门但在做自定义视觉元素时确实能用。还有一点容易被忽略margin 和 spacing 都参与 computeSize 计算。也就是说你给容器加了 margin容器的首选尺寸会相应变大如果外层布局给的空间是固定的内层控件的可用空间就变小了。调试控件被压扁的问题时先数一数这层容器套了几层 margin经常能发现问题。3. RowData真正决定控件尺寸的地方3.1 width 与 height 的覆盖语义以及那个著名的缓存坑RowData 是 RowLayout 的布局数据类它有三个字段width、height、exclude。前两个的语义很容易误解——它们不是我要多宽而是在布局计算时忽略控件自己算出来的尺寸改用我指定的值。这个区别很重要。你设rowData.width 100控件就会被当成 100 像素宽参与排版哪怕它的文字实际需要 150 像素结果就是文字被截断。反过来说你不设或者设成SWT.DEFAULT控件就用自己算的尺寸。正因为它是一个覆盖值修改它之后必须触发重新布局否则界面上什么都不会变。我踩过最典型的一个坑是这样的程序运行时根据配置动态改按钮宽度代码里写了button.getLayoutData().width 120界面纹丝不动。原因有两个层面——一是没调用layout()二是 RowLayout 内部对每行的计算结果有缓存光调layout()有时候不够。正确的刷新姿势是RowData data (RowData) button.getLayoutData(); data.width 120; // flushCache 为 true 才会丢弃内部缓存并重新计算 button.getParent().layout(true, true);layout(boolean changed, boolean all)这两个参数里第二个才是是否丢弃缓存。很多代码习惯只写layout()等价于layout(false, false)缓存在的时候修改布局数据就是白改。我现在的习惯是任何在运行时修改布局数据的代码后面都跟一句layout(true, true)多一次重算的开销远比界面不刷新、调试半小时要划算。3.2 exclude比 setVisible(false) 更干净的隐藏方式exclude true的作用是这个控件还在 Composite 里但布局时当它不存在。它和control.setVisible(false)的区别在于setVisible(false) 的控件仍然占位只是看不见界面上会留一个空洞而 exclude 会把位置让出来后面的控件往前补。做权限相关的界面时这个特性特别好用。比如某个按钮当前用户没权限直接 exclude整个工具条自动收紧不会留白。相比创建时就不 addexclude 的好处是控件对象还在后续权限变化时只需翻转这个布尔值再 layout 一次。坑在于exclude 只影响布局控件本身还是可见的。如果你忘了同时调 setVisible(false)会出现控件被排除出布局但仍然画在原来的位置上跟别的控件叠在一起的诡异画面。我的做法是封装一个小工具方法两件事一起做private static void setExcluded(Control control, boolean excluded) { RowData data (RowData) control.getLayoutData(); if (data null) { data new RowData(); control.setLayoutData(data); } data.exclude excluded; control.setVisible(!excluded); control.getParent().layout(true, true); }还有一点exclude 的控件如果之前被布局过它会保留上一次的 bounds。所以刷新之后最好确认一下必要时手动 setBounds 或者干脆把它 dispose 掉重建。我一般只在频繁切换且重建成本高的场景才用 exclude其余情况直接 dispose 更省心。3.3 用空 Label 做弹性占位把按钮推到右边RowLayout 没有 GridLayout 里那种弹簧spacer概念但如果想让左边的按钮靠左、右边的按钮靠右可以用一个空的 Label 撑开中间Composite bar new Composite(parent, SWT.NONE); RowLayout layout new RowLayout(SWT.HORIZONTAL); layout.wrap false; layout.pack false; layout.fill true; layout.spacing 6; layout.marginWidth 8; layout.marginHeight 6; bar.setLayout(layout); Button left new Button(bar, SWT.PUSH); left.setText(新建); Label spacer new Label(bar, SWT.NONE); RowData spacerData new RowData(); spacerData.width 1; // 起始宽度很小 spacer.setLayoutData(spacerData); Button right new Button(bar, SWT.PUSH); right.setText(设置);这里的关键是pack false只有允许拉伸spacer 才会在布局时被撑开。但 RowLayout 对普通 Label 的拉伸行为和 GridLayout 的 grabExcessSpace 不完全一样它把剩余空间按比例分配给可拉伸的控件。如果同时存在多个 packfalse 的控件剩余空间会被它们瓜分spacer 就不一定吃得满。所以更可靠的做法是用justify true加一个占位控件或者干脆监听容器的 resize 事件手动计算 spacer 的宽度bar.addListener(SWT.Resize, e - { int used left.computeSize(SWT.DEFAULT, SWT.DEFAULT).x right.computeSize(SWT.DEFAULT, SWT.DEFAULT).x layout.spacing * 3 layout.marginWidth * 2; int remain Math.max(1, bar.getClientArea().width - used); spacerData.width remain; bar.layout(true, true); });这段代码看起来笨但我实测下来最稳尤其在嵌套布局里比依赖 stretch 分配可靠得多。代价是每次 resize 都重算一次不过工具条里的控件就那么几个开销可以忽略。4. 一步步搭一个自适应工具条4.1 骨架代码与参数说明说一千道一万不如完整跑一遍。下面这段是我常用的工具条模板直接可以抄public class ToolBarDemo { public static void main(String[] args) { Display display new Display(); Shell shell new Shell(display); shell.setText(RowLayout Toolbar); shell.setSize(600, 200); Composite bar new Composite(shell, SWT.BORDER); bar.setLayoutData(new GridData(SWT.FILL, SWT.TOP, true, false)); RowLayout layout new RowLayout(SWT.HORIZONTAL); layout.wrap true; // 窗口变窄时换行不裁剪 layout.pack true; // 控件用首选尺寸 layout.fill true; // 高度统一视觉整齐 layout.justify false; // 工具条不需要均分 layout.center false; layout.marginWidth 8; layout.marginHeight 6; layout.spacing 6; bar.setLayout(layout); for (String text : new String[]{新建, 打开, 保存, 另存为, 导出}) { Button btn new Button(bar, SWT.PUSH); btn.setText(text); } Text search new Text(bar, SWT.BORDER | SWT.SEARCH); search.setMessage(搜索); RowData searchData new RowData(); searchData.width 160; search.setLayoutData(searchData); shell.setLayout(new GridLayout()); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }几点说明。外层 Shell 用 GridLayout 只是为了让工具条贴顶这个和 RowLayout 不冲突属于典型的嵌套混用。搜索框用 RowData 指定了 160 像素宽因为 Text 的默认 computeSize 只按内容算空的时候会窄到几乎看不见。fill true在这里的作用是让按钮和搜索框高度一致。如果你把 fill 关掉按钮高度是它自己文字高度加边框搜索框高度是另一套算法两者会差几个像素肉眼能看出来不齐。4.2 尺寸计算过程复盘工具条宽度 600margin 左右各 8可用 584。五个按钮的文字宽度假设中文按钮默认字体约 14px 一个字加上按钮内边距大概各 70~80取 75五个共 375。搜索框 160。spacing 有 6 个间隔5 个控件加搜索框共 6 个间隔 5 个5×630。合计 37516030565小于 584能排下不换行。把窗口拉到 450 宽可用变成 434565 排不下wrap 生效搜索框会被挤到第二行。这时候容器高度变成两行高度加间距工具条整体变高。如果外层 Shell 的布局没有为这个变化留空间比如工具条所在的 GridData 设了固定高度第二行就会被裁掉。这个推演过程很土但非常有用。我遇到布局问题时第一反应就是拿计算器把宽度加一遍看看到底是排不下还是算错了。大部分奇怪的布局表现一算就水落石出。4.3 窗口缩放时的表现调试调试 RowLayout 的自适应我有两个固定动作。第一个是临时给容器加个背景色bar.setBackground(display.getSystemColor(SWT.COLOR_YELLOW))缩放窗口时一眼就能看出容器实际占了多大、控件有没有溢出。颜色对比比看边框直观得多尤其是控件背景被系统主题覆盖的时候。第二个是打印 clientAreabar.addListener(SWT.Resize, e - { Rectangle area bar.getClientArea(); System.out.println(client area.width x area.height computed bar.computeSize(SWT.DEFAULT, SWT.DEFAULT)); });对比实际区域和计算尺寸如果 computed 明显大于 client说明内容排不下被裁了如果 computed 远小于 client说明有本该填充的空间没填上。这两个数字一对比问题方向就定了。还有一个现象值得单独说在某些平台上拖动窗口边缘连续缩放时控件会闪烁。这不是 RowLayout 的问题是 SWT 的 paint 和 layout 节奏问题。缓解办法是在 Resize 事件里做防抖或者给容器开双缓冲SWT.DOUBLE_BUFFERED但 Composite 未必支持。我一般不做额外处理因为正常用户不会长时间拖着窗口边缘来回拉。5. 换行wrap与容器尺寸的纠缠5.1 wrap 打开后容器高度为什么算不对这是 RowLayout 最容易出问题的地方我专门花时间研究过源码层面的原因。RowLayout 计算高度时需要知道按当前宽度能排几行而当前宽度来自哪里来自父容器给的 wHint。如果父容器在计算尺寸时传的是SWT.DEFAULTRowLayout 就不知道宽度约束只能按所有控件排一行来算高度。于是就会出现实际显示时换成了三行但容器只预留了一行的高度后两行被裁掉。解决办法是给组件明确的宽度约束。常见的两种做法一是把工具条放进 GridLayout 的单元格并且设置GridData(SWT.FILL, ..., true, false)让 GridLayout 在布局时传入明确的宽度。GridLayout 在布局阶段是知道列宽的所以传给子容器的 wHint 是准确值RowLayout 就能算对行数。二是自己接管监听容器的宽度变化手动调layout()。前提是容器的宽度已经确定不能是跟着内容走的模式。这两种做法的本质是一样的必须有一方先确定宽度。width 和 height 在 wrap 场景下不能同时是自由的否则就是死循环。5.2 和 ScrolledComposite 一起用时要注意什么ScrolledComposite 的场景更麻烦因为它内部的内容content尺寸决定了滚动条。如果 content 用了 RowLayout 且 wraptrue你需要告诉它宽度就是可视区宽度别自己无限延伸。标准写法是ScrolledComposite sc new ScrolledComposite(parent, SWT.V_SCROLL | SWT.H_SCROLL); sc.setExpandHorizontal(true); sc.setExpandVertical(true); Composite content new Composite(sc, SWT.NONE); RowLayout layout new RowLayout(SWT.HORIZONTAL); layout.wrap true; content.setLayout(layout); // ... 添加控件 sc.setContent(content); sc.setMinSize(content.computeSize(SWT.DEFAULT, SWT.DEFAULT)); // 关键可视区宽度变化时重新约束 content 宽度并更新最小高度 sc.addListener(SWT.Resize, e - { int width sc.getClientArea().width; Point size content.computeSize(width, SWT.DEFAULT, true); content.setSize(size); sc.setMinSize(size); });这里computeSize(width, SWT.DEFAULT, true)的第三个参数传 true 很重要意思是忽略缓存重新算。如果传 falsecontent 之前算过的高度会被复用窗口变宽后行数变少高度却还是旧值下面会多出一大块空白。我遇到过一个更隐蔽的情况内容里有一个动态增删的控件增删之后调了content.layout()但 ScrolledComposite 的 minSize 没更新滚动条长度还是旧的。这类问题的通用解法是任何影响内容尺寸的操作之后都重新走一遍computeSize → setMinSize的流程。写成一个 refresh 方法每次改完都调比到处补漏强。5.3 控件数量多的时候RowLayout 的性能表现RowLayout 的布局算法是逐行扫描每确定一个控件的位置都要和当前行剩余宽度比较行数多的时候复杂度接近 O(n × 行数)。控件数量在几十个的时候完全感觉不到上百个开始有轻微延迟上千个就会明显卡顿尤其是 resize 的时候连续触发。如果你的场景是几百个标签流式排列我建议换成自定义的虚拟布局只对可视区内的控件做位置计算其余的不参与。或者干脆用 Table/Tree 的虚拟模式。RowLayout 的设计目标是少量控件的方向性排列把它当流式布局引擎用属于用错了工具。还有一个隐藏的性能点在 layout 过程中创建控件。有些人会在 Resize 事件里根据宽度动态创建或销毁控件然后立刻 layout。这个循环里每一轮都触发 computeSize而 computeSize 会走控件的文字测量成本不低。我做过一次压测两百个按钮在 resize 里反复重建拖窗口能明显感到掉帧。正确做法是控件只创建一次通过 exclude 或者 RowData 控制显示避免重复创建。6. 常见问题排查速查与实操心得6.1 现象、原因、解决对照表现象最可能的原因处理方式改了 RowData.width 界面没反应没触发重算或缓存未清调layout(true, true)控件排到容器外看不见wrapfalse 且总宽度超出打开 wrap 或减小控件宽度换行后下半部分被裁掉容器高度按单行计算父布局传入明确宽度约束控件高度参差不齐fillfalse打开 fill或统一 RowData.height按钮之间间距过大justifytrue 且容器过宽关掉 justify或改用占位控件控件消失在界面上excludetrue 但没 setVisible(false)两件事一起做文字被截断RowData.width 小于实际文字宽度去掉宽度覆盖或加大数值放入 ScrolledComposite 后滚动条不对minSize 没随内容更新重新 computeSize 并 setMinSize这张表我基本是照着排错顺序写的。遇到布局问题先看是不是没刷新再看是不是算不对最后才看参数配错。实际经验里前两类占了七八成。6.2 几条不那么像文档的心得第一条先让容器有明确尺寸再谈内部布局。我见过太多人对着内层的一堆 RowLayout 参数调了半天最后发现是外层容器根本没有合适的大小内层怎么调都是错的。调试顺序应该是由外向内而不是盯着一层死磕。第二条别用 RowLayout 做需要列对齐的东西。有一次我看到一个表单标签宽度靠 RowData.width 一个个写死成 80看着挺整齐但换个语言环境、换个字体全部错位。这种需求就应该用 GridLayout 的列宽统一或者用 FormLayout 锚定。RowLayout 的对齐是凑出来的不是算出来的凑出来的东西经不起变化。第三条能不用 exclude 就不用。它看起来很方便但它是布局层面的状态和控件的可见性、父容器的刷新时机都有微妙的交互。我现在的默认策略是需要隐藏就 dispose需要复现就重建。只有那种频繁切换、重建成本确实高的场景才考虑 exclude并且封装成统一方法避免散落在各处。第四条给每个 RowData 都显式赋值别依赖 null 判断。SWT 的布局代码里到处是data null的判断行为是当作默认值处理。但一旦你在某处 new 了一个 RowData 只设了 widthheight 就是SWT.DEFAULT值为 -1这个 -1 参与某些计算时会有意外。我的习惯是写完 setLayoutData 就顺手把两个字段都写清楚哪怕写SWT.DEFAULT。第五条切换主题或字体后重新验证一遍。SWT 的控件尺寸和字体强相关系统字体放大到 125% 之后原来刚好排得下的工具条可能就换行了原来设了固定宽度的输入框可能就截断文字了。这不是 bug是固定宽度覆盖的固有代价。所以我在用 RowData.width 时会尽量留 15% 的余量而不是卡着字数算。第六条验收的时候用小窗口试一次。布局问题几乎全在小窗口下暴露正常尺寸下什么都看不出来。我的习惯是开发完一个界面把窗口拉到 400 像素宽、再拉到最大两个极端各看一眼。这一分钟能省掉后面很多返工。最后再分享一个小技巧如果你不确定某个布局参数该不该开别猜写个十行的小 demo 单独试。SWT 布局的交互远比文档描述的复杂有些组合的效果只有跑起来才知道。我自己的工程里有个LayoutLab目录专门放这种一次性的验证代码攒了二十多个文件每次遇到拿不准的组合就翻出来改一改。比在网上翻帖子快得多也比凭记忆猜靠谱得多。
