子玥酱 （掘金 / 知乎 / CSDN / 简书 同名）

大家好，我是 子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出

我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

很多开发者刚开始做 HarmonyOS 游戏优化时，第一反应往往是：

CPU 不够了？

于是开始：

减少循环
优化算法
减少对象创建

结果发现：

CPU 占用只有 20%
FPS 却只有 35

或者另一种情况：

GPU 占用 100%
CPU 只有 10%

于是大家开始迷惑：

到底是谁拖慢了游戏？CPU 还是 GPU？

实际上，大部分性能问题，不是 CPU 慢，也不是 GPU 慢，而是：

不知道瓶颈在哪里。

真正的性能优化第一步，从来不是优化代码，而是找到瓶颈。

一、游戏为什么会卡？

先看一帧（Frame）是怎么生成出来的。当用户点击屏幕：

输入事件
 ↓
逻辑更新
 ↓
物理计算
 ↓
AI
 ↓
生成渲染指令
 ↓
GPU绘制
 ↓
屏幕显示

其中：

CPU 负责计算
GPU 负责渲染

整个过程：

CPU → GPU → Display

如果其中任意一环超过：

16.67ms（60FPS）

就会掉帧。例如，CPU 花费：

12ms

GPU 花费：

8ms

总时间：

20ms

那么：

1000 / 20 ≈ 50FPS

这就是卡顿的来源。

二、CPU 到底负责什么？

很多人以为：

游戏 = GPU

其实不是。CPU 才是整个游戏的大脑。

负责：

输入系统
状态更新
物理系统
碰撞检测
AI
动画计算
脚本执行
生成 DrawCall

例如：

update() {

    player.move()

    enemyAI.update()

    collisionSystem.check()

    bulletSystem.update()

}

这些全部运行在 CPU。CPU 工作流程：

Input
 ↓
Logic
 ↓
Physics
 ↓
AI
 ↓
Animation
 ↓
Render Command

最后把绘制命令提交给 GPU。

CPU
 ↓
Command Buffer
 ↓
GPU

所以：

CPU 不负责画画，它负责告诉 GPU 怎么画。

三、GPU 又负责什么？

GPU 负责真正把画面绘制出来。包括：

Vertex Shader

顶点变换：

模型
↓
世界坐标
↓
屏幕坐标

Fragment Shader

像素计算：

颜色
光照
阴影
透明度

Texture Sampling

纹理采样：

Image
↓
GPU Memory
↓
Pixel

Rasterization

光栅化：

三角形
↓
像素

最终：

Framebuffer
↓
Display

所以：

GPU 决定画面的复杂程度。

四、如何判断谁是瓶颈？

这是最重要的一步。

情况一

CPU：

18ms

GPU：

6ms

最终：

18ms

FPS：

55

这是 CPU Bound 瓶颈在 CPU。

情况二

CPU：

5ms

GPU：

22ms

FPS：

45

这是 GPU Bound 瓶颈在 GPU。

情况三

CPU：

10ms

GPU：

9ms

FPS：

60

说明：

性能正常

因此：

一帧时间 = max(CPU时间，GPU时间)

不是：

CPU+GPU

而是：

Frame Time = max(CPU, GPU)

因为 CPU 和 GPU 是流水线并行工作的。

五、CPU 瓶颈通常长什么样？

1、 AI 太多

例如：

for (let enemy of enemies) {
    enemy.updateAI()
}

500 个 NPC：

500 × PathFinding

CPU 会直接爆掉。

优化方案，降低更新频率：

if (frame % 10 == 0) {
    enemy.updateAI()
}

从：

60 次/s

变成：

6 次/s

几乎感觉不到差别。

2、碰撞检测太多

错误写法：

for player
    for enemy
        checkCollision()

复杂度：

O(n²)

1000 个对象：

1000000 次检测

优化，空间分区：

QuadTree
Grid
BVH

复杂度：

O(nlogn)

提升巨大。

3、对象频繁创建

错误：

update() {

    let bullet = new Bullet()

}

GC 会疯狂触发，导致：

卡顿
掉帧

优化，对象池。

bulletPool.get()

避免：

new
delete
GC

六、GPU 瓶颈通常长什么样？

1、DrawCall 太多

例如：

1000 个 Sprite

=
1000 DrawCall

CPU 和 GPU 都会受影响。优化 Sprite Batch 合并成：

10 DrawCall

提升几十倍。

2、透明层过多

错误：

UI
Particle
Fog
Shadow
Water

透明对象需要重复计算。造成：

Overdraw

GPU 爆炸，可以通过：

减少 Alpha
减少半透明层

优化。

3、Shader 太复杂

错误：

sin()
pow()
noise()
reflection()

大量像素执行：

1920 × 1080 × 60

每秒超过：

1 亿次计算

优化简化 Shader，例如：

color = texture(diffuseMap, uv);

避免复杂实时计算。

七、HarmonyOS 游戏最容易忽略的瓶颈

其实很多项目真正卡的地方是：

UI

例如：

@State hp

@State score

@State combo

@State exp

每次更新：

整个页面重新刷新

导致：

Build()
大量执行

CPU 占用飙升。例如：

build() {

    Column() {

        Player()

        EnemyList()

        SkillBar()

        BagPanel()

    }

}

如果：

score++

整个树重建，性能会迅速下降。

八、Store + Component 拆分才是关键

错误：

一个巨大页面

正确：

Page
 ↓
Component
 ↓
Store

只有局部刷新：

ScorePanel

而不是：

整个 GamePage

例如：

ScorePanel({
    score: scoreStore.score
})

只有：

ScorePanel.build()

重新执行，而：

Player
Enemy
Map

完全不动，这也是为什么大型游戏越来越喜欢：

ECS
Store
Reactive

因为：

性能优化，本质是减少不必要更新。

九、真正的性能优化流程

不要一上来就优化代码，正确流程：

第一步

定位瓶颈：

CPU？
GPU？
内存？
GC？
UI？

第二步

找到热点：

AI
碰撞
DrawCall
Shader
Build

第三步

局部优化：

对象池
Batch
LOD
缓存
组件拆分

第四步

验证 FPS

60FPS
120FPS

形成闭环。

十、未来 HarmonyOS 游戏优化会越来越偏向 ECS + Job System

传统结构：

Update()
 ↓
单线程
 ↓
Render

未来会逐渐变成：

Main Thread
      ↓
 Job System
 ↓    ↓    ↓
AI Physics Animation
      ↓
Render Thread
      ↓
GPU

甚至加入 Agent 后：

AI Agent
 ↓
Store
 ↓
System
 ↓
Render

形成：

CPU
 ↓
System
 ↓
GPU

真正做到：

多线程
高并发
60FPS
120FPS

总结

很多人优化 HarmonyOS 游戏时，总在问：

CPU 和 GPU，到底谁是瓶颈？

其实更准确的问题应该是：

这一帧，时间花在哪？

因为游戏性能的本质是：

Frame Time

而不是：

CPU 使用率
GPU 使用率

最后一句话总结：

性能优化不是“疯狂优化代码”，而是找到瓶颈，让 CPU 和 GPU 都不闲着。

只有理解了 CPU、GPU 的职责，以及它们之间的流水线关系，才能真正做出稳定 60FPS、甚至 120FPS 的 HarmonyOS 游戏。