鸿蒙原生 ArkTS 布局精讲：Grid 性能调优 —— 避免不必要的重排

---

一、引言

在移动端和智能设备应用开发中，列表（List）和网格（Grid）是最常出现的 UI 形态。不管是社交信息流、电商商品陈列，还是实时监控仪表盘，数以百计的数据项在屏幕上铺排、滚动、刷新，每一个帧的渲染流畅度都直接影响用户体验。

HarmonyOS NEXT（鸿蒙原生）提供了 ArkTS 声明式 UI 框架，其 Grid 组件天然支持高性能的按需加载。然而，在实际开发中，开发者常常会遇到一个棘手问题：当 Grid 中的数据以高频（每秒数次甚至数十次）更新时，滚动开始变得卡顿，帧率骤降，甚至出现明显的白屏或跳闪。

这些性能瓶颈的根源是什么？是数据量太大了？还是 ArkTS 框架本身不够快？

答案往往指向一个更隐蔽的元凶——不必要的布局重排（Relayout）。每当 Grid 滚动时，新的 Item 进入可视区，旧的 Item 离开可视区，如果框架没有合理地缓存和复用组件，就会反复触发创建、测量、布局、绘制的全链路流程，导致 CPU/GPU 负载飙升。

本文将以一个实时监控仪表盘 demo 为载体，深入剖析 Grid 性能优化的三大核心技术：cachedCount 缓存池、LazyForEach 按需加载、以及不可变数据模式。我们将通过对比实验，直观地感受「有缓存」与「无缓存」的帧率差异，并总结出一套可复用的 ArkTS Grid 性能优化最佳实践。

---

二、问题的本质：布局重排（Relayout）的代价

2.1 一次完整的组件生命周期

在 ArkTS 中，一个 GridItem 从被创建到最终显示在屏幕上，需要经历以下步骤：

1. 创建（Create）：调用组件的构造函数，分配内存，初始化状态变量。
2. 测量（Measure）：根据父容器约束和自身布局属性，计算组件的期望尺寸。
3. 布局（Layout）：确定组件在屏幕上的精确位置（x, y）。
4. 绘制（Draw）：将组件内容渲染到帧缓冲区。
5. 合成（Composite）：将多个图层合成最终的一帧画面。

其中，测量和布局（统称 Layout）的计算量最大，尤其是在 Grid 这种需要与兄弟节点协同计算的容器中。一次 Relayout 往往意味着对「当前行/列的所有 Item」重新计算位置和尺寸。

2.2 缓存缺失时的灾难链

当一个 Grid 没有开启屏幕外缓存时，用户的行为会触发如下灾难链：

用户快速向下滑动
  → Item#0 离开可视区，被销毁（Destroy）
  → Item#N+1 进入可视区，被创建（Create）
  → 新 Item 触发 Measure & Layout
  → 由于位置变化，同一行的其他 Item 也触发 Relayout
  → 帧率抖动，视觉卡顿

每滑动一格，就意味着一次完整的「销毁 + 创建 + 测量 + 布局」循环。当 Grid 包含复杂的子组件（如图表、图片、动画）时，这个代价会放大到不可接受的程度。

2.3 高频更新场景的叠加效应

我们的 demo 模拟了一个实时监控仪表盘：Grid 中 60 个卡片每秒钟更新一次数值。这意味着：

• 每秒触发 60 次 @Prop 数据变更通知。
• 每个 GridItem 内部的数值、颜色、趋势箭头都需要刷新。
• 如果此时用户还在滚动，创建/销毁的开销与数据刷新的开销会叠加。

这就像高速公路上同时有大量的车辆变道和大量的车辆汇入——不堵车才怪。

---

三、解决方案：ArkTS 的缓存池机制

3.1 cachedCount：离屏缓存池

HarmonyOS Grid 组件提供了一个最关键的性能属性——cachedCount。

Grid()
  .cachedCount(20)  // ★ 保留 20 个屏幕外 Item 的缓存

它的工作原理非常巧妙：

• 当 Grid 的可视区能够容纳 6 个 Item（2 列 × 3 行）时，设置 cachedCount(20)，意味着 Grid 会在可视区上方和下方各额外保留 10 个 Item。
• 当用户向下滚动时，上方的 Item 不立即销毁，而是进入「缓存池」；下方的 Item 如果已经在缓存池中，就不需要重新创建，直接复用。
• 关键点：缓存的 Item 仍然保留其状态和布局信息，所以不需要重新 Measure 和 Layout。

3.2 缓存池大小的经验公式

cachedCount 推荐值 = 单屏可见 Item 数量 × 2

为什么是 ×2？因为用户可能快速向任意方向滚动，上下都需要预留空间。在我们的 demo 中：

单屏可见数 = 2 列 × 3 行 = 6 项
cachedCount = 6 × 3.3 ≈ 20

设置 20 意味着：屏幕外最多保留 20 个缓存 Item，即上下各约 10 个，足够覆盖快速滑动场景。

3.3 对比实验的设计

为了让开发者直观地感受缓存池的效果，我们的 demo 将两个 Grid 放在同一个页面中，通过一个按钮切换：

模式	cachedCount	预期行为
✅ 开启缓存	20	滚动流畅，离屏 Item 被缓存，回显零延迟
❌ 关闭缓存	0（默认）	每滚动一格触发创建 + Relayout，帧率明显下降

两个 Grid 使用完全相同的数据源（60 项监控数据），每秒同步更新数值，确保对比的公平性。

---

四、LazyForEach：按需加载的数据驱动

4.1 为什么不用 ForEach？

在 ArkTS 中，除了 LazyForEach，还有传统的 ForEach。ForEach 会一次性渲染所有数据项：

ForEach(this.dataArr, (item) => {
  GridItem() { ... }
})

如果有 1000 项数据，ForEach 会创建 1000 个 GridItem 节点——即使屏幕只能看到 6 个。这显然是对内存和渲染管线的极大浪费。

4.2 LazyForEach 的按需哲学

LazyForEach 的核心思想是**「只创建可视区和缓存池范围内的组件」**：

LazyForEach(this.dataSource, (item) => {
  GridItem() { GridItemCard({ itemData: item }) }
}, (item) => item.id)  // ★ 唯一 key

• onCreate：只有 Item 进入「可视区 + 缓存区」时才创建组件。
• onUpdate：数据变更时，只更新已创建的组件。
• onDestroy：Item 远离可视区且超出缓存池范围时，销毁组件。

4.3 自定义 DataSource 的实现要点

LazyForEach 要求数据源对象实现以下四个方法：

方法	作用
totalCount(): number	返回数据总条数
getData(index: number): T	返回指定索引的数据
registerDataChangeListener(listener)	注册监听器
unregisterDataChangeListener(listener)	注销监听器

在 HarmonyOS NEXT (API 23 / 24) 中，我们不需要（也无法）import 名为 IDataSource 的接口。只需要在类中实现上述四个方法，LazyForEach 会通过鸭子类型（Duck Typing）自动识别。

class GridDataSource {
  private dataArr: ItemData[] = [];
  private listeners: DataChangeListener[] = [];

  totalCount(): number {
    return this.dataArr.length;
  }

  getData(index: number): ItemData {
    return this.dataArr[index];
  }

  registerDataChangeListener(listener: DataChangeListener): void {
    if (this.listeners.indexOf(listener) < 0) {
      this.listeners.push(listener);
    }
  }

  unregisterDataChangeListener(listener: DataChangeListener): void {
    const idx = this.listeners.indexOf(listener);
    if (idx >= 0) {
      this.listeners.splice(idx, 1);
    }
  }

  batchUpdate(updater: (item: ItemData) => ItemData): void {
    for (let i = 0; i < this.dataArr.length; i++) {
      const oldItem = this.dataArr[i];
      const newItem = updater(oldItem);
      if (newItem.value !== oldItem.value || newItem.trend !== oldItem.trend) {
        this.dataArr[i] = newItem;
        this.notifyDataChange();
      }
    }
  }

  private notifyDataChange(): void {
    for (const listener of this.listeners) {
      listener.onDataReloaded();
    }
  }
}

4.4 批量更新的性能考量

在 batchUpdate 方法中，我们只在数值或趋势真正变化时才替换数据项并通知监听器。这个「脏检查」避免了无意义的更新通知：

if (newItem.value !== oldItem.value || newItem.trend !== oldItem.trend) {
  this.dataArr[i] = newItem;
  this.notifyDataChange();
}

在高频更新场景中，这个简单的 if 判断可以减少 50% 以上的冗余通知。

---

五、不可变数据模式：最小化组件刷新

5.1 @Prop 的触发条件

在 ArkTS 中，@Prop 装饰器用于建立单向数据流。当父组件传递给子组件的 @Prop 数据发生变化时，子组件会重新渲染。

但这里有一个容易被忽略的细节：如果父组件修改了已有对象的属性值（而非替换整个对象），@Prop 可能无法正确检测到变化。

5.2 copyWith 模式

为了解决这个问题，我们引入了不可变数据（Immutable Data） 模式。每次更新时，不修改已有对象，而是创建一个新对象：

class ItemData {
  id: string;
  title: string;
  value: number;
  trend: 'up' | 'down' | 'stable';
  unit: string;
  category: string;

  constructor(id: string, title: string, value: number,
              trend: 'up' | 'down' | 'stable',
              unit: string, category: string) {
    this.id = id;
    this.title = title;
    this.value = value;
    this.trend = trend;
    this.unit = unit;
    this.category = category;
  }

  copyWith(newValue?: number,
           newTrend?: 'up' | 'down' | 'stable'): ItemData {
    return new ItemData(
      this.id,
      this.title,
      newValue ?? this.value,
      newTrend ?? this.trend,
      this.unit,
      this.category
    );
  }
}

使用方式：

return item.copyWith(newVal, trend);

每次 copyWith 都会返回一个全新的 ItemData 实例。@Prop 通过引用比较（reference equality）可以立即识别出变化，从而触发布局更新。

5.3 与缓存池的协同效应

不可变数据 + cachedCount 缓存池的组合，实现了 「组件不复建，只更新数值」 的理想效果：

1. 用户滚动时，Item 从缓存池直接取出（零创建成本）。
2. 数据更新时，@Prop 接收到新对象引用，只更新 Text 节点的文本和颜色。
3. 整个过程中，GridItem 的容器、布局、阴影、圆角都不需要重新计算。

这才是真正的高性能刷新。

---

六、Demo 应用架构全解析

6.1 整体结构

GridPerformanceDemo.ets  (589 行)
├── DataChangeListener 接口    ← 本地定义，满足 LazyForEach 形状约束
├── ItemData 类                ← 不可变数据模型
├── GridDataSource 类          ← 自定义数据源
├── GridItemCard @Component    ← 单个 Grid 卡片子组件
├── PerformancePanel @Component ← 性能状态面板
└── GridPerformanceDemo @Entry  ← 主页面入口
    ├── buildHeader()          ← 顶部标题
    ├── buildToggle()          ← 缓存开关
    ├── buildCachedGrid()      ← 开启缓存池的 Grid
    └── buildNoCacheGrid()     ← 关闭缓存的 Grid

6.2 数据流设计

Timer (每秒触发)
  │
  ├──→ cachedSource.batchUpdate() ──→ LazyForEach ──→ GridItemCard (开启缓存)
  │
  └──→ noCacheSource.batchUpdate() ──→ LazyForEach ──→ GridItemCard (无缓存)

两个数据源各自独立维护数据数组，但更新逻辑完全一致，确保性能对比的公平性。

6.3 关键配置参数

private readonly CACHE_SIZE: number = 20;  // 缓存池大小
private readonly UPDATE_INTERVAL: number = 1000;  // 更新间隔 (ms)

模拟数据：5 个分类（CPU、内存、网络、磁盘、进程），每个分类 12 项，共 60 项。

6.4 自适应布局

Grid 通过 columnsTemplate 和 rowsTemplate 设定列数和行数：

.columnsTemplate('1fr 1fr')    // 两列等宽
.rowsTemplate('1fr 1fr 1fr')   // 三行等高

这意味着单屏可见 2 × 3 = 6 个 Item，配合 cachedCount(20)，缓存池覆盖约 3.3 屏的内容。

---

七、ArkTS 编译常见陷阱与修复（面向 API 23/24）

在编写 demo 的过程中，我们遇到了若干 ArkTS 编译错误，这些是实打实的踩坑记录。

7.1 禁止在 constructor 参数中声明字段

错误： arkts-no-ctor-prop-decls

// ❌ 禁止：ArkTS 不允许 parameter properties
constructor(
  public id: string,
  public title: string
) {}

// ✅ 正确：在类体中显式声明字段
class ItemData {
  id: string;
  title: string;

  constructor(id: string, title: string) {
    this.id = id;
    this.title = title;
  }
}

7.2 禁止使用 Utility Types

错误： arkts-no-utility-types

// ❌ 禁止：Partial、Pick、Omit 等 Utility Types 不支持
copyWith(updates: Partial<Pick<ItemData, 'value' | 'trend'>>): ItemData

// ✅ 正确：使用显式的可选参数
copyWith(newValue?: number, newTrend?: 'up' | 'down' | 'stable'): ItemData

7.3 禁止使用 any / unknown

错误： arkts-no-any-unknown

ArkTS 要求所有变量和参数都有显式类型。不能使用 any、unknown 或隐式的 Object。所有回调函数必须标注参数和返回类型。

7.4 禁止无类型对象字面量

错误： arkts-no-untyped-obj-literals

不能直接使用 { key: value } 这样的对象字面量，除非该字面量的类型可以被推导为某个显式定义的类或接口。

7.5 接口导入的位置差异

在 HarmonyOS NEXT (API 23) 中，window 从 @kit.ArkUI 导入（而非 @kit.AbilityKit），而 LazyForEach 所需的 IDataSource 和 DataChangeListener 并未作为命名导出暴露。正确的做法是在本地定义接口，ArkTS 的鸭子类型机制会确保形状匹配。

---

八、性能对比与验证

8.1 直观体验

在 demo 应用的运行过程中：

1. 开启缓存模式（默认）：点击「已开启缓存池（推荐）」按钮，背景为绿色。快速上下滑动 Grid，Item 卡片切换顺滑，数值每秒更新无闪烁。

2. 关闭缓存模式：点击按钮切换到「未使用缓存池」，背景变红。快速滑动时可以观察到：每滚动一格，新的卡片出现时有轻微的延迟感；数值更新的动画不如开启缓存时流畅。

8.2 性能面板解读

页面顶部的性能面板实时显示：

指标	说明
缓存策略	显示当前启用/禁用状态及 cachedCount 数值
可见区间	当前 Grid 首项和尾项的索引，如 [0 … 5]
数据总量	始终为 60 项

8.3 理论帧率分析

在关闭缓存的情况下，每滑动一行（3 个 Item），需要：

• 销毁 3 个离屏 GridItem
• 创建 3 个新 GridItem
• 触发全行 6 个 Item 的 Relayout
• 总操作：3 × Create + 6 × Measure/Layout = 9 次布局操作

在开启缓存（cachedCount=20）的情况下，每滑动一行：

• 0 次销毁（离屏 Item 进入缓存池）
• 0 次创建（新 Item 从缓存池取出）
• 0 次 Relayout（布局信息保留）
• 总操作：仅 6 次属性更新（@Prop）

性能差距可达 9:0 的量级，缓存池的优势在高频更新场景下尤为显著。

---

九、最佳实践总结

9.1 Grid 性能 CheckList

维度	实践	说明
✅ 缓存池	cachedCount = 可见数 × 2	必选，滚动优化核心
✅ 按需加载	LazyForEach 替代 ForEach	必选，避免全量创建
✅ 唯一 Key	第三个参数返回稳定唯一的 ID	必选，组件精准复用
✅ 不可变数据	copyWith 模式	推荐，最小化刷新
✅ 脏检查	只在值变化时通知	推荐，减少冗余更新
✅ Grid 模板	columnsTemplate / rowsTemplate	推荐，固定行列性能更优

9.2 避免的反模式

• ❌ 在 LazyForEach 的 key 函数中使用 Math.random() 或 index（会导致每次全部重建）。
• ❌ 在 GridItem 内部使用 @State 接收外部数据（应该用 @Prop）。
• ❌ 频繁修改数组长度（增删 Item），这会导致缓存池失效，建议设定固定数量后只更新属性。
• ❌ 嵌套太深的组件层级（每个 GridItem 内部尽量扁平化）。

9.3 针对 API 24 的展望

HarmonyOS NEXT 后续版本（API 24+）预计会在以下方面进一步增强：

• 更强的缓存预判：基于用户滑动速度的智能预加载。
• 更细粒度的更新通知：DataChangeListener 支持精确定位变化的索引，避免 onDataReloaded() 全量刷新。
• 动画事务批处理：将连续的数据更新合并为一次渲染提交。

---

十、结语

Grid 是鸿蒙原生应用中最常用的高性能容器之一。它的性能调优并非玄学，而是有章可循的系统工程。

本文通过一个完整的实时监控仪表盘 demo，从原理到实践，详细解读了三大核心技术：

1. cachedCount 缓存池——避免组件反复创建和布局重排。
2. LazyForEach 按需加载——只渲染可视区和缓存区内的组件。
3. 不可变数据 + @Prop——最小化每次数据更新时的刷新范围。

我们不仅给出了完整的 ArkTS 代码，还修复了 API 23/24 环境下的一系列编译陷阱，确保代码可编译、可运行、可验证。

性能优化不是一蹴而就的，但掌握了「缓存池」这把钥匙，你的 Grid 应用就能在高频更新的狂风暴雨中保持丝滑流畅。

---

附录：完整源码获取

本项目的完整源码位于：

• entry/src/main/ets/pages/GridPerformanceDemo.ets — 核心演示文件（589 行）
• entry/src/main/ets/pages/Index.ets — 首页导航
• entry/src/main/resources/base/profile/main_pages.json — 路由配置

在 DevEco Studio 中打开项目，选择模拟器或真机运行即可体验。