条件渲染与 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.viewMode===ViewMode.CHART){ChartSummary({data:this.statisticsData})}elseif(this.viewMode===ViewMode.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 属性

选择建议：如果切换频率极高（如 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 值不稳定的后果：

1. UI 错乱：框架复用错误的组件实例，导致列表项显示与实际数据不匹配。
2. 性能下降：框架无法准确判断新增/删除项，导致全量重建。
3. 动画异常：列表项增删动画可能错误地应用到其他项上。

2.4 ForEach 的 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.billType===BillType.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，保证列表更新时的性能。

四、最佳实践总结

1. 始终提供稳定的 key：使用数据库 ID 作为 key，绝不使用索引。
2. 条件渲染 vs visibility：结构差异大时用if/else，切换需要保留状态时用visibility。
3. 避免复杂条件表达式：build()中的条件逻辑应简洁明了，复杂逻辑提取到计算属性。
4. 大数据量用 LazyForEach：超过 100 条数据时，优先考虑懒加载方案。
5. 三元运算符仅用于属性值：不要试图在build()中用三元表达式替代if/else。

五、参考文档

• 条件渲染与循环渲染
• ForEach API 参考
• key 生成策略说明
• LazyForEach 文档