HarmonyOS7 订单行布局避坑：flexShrink 该让谁收缩

文章目录订单行先定优先级数据结构先看这里状态变量负责让页面动起来布局代码怎么读交互逻辑别藏太深使用时我会怎么改完整代码代码里的几个细节常见改造坑写在最后订单号、商品名、状态、金额都想出现不能平均挤压。这里重点看谁可以让空间。这里我会多讲一点代码。很多教程只把完整代码贴出来看着是完整了但读者真正改项目时还是不知道该动哪里。下面这几段会把数据、状态、布局和事件拆开说。订单行先定优先级这个案例对应的是「订单信息行」。如果只是运行一下效果当然很快但真要把它改进自己的项目里最好先把页面分成“数据层、状态层、布局层、交互层”四块。我比较推荐这种读法先看interface定义再看State最后看build()里的Column、Row、Flex怎么嵌套。这样不容易被一长串样式绕晕。数据结构先看这里这份代码里的核心数据模型是订单数据结构。它决定了页面每一项需要哪些字段比如标题、描述、颜色、状态、价格、数量、角标等。很多 ArkUI 页面写得乱根源不是布局而是数据字段没想清楚。如果你要接真实接口优先改这一层。接口字段名和页面字段名不一致也没关系可以在请求完成后做一次映射别把接口返回结构直接塞进 UI 里。那样短期省事后面改样式会很难受。状态变量负责让页面动起来这个案例里最关键的状态是selectedOrder。它不是摆设页面里的选中、展开、切换、数量变化、输入内容基本都靠它驱动。写 HarmonyOS7 ArkUI 页面时我会刻意把“会变的东西”和“不会变的静态数据”分开。像orderList这种列表数据负责提供内容selectedOrder负责描述当前用户操作后的界面状态。这样读代码时很清楚数据从哪里来界面为什么变。布局代码怎么读布局部分不要从第一行样式读到最后一行这样很累。先找最外层容器看页面是纵向结构还是横向结构再看每个区域内部是Row、Column还是Flex。这个案例的布局重点是flexShrink的重点是决定谁让空间状态、金额这类信息不要被压没。如果你调页面时发现内容挤压、对齐不准、间距失控优先检查这几个地方固定宽高是不是太多layoutWeight或Blank是否用对列表项里长文本有没有设置省略Flex 换行条件是否满足。交互逻辑别藏太深这个页面的交互主线是点击订单卡片切换选中态长文本通过省略保持行内稳定。小案例里直接在.onClick()里改状态没问题读起来也直观。但如果后面业务变复杂比如要请求接口、弹确认框、写缓存就别把逻辑全塞在事件回调里。可以拆成一个私有方法让 UI 代码只表达“点了什么”具体怎么处理交给方法。使用时我会怎么改如果你只是学习布局直接运行下面代码就行。如果你准备放进项目里我建议按这个顺序改先替换数据数组再调整颜色和字体最后再改交互逻辑。还有一个小经验不要一开始就把所有东西拆成组件。先让页面跑通等你发现某个卡片、按钮组、列表项重复出现两三次再抽成Builder或单独组件。这样代码会更贴近真实需求。完整代码/** * Flex flexShrink弹性收缩的卡片标签行 * 知识点flexShrink 控制子项在空间不足时的收缩比例 */ interface OrderCardInfo { orderId: string productName: string statusLabel: string statusColor: string statusBg: string amount: string date: string tags: string[] } Entry Component struct OrderShrinkBehaviorPage { State shrinkMode: number 0 private orders: OrderCardInfo[] [ { orderId: NO.20240601001, productName: HarmonyOS 开发者套件 旗舰版超长名称款, statusLabel: 待支付, statusColor: #FF8C00, statusBg: #FFF8E8, amount: ¥1,299.00, date: 2024-06-01 14:32, tags: [包邮, 7天退换, 正品保障, 极速发货, 官方认证] }, { orderId: NO.20240530002, productName: 华为MatePad Pro 平板电脑, statusLabel: 配送中, statusColor: #007DFF, statusBg: #EAF3FF, amount: ¥4,888.00, date: 2024-05-30 09:15, tags: [顺丰, 已签收确认, 开具发票] }, { orderId: NO.20240528003, productName: 智能手表 SE2 碳晶灰, statusLabel: 已完成, statusColor: #07C160, statusBg: #EDFAF4, amount: ¥1,099.00, date: 2024-05-28 18:20, tags: [好评, 返现] }, ] Builder ShrinkDemo(title: string, desc: string) { Column({ space: 6 }) { Text(title).fontSize(13).fontWeight(FontWeight.Medium).fontColor(#1A1A1A) Text(desc).fontSize(11).fontColor(#999999) // flexShrink 演示行 Flex({ direction: FlexDirection.Row, alignItems: ItemAlign.Center }) { // 固定宽文字flexShrink:0不压缩 Text(不收缩) .fontSize(13) .fontColor(#FFFFFF) .backgroundColor(#FF4D4D) .padding({ left: 10, right: 10, top: 6, bottom: 6 }) .borderRadius(6) .flexShrink(0) // 会收缩的区域flexShrink:1 Text(这段文字会在空间不足时被压缩体现flexShrink效果) .fontSize(13) .fontColor(#1A1A1A) .backgroundColor(#E8F3FF) .padding({ left: 10, right: 10, top: 6, bottom: 6 }) .borderRadius(6) .maxLines(1) .textOverflow({ overflow: TextOverflow.Ellipsis }) .flexShrink(1) .margin({ left: 8 }) // 固定宽按钮flexShrink:0不压缩 Text(操作) .fontSize(13) .fontColor(#007DFF) .backgroundColor(#EAF3FF) .padding({ left: 10, right: 10, top: 6, bottom: 6 }) .borderRadius(6) .flexShrink(0) .margin({ left: 8 }) } .width(100%) .backgroundColor(#F5F5F5) .padding(10) .borderRadius(8) } } build() { Column() { // 标题 Text(flexShrink 弹性收缩) .fontSize(20) .fontWeight(FontWeight.Bold) .fontColor(#1A1A1A) .padding({ left: 16, right: 16, top: 20, bottom: 4 }) .alignSelf(ItemAlign.Start) Text(控制子项在主轴空间不足时的收缩比例0不收缩1按比例收缩) .fontSize(13) .fontColor(#888888) .padding({ left: 16, right: 16, bottom: 16 }) .alignSelf(ItemAlign.Start) // 概念演示卡片 Column({ space: 16 }) { this.ShrinkDemo( flexShrink:0 不收缩, 红色和蓝色区域 flexShrink0中间文字 flexShrink1 会被压缩 ) } .padding({ left: 16, right: 16 }) .width(100%) Divider().color(#EEEEEE).margin({ top: 16, bottom: 8 }) // 订单列表实际应用 flexShrink 的场景 Text(实际应用订单列表标签行) .fontSize(15) .fontWeight(FontWeight.Medium) .fontColor(#1A1A1A) .padding({ left: 16, right: 16, top: 8, bottom: 12 }) .alignSelf(ItemAlign.Start) Column({ space: 12 }) { ForEach(this.orders, (order: OrderCardInfo) { Column({ space: 12 }) { // 第一行订单号 状态 Flex({ direction: FlexDirection.Row, alignItems: ItemAlign.Center }) { Text(订单号 order.orderId) .fontSize(12) .fontColor(#999999) .flexShrink(1) // 可收缩 .maxLines(1) .textOverflow({ overflow: TextOverflow.Ellipsis }) Text(order.statusLabel) .fontSize(13) .fontWeight(FontWeight.Medium) .fontColor(order.statusColor) .backgroundColor(order.statusBg) .padding({ left: 8, right: 8, top: 4, bottom: 4 }) .borderRadius(6) .flexShrink(0) // 不收缩状态标签不可被压缩 .margin({ left: 8 }) } .width(100%) // 第二行商品名会被压缩 金额不压缩 Flex({ direction: FlexDirection.Row, alignItems: ItemAlign.End }) { Text(order.productName) .fontSize(15) .fontColor(#1A1A1A) .fontWeight(FontWeight.Medium) .flexShrink(1) // 商品名可以收缩 .maxLines(2) .textOverflow({ overflow: TextOverflow.Ellipsis }) .layoutWeight(1) Column({ space: 2 }) { Text(order.amount) .fontSize(17) .fontWeight(FontWeight.Bold) .fontColor(#FF4D4D) Text(order.date) .fontSize(11) .fontColor(#BBBBBB) } .alignItems(HorizontalAlign.End) .flexShrink(0) // 金额不压缩 .margin({ left: 12 }) } .width(100%) // 第三行标签列flexShrink:0 各标签不压缩超出截断 Flex({ direction: FlexDirection.Row, alignItems: ItemAlign.Center }) { ForEach(order.tags, (tag: string) { Text(tag) .fontSize(11) .fontColor(#888888) .backgroundColor(#F5F5F5) .padding({ left: 6, right: 6, top: 3, bottom: 3 }) .borderRadius(4) .flexShrink(0) // 标签不压缩超出自然溢出 .margin({ right: 6 }) }) } .width(100%) .clip(true) // 超出剪切 } .padding(16) .backgroundColor(#FFFFFF) .borderRadius(14) .shadow({ radius: 6, color: #10000000, offsetX: 0, offsetY: 2 }) }) } .padding({ left: 16, right: 16 }) .width(100%) } .width(100%) .height(100%) .backgroundColor(#F5F6FA) } }代码里的几个细节看完完整代码后可以回头重点检查三处。第一处是数据声明。订单数据结构这类结构把页面需要的字段提前摆出来后面ForEach渲染时就不会到处临时拼数据。第二处是状态更新。selectedOrder变化后相关 UI 会自动刷新这也是声明式 UI 写起来舒服的地方。你不用手动找某个控件改样式只要把状态描述清楚。第三处是容器嵌套。这个案例不是为了炫技才套Row、Column、Flex而是每一层都在解决具体排版问题。读代码时多问一句这一层容器负责什么如果答不上来它可能就该被简化。常见改造坑最容易踩的坑是把示例里的颜色、文案、尺寸都保留然后只替换数据。这样页面能跑但很难和自己的项目风格统一。另一个坑是过度依赖固定宽高。固定宽高在演示里很方便在真实设备上就未必稳。文本变长、屏幕变窄、系统字体变大都会把问题暴露出来。我一般会保留固定尺寸给图标、头像、按钮这类稳定元素文本区域、列表区域、内容卡片尽量交给弹性布局处理。写在最后这个案例的价值不只是“有一份完整代码”。更重要的是你能从里面看到 ArkUI 页面的一条基本思路数据先定义清楚状态单独管理布局按区域拆交互只改必要状态。按这个思路去写页面复杂一点也不会马上失控。