条件渲染与 ForEach — 动态 UI 的构建策略一、引言动态 UI 是现代应用开发的核心需求——不同状态展示不同内容列表数据动态填充。鸿蒙 ArkTS 提供了if/else条件渲染和ForEach循环渲染两种声明式渲染控制能力帮助开发者高效构建动态界面。MoneyTrack 在账单详情成员信息展示、统计视图切换、账单列表渲染等场景中充分运用了这两种策略实现了灵活且高性能的动态 UI 构建。二、核心知识点2.1 if/else 条件渲染完整语法if/else是 ArkTS 中最基本的条件渲染语法根据布尔表达式的值决定是否创建或保留组件。与show/hide不同if/else会完全销毁和重建组件。ArkTS 支持完整的if / else if / else多分支结构if(this.viewModeViewMode.CHART){ChartSummary({data:this.statisticsData})}elseif(this.viewModeViewMode.CALENDAR){CalendarSummary({data:this.statisticsData})}else{ListSummary({data:this.statisticsData})}关于三元运算符在 ArkTS 的build()方法中condition ? A : B三元运算符不能直接用于 UI 结构只能用于属性值的条件赋值。条件渲染必须使用if/else语句块build(){Column(){// 正确if/else 用于组件分支if(this.isPremium){PremiumBadge()}// 正确三元运算符用于属性值Text(标题).fontColor(this.isActive?#333333:#999999)}}2.2 条件渲染 vs visibility 属性对比维度if/else 条件渲染visibility 属性控制组件生命周期销毁/重建保留仅隐藏性能开销创建销毁有开销零重建开销适用场景切换频繁、结构差异大切换不频繁、结构相同内存占用不显示时不占用始终占用子组件状态重建后丢失保留选择建议如果切换频率极高如 Tab 切换且组件创建成本较低用if/else更合理如果组件需要保留状态如滚动位置用visibility控制。2.3 ForEach 列表渲染与 key 生成ForEach基于数组数据循环渲染组件列表每个数组元素对应一个 UI 实例。其完整签名为ForEach(arr:any[],// 数据源数组itemGenerator:(item,index)void,// 组件生成函数keyGenerator?:(item,index)string// key 生成函数可选)第三个参数 key 生成函数至关重要。它告诉框架如何唯一标识每个列表项以便在数组变化时进行高效的 Diff 更新// ✅ 推荐使用唯一 ID 作为 keyForEach(this.transactionList,(item:Transaction){ListItem(){TransactionCard({transaction:item})}},(item:Transaction)item.id.toString())// ❌ 不推荐使用索引作为 key索引变化会导致组件复用错误ForEach(this.transactionList,(item:Transaction,index:number){ListItem(){TransactionCard({transaction:item})}},(item:Transaction,index:number)index.toString())key 值不稳定的后果UI 错乱框架复用错误的组件实例导致列表项显示与实际数据不匹配。性能下降框架无法准确判断新增/删除项导致全量重建。动画异常列表项增删动画可能错误地应用到其他项上。2.4 ForEach 的 Diff 更新流程是否数据源数组变化keyGenerator 是否提供基于 key 做 Diff 比对基于索引位置比对匹配成功 → 更新已有组件属性未匹配 → 创建新组件 / 删除旧组件新增项 → 尾部追加删除/插入 → 后续组件整体重建增量更新性能最优性能一般当提供稳定的 key 时框架执行基于 key 的 Diff 算法精确识别新增、删除和移动的项做到最小化 DOM 操作。不使用 key 时框架退化为索引比对在列表中间插入或删除元素会导致后续所有组件重建。2.5 LazyForEach 简要说明对于超长列表数百条以上ForEach会一次性创建所有组件实例可能导致内存不足。LazyForEach是懒加载版本仅渲染当前可见区域的列表项滚动时按需创建和回收组件LazyForEach(this.dataSource,(item:Transaction){ListItem(){TransactionCard({transaction:item})}},(item:Transaction)item.id.toString())LazyForEach需要配合实现了IDataSource接口的数据源类使用适用于无限滚动、消息列表等大数据量场景。三、项目代码案例3.1 BillDetailPage 中成员信息条件渲染在products/entry/src/main/ets/views/bill/BillDetailPage.ets中根据账单类型个人/共享条件渲染成员信息区域个人账单展示仅自己可见提示家庭账单展示参与成员的头像列表if(this.billTypeBillType.SHARED){// 渲染成员头像列表Row(){ForEach(this.memberList,(member:MemberModel){Image(member.avatar).width(32).height(32).borderRadius(16)},(member:MemberModel)member.id.toString())}}else{// 渲染个人标签Text(个人账单).fontSize(14).fontColor(#999)}3.2 StatisticsView 中 ChartSummary/CalendarSummary 切换在统计页面根据用户选择的视图模式条件渲染isChartView为true时渲染ChartSummary组件图表报表isChartView为false时渲染CalendarSummary组件日历视图两种视图的数据结构不同采用条件渲染完全隔离两种 UI 实现3.3 ForEach 渲染账单列表在首页和账单页面中DailyBillGroup和BillCard通过 ForEach 渲染每日账单分组和具体账单项每个列表项使用item.id作为稳定 key保证列表更新时的性能。四、最佳实践总结始终提供稳定的 key使用数据库 ID 作为 key绝不使用索引。条件渲染 vs visibility结构差异大时用if/else切换需要保留状态时用visibility。避免复杂条件表达式build()中的条件逻辑应简洁明了复杂逻辑提取到计算属性。大数据量用 LazyForEach超过 100 条数据时优先考虑懒加载方案。三元运算符仅用于属性值不要试图在build()中用三元表达式替代if/else。五、参考文档条件渲染与循环渲染ForEach API 参考key 生成策略说明LazyForEach 文档