HarmonyOS掌上记账APP开发实践第29篇：条件渲染与 ForEach — 动态 UI 的构建策略

春卷同学

71人浏览 · 2026-07-16 23:40:45

春卷同学 · 2026-07-16 23:40:45 发布

条件渲染与 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 })
} else if (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 属性

对比维度	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 作为 key
ForEach(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 更新流程

当提供稳定的 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')
}