HarmonyOS7 @Builder 把重复 UI 收起来:别急着拆组件

发布时间:2026/7/22 0:00:16
HarmonyOS7 @Builder 把重复 UI 收起来:别急着拆组件 文章目录前言为什么这个问题经常被写乱Builder 和组件怎么选先把页面目标想清楚完整 ArkUI 示例把关键代码一段段拆开Builder 不适合装太多业务新手最容易踩的坑放进真实项目还要补什么写在最后前言页面里重复三次以上的标题栏、设置行、状态标签复制粘贴肯定能跑但后面改样式会很痛苦。这时候很多人会立刻拆组件。我的习惯是先判断这个 UI 片段是不是只在当前页面复用有没有独立状态会不会跨页面使用如果答案都偏轻用Builder更合适。Builder适合收起当前组件里的局部重复不是所有组件拆分的替代品。为什么这个问题经常被写乱Builder 把重复 UI 收起来 这类内容很容易被写成“代码能跑就算讲完了”但对初学者来说这恰恰是最不够的地方。真正让人卡住的往往不是某个组件名记不住而是不知道这段代码为什么要这样拆、状态为什么要这样放、以后需求变化时应该从哪里改。所以这篇文章不只想给你一个能跑的例子更想把背后的判断过程讲清楚。你只要把这个判断过程吃透后面自己改页面、补需求、查问题时心里会稳很多。Builder 和组件怎么选写法适合场景代价直接复制一两处临时 UI后期样式容易漂移Builder同页面局部重复不适合承载复杂业务状态独立组件多页面复用、有明确接口命名和参数要设计清楚设置页是Builder很适合的场景分组标题、普通设置行、开关设置行都很像但还没必要拆成一堆文件。复制粘贴省的是当下几分钟后面统一改样式时会还回来。先把页面目标想清楚在真正写代码之前先别急着盯着 API。更有用的做法是先想清楚这个页面到底想解决什么问题用户最在意的反馈是什么哪些状态必须一直保持一致。当你先把这条主线想明白再回头看组件和状态设计很多选择都会顺理成章。对小白来说这一步尤其重要因为它能帮你从“照着抄”慢慢过渡到“看得懂、改得动”。完整 ArkUI 示例下面这个设置页用三个Builder收起重复 UI分组标题、普通设置行、开关设置行。EntryComponentstruct SettingsBuilderPage{StatepushEnabled:booleantrueStateuseCellular:booleanfalseBuilderSectionTitle(title:string){Text(title).fontSize(13).fontColor(#888888).width(100%).padding({left:4,top:12,bottom:6})}BuilderSettingRow(title:string,desc:string,value:string){Row(){Column({space:4}){Text(title).fontSize(16).fontColor(#222222)Text(desc).fontSize(12).fontColor(#888888).maxLines(1)}.alignItems(HorizontalAlign.Start).layoutWeight(1)Text(value).fontSize(14).fontColor(#666666)Text().fontSize(16).fontColor(#BBBBBB).margin({left:6})}.padding(14).backgroundColor(Color.White)}BuilderSwitchRow(title:string,desc:string,enabled:boolean,onChange:(value:boolean)void){Row(){Column({space:4}){Text(title).fontSize(16)Text(desc).fontSize(12).fontColor(#888888)}.alignItems(HorizontalAlign.Start).layoutWeight(1)Toggle({type:ToggleType.Switch,isOn:enabled}).onChange((value:boolean)onChange(value))}.padding(14).backgroundColor(Color.White)}build(){Column(){this.SectionTitle(账号)this.SettingRow(个人资料,头像、昵称和简介,去完善)this.SettingRow(登录设备,查看最近登录的手机和平板,2 台)this.SectionTitle(通知)this.SwitchRow(消息推送,订单和系统通知会及时提醒,this.pushEnabled,(value:boolean){this.pushEnabledvalue})this.SwitchRow(使用蜂窝网络同步,非 Wi-Fi 环境也同步草稿,this.useCellular,(value:boolean){this.useCellularvalue})}.padding(16).backgroundColor(#F5F7FA)}}把关键代码一段段拆开SectionTitle是最轻的 Builder只接收一个标题。它把字号、颜色、间距固定住后面设置页分组多了也不会样式漂移。SettingRow负责普通可点击设置项。左侧是标题和说明右侧是当前值和箭头。layoutWeight(1)让左侧说明占剩余空间右侧值不会被长文案挤掉。SwitchRow比普通行多一个开关状态和回调。这里没有让 Builder 自己保存状态而是通过enabled和onChange把状态交回页面。这样状态来源仍然清楚。这三个 Builder 都只服务当前页面。如果以后多个页面都要用同样的设置行再考虑抽成SettingRowComponent。Builder 不适合装太多业务如果一个 UI 片段开始有自己的生命周期、网络请求、复杂状态继续塞在Builder里就不合适了。那时候它已经不是“局部模板”而是一个真正的业务组件。参数也别太多。一个 Builder 如果传了七八个参数读调用处会很费劲。可以先合成一个配置对象或者直接拆组件。新手最容易踩的坑这一类示例最容易让人产生错觉界面出来了就以为已经掌握了。其实真正容易出问题的地方通常都在效果之外比如状态有没有收拢、失败后怎么兜底、以后要扩展时会不会牵一发动全身。所以你练这篇内容时别只看“现在能不能跑”还要继续看“以后好不好改”。能把这个习惯养起来你写出来的页面会比单纯照着示例拼出来的页面稳很多。放进真实项目还要补什么示例代码的重点是把核心思路讲明白所以很多工程化细节会故意省掉。真正落到项目里时你通常还要继续补接口联动、异常处理、边界保护、资源抽离以及和其他页面状态之间的配合。写在最后比较稳的做法是分三步走先把结构和职责立住再把真实业务接进去最后再优化视觉和交互体验。这样改出来的页面不只是“能演示”而是真的更接近可以长期维护的业务代码。