【共创季稿事节】面向 HarmonyOS 7.0：从康威生命游戏看鸿蒙渲染性能优化实战与前瞻

本文以一款基于细胞自动机（Cellular Automaton）打造的 HarmonyOS 7.0 应用「万物生长」为载体，深入拆解一次真实的 Canvas 渲染性能优化实战——全量重绘与差分重绘这两种渲染策略在同一场景下的真实耗时对比。文章包含完整可复现的 ArkTS 代码、量化测试数据与真机运行截图，并在此基础上展望这类渲染优化思路在鸿蒙渲染管线上进一步演进的空间。

一、引子：一个关于"重复劳动"的朴素问题

几乎所有涉及动态内容的 UI 渲染场景，都会面临同一个朴素却根本的问题：当画面上只有一小部分内容发生变化时，我们有没有必要把整块画布重新画一遍？

这个问题听起来显而易见——当然没必要。但在实际工程中，“全部重画"往往是最容易实现的第一版方案：逻辑简单、心智负担低、不用维护"上一帧状态”。于是很多应用的第一版渲染代码，几乎都长这样：

function renderFrame() {
  clearCanvas();          // 先清空整个画布
  drawEverything();        // 再把所有要显示的内容重新画一遍
}

这套写法在内容量小的时候毫无问题。但当画布变大、绘制对象变多，这种"无差别重画"的开销会随着规模线性增长，最终变成性能瓶颈。从"全量重绘"到"差分重绘"（只画变化的部分），是几乎所有高性能渲染系统都会经历的一次进化——无论是网页的虚拟 DOM diff、游戏引擎的脏矩形（dirty rectangle）技术，还是移动端的按需刷新机制，本质上都是同一个思想的不同实现。

要把这个抽象的优化思路讲清楚，我需要一个"看得见、摸得着"的实验场——于是我选择了计算机科学里最经典、最优雅的一个演示模型：康威生命游戏（Conway’s Game of Life）。围绕它，我做了一款完整的鸿蒙应用「万物生长」，并在应用内置了一个"性能实验室"，把这次渲染优化的对比过程做成了可以亲手验证的真实实验，而不只是一段孤立的代码片段。

先看一眼这个应用的整体样貌——下图是在 DevEco Studio 里，代码编辑区与模拟器预览同框的画面，右侧模拟器里正演化到第 5789 代、存活 748 个细胞：

可以看到，应用的工程结构（common/entryability/model/pages）和四个底部 Tab（培养皿、图鉴、实验室、关于）都清晰可见。这不是一个孤立的性能测试脚本，而是一个完整、可交互、可长期把玩的应用。下面，我们从"细胞自动机"这个载体讲起，一步步深入到渲染优化的核心。

二、为什么选细胞自动机做这个实验

选择细胞自动机作为性能实验的载体，不是随意的决定，而是因为它天然具备三个特质，恰好匹配"渲染优化对比"这个实验的需求：

其一，计算与渲染完全解耦。 细胞自动机的"下一代计算"是纯逻辑运算（数邻居、判断规则），和"把结果画到屏幕上"是两个独立步骤。这让我可以精确地只测量"渲染"这一部分的耗时，不被计算逻辑干扰——这对做性能对比实验至关重要。

其二，规模可控、变化量可控。 我可以精确控制网格是 60×40 还是 120×80（通过压力档位调整），也可以观察到"每一代到底有多少格子发生了状态变化"——这正是"全量重绘 vs 差分重绘"这个对比实验最需要的变量。

其三，视觉效果本身有说服力。 细胞自动机能演化出滑翔机、振荡器、乃至能自我复制的复杂结构，这种"简单规则孕育复杂之美"的观感，让整个应用不只是一个冷冰冰的测试工具，而是真正好玩、值得把玩的东西。这是我给这类"技术验证型"应用的一个基本要求：技术严谨性和趣味性并不矛盾，做到位的话可以兼得。

三、细胞自动机引擎：从规则到实现

3.1 用类型化数组存储网格状态

网格是整个引擎的核心数据结构。我没有用普通数组或二维数组，而是用了 Uint8Array：

export class LifeGrid {
  readonly cols: number;
  readonly rows: number;
  private cells: Uint8Array;
  private next: Uint8Array;
  rule: Rule = RULES[0];
  generation: number = 0;

  constructor(cols: number, rows: number) {
    this.cols = cols;
    this.rows = rows;
    this.cells = new Uint8Array(cols * rows);
    this.next = new Uint8Array(cols * rows);
  }
}

选择 Uint8Array 而非普通 Array<number>，是出于两个考虑：一是内存布局连续，CPU 缓存命中率更高，遍历访问速度明显优于对象数组；二是每个元素只需要 0~255 的范围（用来表示细胞的"年龄"），用一个字节存储刚好足够，不浪费空间。 这是我在做这类需要频繁大规模遍历的场景时，养成的一个习惯性优化——能用类型化数组的场景，就不用普通数组。

3.2 用"年龄"承载双重语义

网格里存的不是简单的 0/1（死/活），而是一个 0~255 的"年龄"值。这个设计有个巧妙之处：同一个数值，同时承载了"是否存活"和"存活了多久"两层语义，前者驱动逻辑判断，后者驱动渲染时的视觉呈现（越老的细胞颜色越亮）：

isAlive(x: number, y: number): boolean {
  return this.cells[this.idx(x, y)] > 0;   // > 0 即存活，语义1
}

age(x: number, y: number): number {
  return this.cells[this.idx(x, y)];        // 具体数值即年龄，语义2
}

渲染时，颜色的亮度随年龄增长而提升：

const gray = Math.min(255, 90 + age * 12);
this.ctx.fillStyle = `rgb(${Math.floor(gray * 0.25)},${gray},${Math.floor(gray * 0.7)})`;

存活越久的细胞越亮，这不只是视觉效果的加分项，也直观地传达了"生长"这个主题——你能一眼看出哪些区域是"老细胞聚居地"（稳定结构），哪些是"新生代刚刚诞生"的活跃前沿。

3.3 环形边界：让图案永不"撞墙"

细胞自动机的经典移动图案（比如滑翔机）会持续向某个方向平移。如果边界是"硬墙"，图案飞出画布就消失了，体验会很差。我用取模运算实现了环形边界（Torus）：

private idx(x: number, y: number): number {
  const wx = (x + this.cols) % this.cols;   // 超出右边界，从左边界重新计数
  const wy = (y + this.rows) % this.rows;
  return wy * this.cols + wx;
}

这样一来，滑翔机飞到画布右边缘，下一步就会从左边缘重新出现——图案可以无限地在画布上飞行，永不"撞墙消失"。这也是为什么应用里的图案能持续演化几千代而不无聊：它们真的会一直"活"下去。

3.4 逐格计算邻居数：性能敏感的核心循环

step() 方法是整个引擎里被调用频率最高、也最需要关注性能的部分——每一代都要遍历全部格子，为每个格子数出周围 8 个邻居里有多少个存活：

step(): number {
  const cols = this.cols;
  const rows = this.rows;
  let alive = 0;
  for (let y = 0; y < rows; y++) {
    const up = (y - 1 + rows) % rows;
    const down = (y + 1) % rows;
    for (let x = 0; x < cols; x++) {
      const left = (x - 1 + cols) % cols;
      const right = (x + 1) % cols;
      let n = 0;
      if (this.cells[up * cols + left] > 0) { n++; }
      if (this.cells[up * cols + x] > 0) { n++; }
      if (this.cells[up * cols + right] > 0) { n++; }
      if (this.cells[y * cols + left] > 0) { n++; }
      if (this.cells[y * cols + right] > 0) { n++; }
      if (this.cells[down * cols + left] > 0) { n++; }
      if (this.cells[down * cols + x] > 0) { n++; }
      if (this.cells[down * cols + right] > 0) { n++; }

      const i = y * cols + x;
      const curAge = this.cells[i];
      let nextAge = 0;
      if (curAge > 0) {
        if (this.rule.survive.indexOf(n) >= 0) {
          nextAge = curAge < 255 ? curAge + 1 : 255;
        }
      } else {
        if (this.rule.birth.indexOf(n) >= 0) {
          nextAge = 1;
        }
      }
      this.next[i] = nextAge;
      if (nextAge > 0) { alive++; }
    }
  }
  // 双缓冲交换：避免计算过程中读写同一份数据造成的"就地更新"错误
  const tmp = this.cells;
  this.cells = this.next;
  this.next = tmp;
  this.generation++;
  return alive;
}

这里有两个值得展开的细节：

其一，up/down/left/right 的取模运算提前到行/列循环外计算。 注意 up、down 是在外层 y 循环里算一次，而不是在内层 x 循环里对每个格子都重新算一次——这是一个经典的循环不变量外提（loop-invariant code motion）优化，避免了内层热循环里的重复取模运算。

其二，双缓冲（double buffering）交换。 计算下一代时，绝不能直接在 cells 数组上就地修改——因为计算格子 (x, y) 的邻居数时，可能已经用到了同一代里刚被修改过的相邻格子，这会导致状态污染。所以引擎维护了两份数组 cells 和 next，本代计算结果写入 next，算完后整体交换引用。这是所有细胞自动机、以及更广泛的"基于前一状态计算下一状态"场景（比如物理模拟、图像卷积）都会用到的标准手法。

3.5 规则可插拔：用 B/S 记号驱动多样性

细胞自动机的规则可以用经典的 B/S（Birth/Survive）记号描述——“B3/S23” 就是康威生命游戏的规则：死细胞周围恰好 3 个活邻居会诞生，活细胞周围有 2 或 3 个活邻居会存活。我把规则抽象成一个可插拔的数据结构：

export interface Rule {
  id: string;
  name: string;
  birth: number[];     // 死细胞周围活邻居数在此集合内 -> 诞生
  survive: number[];   // 活细胞周围活邻居数在此集合内 -> 存活
  desc: string;
}

export const RULES: Rule[] = [
  { id: 'conway', name: '经典生命', birth: [3], survive: [2, 3], desc: 'B3/S23 · 康威生命游戏经典规则' },
  { id: 'highlife', name: '繁盛之地', birth: [3, 6], survive: [2, 3], desc: 'B36/S23 · 更容易繁殖出复制器' },
  { id: 'daynight', name: '昼夜交替', birth: [3, 6, 7, 8], survive: [3, 4, 6, 7, 8], desc: 'B3678/S34678 · 对称的明暗交织' },
  { id: 'seeds', name: '种子爆发', birth: [2], survive: [], desc: 'B2/S · 无稳定形态，持续爆发式生长' }
];

step() 方法里对规则的应用，只是简单的 indexOf 查找是否命中集合——这意味着新增一套规则完全不需要改动任何计算逻辑，只需要往 RULES 数组里加一条数据。下图是"种子爆发"规则下的实际运行效果，可以看到这套规则没有稳定形态，画面持续处于爆发式生长状态：

顶部显示"第 5891 代 · 存活 750 个细胞"，说明这个规则下的种群数量在长期演化中保持着动态平衡——持续有新细胞诞生，也持续有细胞死亡，永不收敛到静止状态。这也是"种子爆发"这个名字的由来。

四、经典图案库：用坐标数据复现数学史上的名场面

细胞自动机的魅力不只在于规则本身，更在于几十年来数学爱好者们发现的一系列"经典图案"——它们有的会移动，有的会周期性闪烁，甚至有一种能持续不断"生产"另一种图案的传奇结构。我把 6 个最具代表性的图案坐标数据化：

export const PATTERNS: LifePattern[] = [
  { id: 'glider', name: '滑翔机', desc: '最经典的移动图案，斜向平移，永不停息', size: '3×3',
    points: [[1, 0], [2, 1], [0, 2], [1, 2], [2, 2]] },
  { id: 'lwss', name: '轻型飞船', desc: '比滑翔机更大的移动图案，速度较快', size: '5×4',
    points: [[1, 0], [4, 0], [0, 1], [0, 2], [4, 2], [0, 3], [1, 3], [2, 3], [3, 3]] },
  { id: 'pulsar', name: '脉冲星', desc: '周期性闪烁的振荡器，每 3 代完整循环一次', size: '13×13',
    points: [ /* 48 个坐标点，构成对称的雪花状结构 */ ] },
  { id: 'gun', name: '滑翔机枪', desc: '传奇图案：每 30 代自动发射一架滑翔机，永动装置', size: '36×9',
    points: [ /* 36 个坐标点 */ ] },
  { id: 'block', name: '静物方块', desc: '最简单的静止图案，永远保持不变', size: '2×2',
    points: [[0, 0], [1, 0], [0, 1], [1, 1]] },
  { id: 'toad', name: '蟾蜍', desc: '周期为 2 的振荡器，在两种形态间来回切换', size: '4×2',
    points: [[1, 0], [2, 0], [3, 0], [0, 1], [1, 1], [2, 1]] }
];

放置逻辑同样简洁——把一组相对坐标批量转换成"点亮"操作：

placePattern(cx: number, cy: number, points: number[][]): void {
  for (const p of points) {
    this.setAlive(cx + p[0], cy + p[1], true);
  }
}

下图是在培养皿页面点击"放置经典图案"后弹出的图案选择列表，可以看到轻型飞船、脉冲星、滑翔机枪、静物方块、蟾蜍的具体尺寸和描述一一列出：

用户选中一个图案后，只需点击画布任意位置，就能把这个经典结构"种"进当前的培养皿里，观察它与周围环境的互动——比如一架飞行中的滑翔机撞上静物方块会发生什么，这种"混沌实验"正是细胞自动机好玩的地方。

4.1 图鉴：让每个标本"活"在自己的独立世界里

除了在主培养皿里放置图案，我还专门做了一个「图鉴」页，让每个经典图案在一个独立的小画布里自主循环演化，像陈列在博物馆里的活体标本：

setup(): void {
  this.grid = new LifeGrid(this.cols, this.rows);
  this.grid.rule = RULES[0];
  const cx = Math.floor(this.cols / 2) - 3;
  const cy = Math.floor(this.rows / 2) - 3;
  this.grid.placePattern(cx, cy, this.pattern.points);
  this.timer = setInterval(() => {
    const alive = this.grid.step();
    this.draw();
    if (alive === 0) {
      // 图案自然消亡后，自动重置重放，标本"永不真正死亡"
      this.grid.clear();
      this.grid.placePattern(cx, cy, this.pattern.points);
    }
  }, 260);
}

这里有个小心思：当一个图案最终演化到全部死亡（比如某些图案在小画布的环形边界约束下最终会湮灭），我会自动清空重放，让标本看起来"永不真正消亡"。这是一个纯粹为了体验设计的小细节，但我认为恰恰是这种细节，把一个技术 Demo 和一个"值得反复打开来看"的产品区分开来。

下图是图鉴页面的整体效果，六个标本各自在独立画布里演化，脉冲星呈现出对称的雪花状闪烁图案：

五、性能实验室：把"渲染优化"做成一个可复现的实验

前面四章讲的都是"计算"层面的实现——细胞自动机引擎本身的效率已经足够高（Uint8Array + 双缓冲 + 循环优化）。但整个应用真正的技术核心，在于渲染这一层。这一章，我要完整拆解"性能实验室"这个模块，把"全量重绘 vs 差分重绘"这个渲染优化命题，变成一次可以亲手复现、有真实数据支撑的实验。

5.1 两种策略的本质区别

先明确定义这两种策略：

全量重绘（Full Redraw）：每一帧都做两件事——先把整块画布清空，再遍历所有存活细胞，把它们逐一画上去。

private async benchFull(cols: number, rows: number, genCount: number): Promise<BenchResult> {
  const grid = new LifeGrid(cols, rows);
  grid.randomize(0.25);
  let totalMs = 0;
  for (let g = 0; g < genCount; g++) {
    grid.step();
    const t0 = Date.now();
    this.ctx.fillStyle = C.canvasBg;
    this.ctx.fillRect(0, 0, w, h);              // 清空整块画布
    grid.forEachAlive((x, y, age) => {           // 遍历全部存活细胞
      this.ctx.fillStyle = colorOf(age);
      this.ctx.fillRect(x * cell, y * cell, cell - 1, cell - 1);
    });
    totalMs += Date.now() - t0;
  }
  return { label: '全量重绘', avgFrameMs: totalMs / genCount, /* ... */ };
}

这里有个关键的耗时采样细节：t0 = Date.now() 放在 grid.step() 之后，也就是说只测量渲染部分的耗时，不包含逻辑计算耗时——这是保证实验对比公平性的关键，因为两种策略用的是完全相同的计算引擎，差异只应该体现在渲染环节。

差分重绘（Diff Redraw）：不清空整块画布，只处理"本帧相对上一帧发生变化"的格子——新生的格子画上去，死亡的格子擦掉，其余不变的格子完全不动它：

private async benchDiff(cols: number, rows: number, genCount: number): Promise<BenchResult> {
  const grid = new LifeGrid(cols, rows);
  grid.randomize(0.25);
  // 先画一次初始状态作为基底
  let prevAlive: Set<number> = new Set<number>();
  grid.forEachAlive((x, y, age) => {
    const key = y * cols + x;
    prevAlive.add(key);
    this.paintCell(x, y, age, cell);
  });

  let totalMs = 0;
  for (let g = 0; g < genCount; g++) {
    grid.step();
    const curAlive: Set<number> = new Set<number>();
    const t0 = Date.now();
    grid.forEachAlive((x, y, age) => {
      const key = y * cols + x;
      curAlive.add(key);
      if (!prevAlive.has(key)) {
        this.paintCell(x, y, age, cell);   // 只画"新生"的格子
      }
    });
    prevAlive.forEach((key: number) => {
      if (!curAlive.has(key)) {
        const x = key % cols;
        const y = Math.floor(key / cols);
        this.ctx.fillStyle = C.canvasBg;
        this.ctx.fillRect(x * cell, y * cell, cell, cell);   // 只擦"死亡"的格子
      }
    });
    prevAlive = curAlive;
    totalMs += Date.now() - t0;
  }
  return { label: '差分重绘', avgFrameMs: totalMs / genCount, /* ... */ };
}

这段代码的核心是用两个 Set<number>（prevAlive 记录上一帧存活格子、curAlive 记录当前帧存活格子）做帧间差分：

• 存在于 curAlive 但不存在于 prevAlive 的格子 —— 新生，需要绘制
• 存在于 prevAlive 但不存在于 curAlive 的格子 —— 死亡，需要清除
• 同时存在于两者的格子 —— 不变，什么都不做，直接跳过

这正是差分算法的精髓：把"渲染谁"这个问题，从"全部存活的细胞"缩小为"发生变化的细胞"。 当画面趋于稳定（比如出现大量静态振荡器结构）时，变化量会远小于总存活量，差分重绘的优势就会显现得越明显。

5.2 用 Set 做集合比对：为什么选它而不是别的结构

这里选用 Set<number> 而非数组来记录存活格子，是有意为之的设计决策。判断"某个格子是否在上一帧存活"是一个高频的查找操作（prevAlive.has(key)），Set 的查找是 O(1) 均摊复杂度，而如果用数组做同样的查找需要 O(n) 的线性扫描或者额外排序。在写这类需要频繁做集合运算（存在性判断、差集计算）的逻辑时，选对底层数据结构，往往比后续任何"微调"都更能决定性能上限。

5.3 为了保证测试不冻结 UI 线程的细节

无论是全量重绘还是差分重绘，测试都要跑满 200 代，如果不做任何让步，这个同步循环会长时间占用 JS 线程，导致界面卡死、甚至被系统判定为无响应。所以每跑 20 代，我会主动让出一次执行权：

if (g % 20 === 0) { await this.yieldFrame(); }

private yieldFrame(): Promise<void> {
  return new Promise((resolve: () => void) => { setTimeout(resolve, 0); });
}

setTimeout(resolve, 0) 是一个经典的"让出主线程"技巧——它把后续逻辑重新排入事件队列末尾，让浏览器/运行时有机会处理其他挂起的任务（比如 UI 重绘、用户交互响应），避免长时间同步计算造成的界面冻结。这是任何要在主线程做批量计算的场景都应该考虑的细节——性能优化不能以牺牲界面响应性为代价。

5.4 真实测试数据：加速比会说话

下图是压力档位调到 4×（更大网格规模）时的测试结果——画布上密布着细胞图案，代表这是一个"大规模、高负载"场景：

而在 1× 压力档位（较小网格规模）下，跑完对比测试后，应用给出了具体的量化结果——差分重绘平均每帧耗时 0.20 ms，折算约 4878 FPS，结论卡片直接给出"差分重绘比全量重绘快 2.1 倍"：

而在另一次测试中（不同压力档位），差分重绘的表现是平均每帧 1.15 ms，约 873 FPS，加速比约为 1.2 倍。这两组数据放在一起对比，能看出一个很有意思的规律：网格规模越小、画面越"安静"（变化量占比越低），差分重绘的相对优势反而可能被更小的绝对耗时基数"稀释"，测出来的加速比会有波动；而随着规模增大、变化量的绝对值增长，差分重绘"只处理变化部分"的优势会更稳定地体现出来。 这提醒我们，性能优化的收益不是一个恒定的倍数，而是和场景的具体特征（规模、变化率、变化的空间分布）密切相关的——做性能优化，永远要在真实的、贴近生产环境的负载下测试，不能只信一次孤立的跑分。

5.5 加速比的计算与展示

结果展示区会自动算出两次测试之间的加速比：

speedupText(): string {
  if (this.results.length < 2) { return ''; }
  const full = this.results[0].avgFrameMs;
  const diff = this.results[1].avgFrameMs;
  if (diff <= 0) { return ''; }
  const ratio = full / diff;
  return '差分重绘比全量重绘快 ' + ratio.toFixed(1) + ' 倍';
}

把"耗时"转换成"倍数"这个更直觉的表达方式，是数据可视化里一个简单却有效的技巧——用户理解"快 2.1 倍"远比理解"从 0.42ms 降到 0.20ms"更直接，即便两者传达的是同一个事实。

六、渲染优化的一般性方法论：从这个实验能提炼出什么

做完这个实验，我想跳出"细胞自动机"这个具体场景，提炼出一套更普适的渲染优化方法论——这套方法论几乎可以套用到任何"周期性刷新、局部变化"的 UI 场景（列表滚动、数据可视化图表、实时监控面板、游戏 HUD 等）：

第一步：明确"状态"与"渲染"的边界。 我在这个实验里能精确对比两种策略，前提是"计算下一代"和"渲染当前状态"是完全独立的两个函数。如果这两者耦合在一起，你连"渲染到底花了多少时间"都测不准，更别提优化。

第二步：找到"变化的最小单元"。 在这个场景里最小单元是"一个格子"；在列表场景里可能是"一个列表项"；在图表场景里可能是"一条曲线的一个数据点"。找到这个最小单元，才能定义什么叫"差分"。

第三步：维护"上一帧状态"用于比对。 差分重绘天然要求你保留一份历史状态（这里是 prevAlive 这个 Set）。这是有内存成本的——差分重绘不是没有代价的免费午餐，它是用"额外的状态维护成本"换取"渲染计算量的降低"，在内存极度紧张的场景，这个权衡需要重新评估。

第四步：用真实数据验证收益，而不是想当然。 我在这个实验里特意保留了"从耗时数字到加速比"的完整链路，就是想强调——渲染优化的收益必须被测量，不能靠直觉判断"肯定更快"就了事。工程实践中，我见过不少"优化"因为额外维护状态的开销，反而在小规模场景下比"傻乎乎的全量重绘"更慢，这正是本实验里 1× 档位加速比不如更高档位明显的原因所在。

七、深挖：HarmonyOS 渲染管线还能往哪里走

这一章我想跳出"这次实验做了什么"，往下深挖一层——基于前面这次实战暴露出的具体问题（手写比对逻辑的开发成本、CPU 侧像素计算的性能天花板、单设备算力上限对大规模场景的限制），讨论鸿蒙渲染管线在这几个方向上还有哪些可以继续挖掘的空间。

7.1 从"应用层手写差分"到"框架层自动差分"

这次实验里，无论是判断哪些格子"新生"、哪些格子"死亡"，全部依赖我在业务代码里手写的 Set 比对逻辑。这本质上是在应用层重新发明了一套简化版的"虚拟 DOM diff"——前端框架早在多年前就把这套机制下沉到了框架内部，开发者只需要声明"UI 应该长什么样"，具体"哪里变了、该重绘哪里"完全交给框架托管。

ArkUI 的声明式渲染模型（@State/@Prop 驱动的响应式更新）在组件树这个层级上，已经具备类似的按需更新能力——状态变化时，框架只会重新渲染受影响的组件子树，而不是整个页面。但在 Canvas 这类"自绘"场景里，一旦进入 CanvasRenderingContext2D 的世界，差分优化就完全落回了开发者手里，框架无法介入。

如果渲染管线能在 Canvas / 自绘组件这条链路上，提供某种"声明脏区域、框架自动合并重绘"的能力（类似游戏引擎里的脏矩形自动管理机制），会是对这类场景开发体验的显著提升——从"手动优化"进化到"框架托管优化"，是绝大多数渲染框架成熟过程中的必经之路，ArkUI 在自绘领域走到这一步，是值得期待的方向。

7.2 硬件合成能力的进一步下沉

本文的差分重绘实验，完全是在 CPU 侧完成的像素级填充运算——每一次 fillRect 调用，最终都要经过 CPU 计算颜色值、写入位图缓冲区。这是当前 Canvas 2D API 的能力边界所在。

如果把视角放宽，现代渲染管线的一个核心趋势是尽可能把重复的、规则的绘制工作下沉到 GPU 侧的合成层，让 CPU 只负责"决定画什么"，而不亲自参与"怎么画"的每一个像素计算。对于本文这种"大量结构相同、只是位置/颜色不同的小色块批量绘制"的场景（本质上是大量精灵/图元的批量渲染），如果图形能力能提供更薄的硬件加速通路——比如把每个细胞抽象成一个轻量图元、交由 GPU 批量合成而非逐个 CPU 绘制——性能天花板会有实质性的提升，尤其是在网格规模进一步放大（比如从本文的 1×~4× 档位扩展到 16× 甚至更大）时，这种差异会更加明显。这类硬件加速能力的持续下沉，是值得关注的第二个方向。

7.3 跨设备算力协同：渲染任务的分摊可能性

鸿蒙最独特的能力标签是"一次开发、多端部署"和分布式协同，这为渲染优化打开了一个其他平台不太具备的思路——渲染负载能不能跨设备分摊？

设想这样一个场景：像本文这种计算密集的细胞自动机模拟，如果放在算力较弱的穿戴设备上运行，会明显吃力；但如果能让算力更强的设备（比如鸿蒙 PC）承担"下一代状态计算"这部分工作，只把最终的、轻量化的渲染指令或差分结果同步给手表显示，就能在不牺牲体验的前提下，把重计算下放到更合适的设备上完成。这本质上是把"分布式能力"和"渲染性能优化"这两个原本分开讨论的话题做了一次交叉——计算跑在哪、渲染跑在哪，未来或许不必被"单一设备"这个假设锁死。这种跨设备的算力协同渲染，是鸿蒙在多端生态持续成熟后，最有机会讲出差异化故事的方向。

7.4 小结：深挖建立在实战之上，才不会流于空谈

以上三个方向——框架层自动差分、硬件合成下沉、跨设备算力协同——都不是凭空提出的猜测，而是直接对应着本文实战里暴露出的三个具体瓶颈：手写比对逻辑的开发成本、CPU 侧像素计算的性能天花板、单设备算力上限对大规模场景的限制。这也是我想强调的方法论：做技术深挖最扎实的方式，不是去畅想一堆"觉得会有的炫酷功能"，而是先把手头这个具体问题的能力边界摸清楚，往哪走自然就会从"这个边界在哪里最值得被打破"这个问题里生长出来。

八、关于页与工程闭环：一个完整应用应有的收尾

最后，一个值得称道的应用不应该只有炫技的核心功能，也需要一个清晰交代"这是什么、怎么做的"的收尾页面。「关于」页用简洁的语言解释了细胞自动机的原理，也如实列出了技术实现要点：

页面上写明了这几点技术实现：网格用 Uint8Array 类型化数组存储、采用环形边界、支持 4 套规则集实时切换、以及性能实验室对比两种渲染策略——这几乎是本文所有技术内容的一份精炼摘要。我始终认为，一个技术向的应用，应该在产品里就把"我做了什么、为什么这么做"讲清楚，而不是把所有技术细节都藏在无人可见的源码里。 这不仅是对用户的尊重，也是对自己这段开发过程的一份诚实记录。

九、总结：性能优化的本质是对"必要工作量"的重新定义

回顾整个实验，从细胞自动机引擎的类型化数组与双缓冲，到性能实验室里全量重绘与差分重绘的量化对比，贯穿始终的其实是同一个朴素的问题：我们真的需要做这么多工作吗？

全量重绘之所以慢，不是因为"画一个色块"这个操作本身有多昂贵，而是因为它无差别地重复了大量本可以省略的工作——那些从上一帧到这一帧根本没有变化的格子，被一遍又一遍地清空又重画。差分重绘的核心贡献，不是发明了什么更快的绘制算法，而是重新定义了"必要工作量"的边界——把"渲染整个画布"缩小为"渲染变化的部分"。

这个洞察的价值，远超"细胞自动机"这一个具体场景。任何一个持续刷新的界面，本质上都值得问一句：这一帧，到底哪些东西真的变了？ 找到这个问题的答案，往往就是性能优化的起点。

回到本文的初衷——在 HarmonyOS 7.0 上做这次渲染优化实战。这类"重新定义必要工作量"的优化思路，大概率会持续沿着框架托管、硬件下沉、跨设备协同这三条线继续演进，从今天开发者需要手写的应用层技巧，逐步变成框架与系统能力原生具备的默认行为。但无论鸿蒙渲染管线未来进化成什么样子，"只做真正必要的工作"这个朴素的工程直觉，都会是理解和驾驭任何新能力的根基。

希望这次实战记录，能给同样在 HarmonyOS 7.0 上做动态渲染与性能优化的开发者一些具体的参考。如果你也在做类似的渲染优化实验，欢迎交流讨论。