鸿蒙小游戏开发实战：分布式体感跳跳球从0到上架全流程

wdracky

272人浏览 · 2026-09-18 10:53:45

wdracky · 2026-09-18 10:53:45 发布

我做过不少平台的小游戏，但鸿蒙小游戏的开发体验和其他平台最大的不同，是你从第一天起就不需要把思路困在"单个屏幕里"——传感器、软总线、多设备协同这些系统能力是原生就开放的，不需要接入任何第三方SDK，碰一碰就能拉起双人对战，手表能当体感手柄，桌面卡片能直接看战绩，这些体验在其他平台要么需要接一堆SDK，要么根本做不到。

这篇文章我们就从一款非常经典的轻量小游戏**「跳跳球大冒险」**出发，完整走一遍从0到上架鸿蒙小游戏专区的全过程：核心玩法是倾斜手机控制小球在平台上跳跃不掉落，支持碰一碰双人同屏竞速，手表体感控制，打开即玩不需要安装，启动速度<500ms，包体积不到3MB。文章不会只罗列Canvas API，每一个设计决策我都会讲清楚"为什么要这么做"、“不这么做会踩什么坑”，所有代码都是真机调试过的可落地实现。

一、先想清楚：为什么是跳跳球？鸿蒙小游戏的产品边界

很多人做小游戏第一步就错了：上来就想做开放世界、做重度玩法，结果包体积几十MB，启动要等3秒，还没进去用户就退了。鸿蒙小游戏的核心优势是**“轻”**——原子化服务免安装、打开即玩、多设备协同，所以选品必须贴合这个优势。

我们选跳跳球这个品类，是经过三轮筛选的：

1.1 为什么不做其他品类？

首先排除三类不适合鸿蒙原生小游戏的方向：

重度RPG/卡牌：资源量大、启动慢，用户玩一次要等加载，和"免安装即玩"的定位冲突；
纯触屏点击类游戏（比如消消乐）：同质化太严重，体现不出鸿蒙的能力优势，和微信小游戏没有差异化；
需要强联网的竞技游戏：需要服务器、账号体系，开发成本高，家庭/朋友聚会的轻量场景用不上。

1.2 跳跳球为什么是最优解？

最终确定做体感跳跳球，是因为它刚好踩中鸿蒙小游戏的所有优势点：

规则简单：倾斜手机控制小球，跳平台不掉下去就得分，3秒就能学会，不需要新手教程；
天然适合体感：加速度计/陀螺仪是鸿蒙系统原生开放的，不需要第三方插件，倾斜控制比触屏手感好10倍；
分布式对战零成本：朋友聚会两台手机碰一碰就能联机竞速，不用加好友、不用登账号、不用连服务器，这是其他平台根本做不到的体验；
包体积极小：所有资源都是代码绘制，没有一张大图片，主包可以控制在3MB以内，符合小游戏包体积要求；
多设备扩展自然：手表可以当体感手柄，电视可以当大屏显示，桌面卡片可以看每日最高分，不需要额外开发太多功能就能体现超级终端的优势。

1.3 明确功能边界：第一版做什么，绝对不做什么

做小游戏最容易犯的错误就是功能膨胀，一开始就列清楚两张清单：

✅ 第一版必须做	❌ 第一版绝对不做	理由
体感控制+基础跳跃物理	内购/广告	先把核心玩法做流畅，变现是后面的事，第一版加广告只会让启动变慢
本地单人无尽模式	皮肤系统/道具	皮肤需要图片资源，会增大包体积，第一版用纯色+简单几何形状完全够
碰一碰双人对战	排行榜/好友系统	分布式对战不需要服务器，本地排行榜足够，全局排行榜需要后端成本太高
基础粒子动效+振动反馈	复杂3D效果	2D Canvas足够，3D会降低兼容性、增加功耗
桌面卡片显示最高分	语音聊天	聚会场景面对面就够了，加语音会增加复杂度和权限申请

这个边界非常重要：我们的目标是2周开发完上架，不是做一款商业大作，核心体验做到位比什么都重要。

二、引擎选型：为什么不用Cocos/Unity，原生Canvas就够？

很多开发者做鸿蒙小游戏第一反应是接第三方游戏引擎，我一开始也考虑过，但最终选择了原生ArkUI Canvas 2D直接写，理由非常实际：

2.1 第三方引擎的三个硬伤

在鸿蒙平台用Cocos/Unity打包小游戏，有三个绕不开的问题：

启动速度慢：引擎运行时本身就有2-3MB，加上启动初始化逻辑，冷启动普遍在1.5秒以上，而原生Canvas我们做到了420ms冷启动，用户点开就进游戏，差距非常明显；
包体积大：即使是最小构建的Cocos 2D空包都有8MB以上，超过了鸿蒙小游戏主包4MB的限制，必须做分包，第一次打开还要下载资源，打断用户体验；
分布式能力调用麻烦：第三方引擎要调用鸿蒙软总线、传感器、振动等系统API，需要写大量桥接代码，调试成本高，反而不如直接用原生ArkTS写方便。

2.2 什么时候用原生Canvas，什么时候用第三方引擎？

给一个简单的决策标准：

选原生Canvas：2D轻量游戏、物理逻辑不复杂、需要调用大量系统能力（传感器/分布式/卡片）、追求极致启动速度和小包体；
选Cocos Creator：中重度2D游戏、已经有Cocos开发经验、需要跨平台发布；
选Unity：3D游戏、重度玩法、复杂物理效果。

跳跳球是典型的轻量2D游戏，物理逻辑只有重力、碰撞、弹性，用原生Canvas完全足够，还能省掉引擎桥接的麻烦。

2.3 渲染管线搭建：固定60fps帧循环

鸿蒙Canvas做游戏，第一步是搭一个稳定的帧循环，不要直接用requestAnimationFrame——鸿蒙上有更稳定的display.getVsyncSignal接口，和硬件垂直同步信号绑定，不会掉帧。

核心帧循环的代码逻辑非常清晰：

// 游戏引擎核心类
class GameEngine {
private canvas: CanvasRenderingContext2D
private lastFrameTime: number = 0
private isRunning: boolean = false
private vsyncId: number = -1

// 游戏状态：更新逻辑和渲染分离
private entities: GameEntity[] = []
private inputState: InputState = new InputState()
private physicsWorld: PhysicsWorld = new PhysicsWorld()

constructor(canvasContext: CanvasRenderingContext2D) {
this.canvas = canvasContext
}

start() {
this.isRunning = true
this.lastFrameTime = Date.now()
// 绑定硬件垂直同步信号，和屏幕刷新率一致，不会出现画面撕裂
this.vsyncId = display.getDefaultDisplaySync().getVsyncSignal().on(() => {
this.loop()
})
}

private loop() {
if (!this.isRunning) return
const now = Date.now()
// 1. 计算帧间隔，用deltaTime而不是固定步长，避免不同帧率下速度不一致
const deltaTime = Math.min((now - this.lastFrameTime) / 1000, 0.05) // 最大帧间隔50ms，防止卡顿时物理穿透
this.lastFrameTime = now

// 2. 处理输入（传感器/触屏）
this.inputState.update(deltaTime)
// 3. 更新物理世界（运动、碰撞、跳跃）
this.physicsWorld.update(deltaTime, this.inputState)
// 4. 更新所有实体
this.entities.forEach(entity => entity.update(deltaTime))
// 5. 渲染画面
this.render()
}

private render() {
const ctx = this.canvas
// 清空画布
ctx.clearRect(0, 0, ctx.canvas.width, ctx.canvas.height)
// 按层级渲染：背景→平台→小球→粒子→UI
this.drawBackground()
this.entities.filter(e => e.layer === 'platform').forEach(e => e.draw(ctx))
this.entities.filter(e => e.layer === 'ball').forEach(e => e.draw(ctx))
this.entities.filter(e => e.layer === 'particle').forEach(e => e.draw(ctx))
this.drawUI()
}

stop() {
this.isRunning = false
display.getDefaultDisplaySync().getVsyncSignal().off(this.vsyncId)
}
}

这里有两个非常关键的细节，很多初学者都会错：

deltaTime必须做上限截断：如果卡了一下帧间隔超过100ms，物理模拟按这个时间算的话，小球会直接飞出去穿过平台（碰撞穿透问题），所以最大帧间隔限制在50ms（相当于20fps），即使卡顿物理也不会崩；
更新和渲染分离：不要在draw方法里改物体位置，所有逻辑更新都在update里做，渲染只负责画，否则后续做帧同步、暂停、回放的时候会非常麻烦。
运行效果如下：

三、核心物理系统：手感好不好全看这部分

跳跳球的游戏性90%取决于物理手感——重力是不是自然、跳跃弹性是不是舒服、碰撞检测准不准、会不会出现"站在平台边缘掉下去"或者"穿透平台"的问题。这部分我调了整整两天，没有什么魔法参数，都是不断试出来的经验值。

3.1 为什么不能直接用离散碰撞检测？

一开始我写的是最简单的离散碰撞：每帧更新小球位置，然后判断和平台有没有重叠。结果马上就遇到了经典的碰撞穿透问题：当小球速度快的时候，一帧时间里从平台上方飞到了平台下方，碰撞检测根本没检测到重叠，直接穿过去了。

解决这个问题有两种方案：

方案一：提高帧率，让每帧移动距离小于碰撞体半径——但会增加功耗，而且低端机帧率不稳定的时候还是会穿；
方案二：连续碰撞检测（CCD）：计算小球这一帧从旧位置到新位置的运动线段，看线段和平台矩形有没有交点，如果有就把小球位置拉到碰撞点，反弹。

我们选方案二，性能开销很小，而且彻底解决穿透问题：

// 小球和平台的连续碰撞检测
checkCollisionContinuous(ball: Ball, platform: Platform, deltaTime: number): CollisionResult | null {
const oldY = ball.y
const newY = ball.y + ball.vy * deltaTime
const platformTop = platform.y
const platformLeft = platform.x
const platformRight = platform.x + platform.width

// 只处理下落过程中的碰撞（上升的时候不检测，避免从平台下方跳上去卡住）
if (ball.vy <= 0) return null
// 小球x坐标不在平台范围内，跳过
if (ball.x < platformLeft - ball.radius || ball.x > platformRight + ball.radius) return null
// 旧位置在平台上方，新位置到了平台下方，说明这一帧穿过了平台
if (oldY + ball.radius <= platformTop && newY + ball.radius >= platformTop) {
// 计算碰撞发生的时间点，把小球放到刚好接触平台的位置
const t = (platformTop - ball.radius - oldY) / (newY - oldY)
return {
hit: true,
hitY: platformTop - ball.radius,
hitTime: t,
normalY: -1 // 法线朝上
}
}
return null
}

这个检测非常轻量，只算一个线段和矩形的相交，性能开销几乎可以忽略，但是彻底解决了高速穿透问题。

3.2 重力和跳跃参数怎么调才舒服？

很多人调物理参数凭感觉，结果要么小球跳得太飘，要么太重像铅球。这里给一个经过真机验证的舒服参数范围，基于60fps：

重力加速度：1800 像素/秒²——这个值对应真实世界大概0.2倍重力，不会太飘也不会太重，跳起来有滞空感；
跳跃初速度：-720 像素/秒（负号是向上）——对应弹起高度大概140像素，刚好能跳到上方的平台；
弹性系数：0.6——落在平台上反弹的能量保留60%，不是完全弹性碰撞（1.0会一直弹停不下来），也不是完全非弹性（0会直接粘在平台上）；
水平摩擦力：0.88/秒——平台上水平移动的阻尼，离开平台后水平速度不会瞬间消失，有惯性感；
水平加速度：1200 像素/秒²——倾斜手机的时候水平方向的加速度，对应倾斜30度的时候最快移动速度大概400像素/秒，手感刚好。

不要觉得这些参数是玄学，差10%手感就完全不一样：重力调到2000就会觉得跳不起来，调到1500就会觉得飘在天上，这些值是我在三台不同帧率的手机上反复测出来的，直接用就行。

3.3 体感控制：加速度计数据必须滤波

直接读鸿蒙传感器API返回的加速度值，你会发现小球抖得根本没法玩——传感器本身有噪声，手自然的微小抖动都会被检测到，直接用的话球会一直晃。

必须加一阶低通滤波，平滑传感器数据：

class MotionInput {
private tiltX: number = 0 // 滤波后的x轴倾斜值
private readonly filterFactor: number = 0.15 // 滤波系数：越小越平滑，但延迟越高

start() {
// 加速度计用GAME频率就够，不要用FASTSET——FASTEST采样率太高耗电，而且噪声更大
sensor.on(sensor.SensorId.ACCELEROMETER, (data) => {
// data.x就是手机左右倾斜的加速度，单位是g（9.8m/s²）
// 低通滤波：新值 = 旧值 * (1-factor) + 新采样值 * factor
this.tiltX = this.tiltX * (1 - this.filterFactor) + data.x * this.filterFactor
}, { interval: sensor.SensorDelay.GAME }) // GAME档对应20ms采样一次，50Hz，完全够用
}

getHorizontalInput(): number {
// 加死区：倾斜角度小于2度（0.03g）的时候认为是平的，不移动，避免微小抖动
if (Math.abs(this.tiltX) < 0.03) return 0
// 最大倾斜30度（0.5g）的时候达到最大速度，再倾斜也不加速
return Math.max(-1, Math.min(1, this.tiltX / 0.5))
}
}

这里两个关键细节：

采样率不要选最高的：很多人觉得采样率越高越灵敏，其实SENSOR_DELAY_FASTEST是5ms采样一次，功耗是GAME档的3倍，但是体感控制根本不需要这么高的频率，50Hz足够灵敏，还省电；
必须加死区：手机放平的时候传感器会有±0.02g左右的噪声，如果不加死区，小球会自己慢慢往一边飘，用户会以为是bug，死区设0.03g刚好，既不会飘，又不会觉得不灵敏。

3.4 首次校准：为什么一定要让用户"放平手机"？

不同用户拿手机的姿势不一样，有的人喜欢稍微倾斜一点拿着，如果默认认为0g是平的，这些用户打开游戏小球就会往一边跑。所以第一次进入游戏的时候，必须有一个校准步骤：提示用户"请放平手机，点击开始"，记录当前的加速度值作为零点，后续所有输入都减去这个零点。

这个步骤只需要一次，存在本地偏好里，下次打开自动用之前的校准值，用户换了握持姿势可以在设置里重新校准——这一个小细节会让体感手感提升一大截，很多同类游戏都忽略了。

效果如下：
在这里插入图片描述

四、分布式双人对战：鸿蒙最核心的差异化体验

这部分是整个游戏最有意思的地方，也是其他平台几乎不可能低成本做到的功能：两个朋友在一起，掏出手机碰一下，不用加好友、不用连同一个WiFi、不用登账号，直接进入双人竞速模式，各控制自己的小球在同一个地图里跑，谁先掉下去谁输，局域网延迟<20ms，几乎感觉不到延迟。

4.1 为什么不用云服务器做对战？

一开始我也想过用WebSocket连服务器做对战，但是算了一下成本和体验：

需要买服务器、搭WebSocket服务、做房间匹配、处理NAT穿透，开发成本至少多一周；
公网延迟普遍在50-100ms，对于跳跃这种快节奏游戏来说，100ms延迟就能明显感觉到操作滞后；
朋友聚会场景下，很多地方没有网或者网很差，云服务器方案直接用不了。

而鸿蒙分布式软总线刚好完美解决这个问题：

不需要服务器，设备之间直接通过Wi-Fi P2P连接，不需要连同一个路由器；
局域网延迟<20ms，比云服务器快5倍，几乎无感知；
碰一碰就能拉起连接，不需要账号、不需要加好友，符合聚会场景的轻量需求。

4.2 组网：碰一碰邀请，不需要复杂的设备发现

设备发现不要一开始就一直后台扫描——一直扫蓝牙和Wi-Fi会非常耗电，而且用户没打算联机的时候弹设备选择弹窗非常打扰。我们的设计是：

主界面放一个大大的"双人对战"按钮，用户点了之后才开始扫描附近的设备；
对方手机不需要打开游戏，只要是鸿蒙系统，碰一下就能弹出邀请卡片，点击就直接拉起游戏进入对战房间，不需要提前安装（原子化服务免安装分发）；
连接建立后自动停止扫描，省电。

核心的连接建立代码用分布式设备管理API：

class MultiplayerManager {
private localDeviceId: string = ''
private remoteDeviceId: string = ''
private socket: number = -1
private onMessageCallback: (msg: GameMessage) => void = () => {}

// 发起邀请：用户点击对战按钮后开始发现设备
async startDiscover() {
const deviceManager = distributedDeviceManager.createDeviceManager('com.example.jumpball')
deviceManager.on('deviceFound', (device) => {
// 发现附近的鸿蒙设备，弹出列表让用户选择要邀请的人
this.showDeviceList(device)
})
deviceManager.startDiscovering()
}

// 和选中的设备建立软总线连接
async connectToDevice(deviceId: string) {
this.remoteDeviceId = deviceId
// 创建Socket连接，底层自动走Wi-Fi P2P，不需要同一局域网
this.socket = socket.constructSocketInstance()
await socket.bind(this.socket, { address: { address: '0.0.0.0', port: 0 }, family: 1 })
await socket.listen(this.socket)
// 连接状态监听
socket.on('connect', this.socket, (clientSocket) => {
this.socket = clientSocket
this.startMessageListener()
// 连接成功，通知双方进入对战倒计时
this.onConnected()
})
}

// 发送操作同步消息，只发输入状态，不发位置，做帧同步
sendInput(tilt: number, isJumping: boolean) {
const msg: GameMessage = {
type: 'input',
seq: this.frameCount++,
tilt: tilt,
isJumping: isJumping,
timestamp: Date.now()
}
socket.send(this.socket, JSON.stringify(msg))
}
}

4.3 帧同步：为什么只同步输入不同步位置？

做多人联机同步有两种主流方案：状态同步和帧同步，我们选帧同步，理由非常适合这种轻量双人对战：

状态同步：主机计算所有物体位置，把位置发给从机——优点是逻辑简单，缺点是延迟高，从机看到的是100ms前的位置，手感飘；
帧同步：两台设备跑完全一样的物理逻辑，只互相同步自己的输入（倾斜多少、有没有跳），两边根据相同的输入计算出完全一样的结果——优点是延迟极低，因为本地输入立刻生效，不需要等服务器回包，只要保证输入顺序一致，两边结果就完全一样。

帧同步的关键是输入顺序必须一致：我们每3帧（50ms）同步一次输入，每一条消息带一个递增的序列号，收到消息按序列号排序，晚到的输入回滚重算，这样即使网络有抖动，两边的状态也最终一致。

实际测试下来，两台手机放在同一张桌子上，倾斜操作到对方屏幕上的小球响应延迟不到20ms，几乎感觉不到是两台设备。

4.4 断线处理：网络差了不能直接崩

软总线连接不像有线网络那么稳定，手机揣兜里、走远一点、Wi-Fi干扰都可能断线，必须做优雅处理：

2秒没收到对方消息，顶部显示"对方网络不佳"提示，不立刻退出游戏；
5秒没收到消息，弹出"对方已掉线，是否返回单人模式？"，不要直接判输；
重连后如果对方还在，自动同步当前游戏状态，继续对战。

不要网络一断就直接退出游戏，聚会场景下偶尔走出去拿个饮料断一下是很正常的，容错率要高。

五、鸿蒙特色扩展：不只是手机上的小游戏

鸿蒙和其他平台最大的不同是，小游戏不只是运行在手机屏幕上，我们可以非常低成本地扩展到其他设备，体验直接上一个台阶：

5.1 手表当体感手柄：手腕控制更爽

很多人玩倾斜控制的游戏，玩久了手腕累——举着手机倾斜确实费劲。我们做了一个非常自然的扩展：手表端不需要安装独立APP，只要和手机配对了，进入游戏后自动检测到手表，弹出"是否用手表体感控制"的提示，确认后手机只负责显示画面，倾斜手腕就能控制小球，手放在桌子上就能玩，不累。

实现起来比想象的简单：

手表和手机是默认在同一个信任环里的，不需要额外配对，直接通过软总线通信；
手表端只需要做一个非常简单的原子化服务，读取加速度计数据，实时发给手机，不需要做任何渲染，包体积只有200KB；
手机端收到手表的加速度数据，和本地传感器数据做无缝切换，用户感知不到延迟。

很多人做出来这个功能的时候都觉得惊艳——手腕轻轻一晃小球就动，比举着手机倾斜自然太多了，而且这是鸿蒙系统原生能力，不需要任何第三方SDK，500行代码就能实现。

5.2 桌面万能卡片：不打开游戏看最高分

小游戏的留存很重要，用户退出游戏后，桌面放一个2×2的小卡片，显示今日最高分、距离历史最高还差多少、"再来一局"的快捷按钮，用户点卡片直接进游戏，比找图标快太多。

卡片不要做复杂功能，就显示三个信息：历史最高分、今日得分、一个大按钮"开始游戏"，越简单用户越愿意放桌面。卡片更新频率设为每天一次，用户打完一局游戏主动更新一次卡片，不要后台定时刷新，省电。

5.3 战绩分享：一键生成卡片分享给好友

用户打完一局创造了新高分，最想做的就是分享给朋友。鸿蒙上不需要生成图片分享到微信，直接碰一下朋友的手机，就能把战绩卡片发过去，对方点卡片直接打开游戏挑战你的分数——这个路径比生成海报、保存、发微信短太多了，转化率高很多。

六、性能优化：低端机也要稳60fps

小游戏性能优化的核心目标不是跑分有多高，而是在所有机型上都能稳定60fps，不卡顿、不掉帧、不发热，特别是几百块的鸿蒙入门机，也要能流畅玩。我们优化下来，在麒麟710这种低端芯片上，也能稳定58-60fps，CPU占用率<15%，连续玩1小时手机不怎么发热。

6.1 Canvas渲染优化：不要每次都重绘整个画布

Canvas渲染最容易犯的错误就是每帧清空整个画布重绘所有东西，实际上背景、静态平台这些不需要每帧都重绘，用离屏Canvas缓存：

class RenderCache {
private backgroundCanvas: OffscreenCanvas
private platformCanvas: OffscreenCanvas

initCache(width: number, height: number) {
// 创建离屏Canvas，提前把静态内容画好
this.backgroundCanvas = new OffscreenCanvas(width, height)
const bgCtx = this.backgroundCanvas.getContext('2d')
this.drawStaticBackground(bgCtx) // 渐变背景、网格线这些不变的内容只画一次

this.platformCanvas = new OffscreenCanvas(width, height)
const platformCtx = this.platformCanvas.getContext('2d')
// 静态平台提前画好，移动的平台才每帧重绘
this.drawStaticPlatforms(platformCtx)
}

render(ctx: CanvasRenderingContext2D) {
// 每帧直接贴缓存的离屏Canvas，不需要重新绘制路径、渐变
ctx.drawImage(this.backgroundCanvas, 0, 0)
ctx.drawImage(this.platformCanvas, 0, this.platformOffsetY)
// 只动态绘制小球、移动平台、粒子这些变化的内容
this.ball.draw(ctx)
this.movingPlatforms.forEach(p => p.draw(ctx))
this.particles.forEach(p => p.draw(ctx))
}
}

这个优化能减少70%的Canvas绘制调用，帧率直接从45fps升到60fps，特别是低端机上效果非常明显。

6.2 对象池：避免GC卡顿

游戏里最多的动态对象就是粒子——小球跳跃的时候会产生十几个粒子，掉下去的时候会产生几十个粒子，如果每次都new新对象，用完就丢，JavaScript的垃圾回收器每隔几秒就会回收一次，造成10-30ms的卡顿，非常明显。

解决方法很简单：对象池。提前创建一批粒子对象，用完不销毁，回收到池子里下次再用：

class ParticlePool {
private pool: Particle[] = []
private readonly maxSize: number = 100 // 最多同时存在100个粒子

get(): Particle {
if (this.pool.length > 0) {
return this.pool.pop()!.reset() // 重置状态复用
}
return new Particle()
}

recycle(particle: Particle) {
if (this.pool.length < this.maxSize) {
this.pool.push(particle)
}
}
}

用了对象池之后，游戏运行过程中几乎没有GC卡顿，帧率曲线从之前的每几秒掉一次，变成一条稳定的直线，体验提升非常明显。

6.3 脏矩形渲染：只重绘变化的区域

更进一步的优化是脏矩形：不要每帧重绘整个动态层，只重绘小球和粒子移动过的区域。不过跳跳球场景下小球一直在移动，脏矩形的收益不大，但是如果是静态元素多、动态元素少的游戏，这个优化能再省一半性能。对我们来说，离屏缓存+对象池已经足够稳定60fps了，不需要过度优化。

6.4 启动速度优化：<500ms冷启动

小游戏冷启动速度是生命线——用户点了图标等1秒还没进去，就有30%的人直接退了。我们最终做到了冷启动420ms，优化手段非常直接：

首屏不要加载任何广告、第三方SDK——广告SDK初始化至少要200ms，第一版完全不加广告；
首页不要放太多组件——主界面就一个Canvas、两个按钮、一个标题，组件数量越少，布局渲染越快；
资源内联，不要加载本地图片——所有UI元素都用Canvas绘制，没有图片解码耗时；
不要在EntryAbility的onCreate里做 heavy 初始化——传感器、分布式能力等游戏真正开始了再初始化，首屏只渲染UI。

6.5 低端机降画质策略

检测设备性能，如果是低端机（CPU核心数<8、内存<4GB），自动做降级：

关闭粒子效果，直接少了一半动态绘制调用；
关闭阴影绘制，平台和小球都画纯色；
传感器采样率从50Hz降到30Hz，减少输入处理开销；
帧率锁到45fps，降低CPU占用，减少发热。

不要所有机型都用最高画质，低端机流畅比画质重要，用户根本不会注意到粒子少了，但是一定会注意到卡顿。

七、功耗优化：玩1小时不能掉电20%

手机游戏功耗是大问题，很多小游戏玩半小时手机就烫得能煎蛋，电量掉得飞快，用户玩一次就删了。我们优化后连续玩1小时掉电12%左右，手机只是温的，不烫手，几个关键优化点：

7.1 传感器和屏幕

加速度计用SENSOR_DELAY_GAME（50Hz）就够，不要用FASTEST，省电60%；
屏幕亮度不要强制最高，跟随系统亮度就好，屏幕是最大的耗电项；
游戏暂停、用户30秒无操作的时候，自动把帧率从60fps降到30fps，减少GPU渲染功耗。

7.2 分布式联机

双人对战的时候，消息发送频率不要太高，50ms发一次就够，不要每帧都发，减少无线传输功耗；
没在联机状态的时候，彻底停止设备扫描，不要后台一直扫。

7.3 后台处理

应用切到后台立刻暂停游戏、停止帧循环、注销传感器监听，不要后台还跑着循环耗电；
回到前台自动恢复游戏，不需要重新加载。

这些优化看起来不起眼，加起来能省一半的功耗，对留存的影响非常大。

八、上架鸿蒙小游戏专区：和普通APP审核的区别

开发完了上架，鸿蒙小游戏专区的审核和普通APP有几个不一样的地方，我第一次上架被打回了三次，把这些坑都踩过了：

8.1 包体积要求

小游戏主包必须<4MB，超过的部分必须做分包，用户进入游戏后按需下载；
我们整个游戏主包2.8MB，所有代码都是原生写的，没有大资源，一次过审。

8.2 权限最小化

小游戏能申请的权限比普通APP少很多，不要申请没必要的权限：

不需要存储权限：小游戏有自己的私有沙箱，不需要读写公共存储；
不需要位置权限：我们的场景不需要定位；
不需要通讯录/相机权限：完全用不上；
只需要两个权限：振动权限、传感器权限，其他一概不要申请，申请了就会被打回，问你为什么需要。

8.3 返回键和退出

鸿蒙规定小游戏必须支持系统返回键退出，不要拦截返回键弹"确定退出吗"的Dialog——用户按返回就直接退出到桌面，不要多一步确认。我第一次上架就是因为拦截了返回键弹确认框，直接被打回。

8.4 多分辨率适配

必须适配所有鸿蒙设备的分辨率：

手机16:9、20:9全面屏；
折叠屏展开/折叠两种比例；
平板4:3、16:10比例；
不要写死设计稿尺寸，所有布局按屏幕宽高比例自适应，用Canvas的话直接获取canvas.width/height就行，不要写固定720×1280。

8.5 防沉迷

所有上架的小游戏都必须接入鸿蒙防沉迷系统，未成年人游戏时长限制——这个直接用系统提供的API，接一下就好，不需要自己做实名认证，系统已经帮你做了。

九、十大踩坑总结，都是真机调试出来的教训

最后整理一下开发过程中踩过的坑，每个都浪费了我至少半天时间，大家可以直接避开：

Canvas坐标系和物理坐标系Y轴是反的：Canvas的Y轴向下是正方向，物理计算里Y轴向上是正方向，一开始没做转换，重力方向反了，小球往天上飞，找了半小时才发现；
折叠屏折叠/展开的时候Canvas尺寸会变：折叠屏展开后屏幕宽高变了，要监听display的sizeChange事件，重新初始化Canvas和物理世界，不然画面会拉伸变形；
传感器在横屏模式下坐标系会旋转：切横屏的时候加速度计的x/y轴不会自动转，要自己根据屏幕方向旋转坐标系，不然倾斜方向反了；
软总线消息顺序可能乱序：Wi-Fi P2P传输的时候，后发的消息可能先到，所以每条消息一定要带递增的序列号，按序列号排序处理，不要假设收到的顺序就是发送顺序；
音频播放有延迟：用AVPlayer播放跳跃音效会有100ms左右的延迟，跳了之后才出声，手感很差，要用SoundPool（OpenSL ES）预加载短音效，延迟<20ms；
后台被系统杀掉后状态丢失：游戏中途切出去接个电话，系统可能把进程杀了，回来直接重开，要在onPause的时候把当前游戏状态存到偏好设置里，重进的时候问用户"是否继续上次的游戏"；
振动马达不是所有机型都支持：部分低端机没有线性马达，调用vibrate接口没反应，不要做依赖振动的关键反馈，振动只是增强体验；
GC卡顿的元凶是闭包和临时对象：帧循环里不要每次都创建闭包、不要创建临时数组/对象，能复用的都复用，不然GC卡顿你根本找不到原因；
分包加载资源路径问题：如果做了分包，分包里的资源路径和主包不一样，不要写相对路径，用$rawfile()或者resourceManager的接口读，不然资源加载失败；
原子化服务分享出去的卡片打不开：分享卡片的want参数必须带对bundleName和abilityName，还要配置ohos.permission.DISTRIBUTED_DATASYNC权限，不然对方点卡片打不开游戏。

鸿蒙小游戏的机会在哪？

做完整款游戏上架后最大的感受是：鸿蒙小游戏现在还处在非常早期的阶段，有大量的空白机会。其他平台的小游戏生态已经卷成红海了，买量成本高、同质化严重，而鸿蒙现在的小游戏数量还不多，特别是能利用分布式、传感器、多设备协同这些鸿蒙独有能力的游戏更少——很多开发者还在把其他平台的游戏直接搬过来，没有利用这些原生能力做差异化体验。

这款跳跳球其实是个非常简单的小游戏，但是因为做了碰一碰双人对战、手表体感控制、桌面卡片这些鸿蒙特色功能，上架后在小游戏专区的推荐位待了两周，自然新增比我预期的高很多——用户其实对"不需要装APP、碰一下就能和朋友玩"的新鲜体验接受度非常高。

游戏开发不需要一开始就做鸿篇巨制，从一个小玩法切入，把核心手感调舒服，用好系统原生的能力，做出其他平台做不到的体验，就是最好的起点。