鸿蒙游戏 UI 怎么设计才不乱?

张开发
2026/4/16 17:29:17 15 分钟阅读

分享文章

鸿蒙游戏 UI 怎么设计才不乱?
网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。图书作者《ESP32-C3 物联网工程开发实战》图书作者《SwiftUI 入门进阶与实战》超级个体COC上海社区主理人特约讲师大学讲师谷歌亚马逊分享嘉宾科技博主华为HDE/HDG我的博客内容涵盖广泛主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告同时也会提供产品优缺点分析、横向对比并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。展菲您的前沿技术领航员 大家好我是展菲 全网搜索“展菲”即可纵览我在各大平台的知识足迹。每周定时推送干货满满的技术长文从新兴框架的剖析到运维实战的复盘助您技术进阶之路畅通无阻。文章目录引言一、先说结论二、最常见的“乱 UI”写法一个页面写完一切三、第一步UI 只做“展示”UI 写逻辑正确四、第二步状态只来自 Store页面维护状态正确五、第三步组件拆分巨型 UI拆组件示例六、第四步组件分层推荐分层示例七、第五步避免深层嵌套深层嵌套拆出去八、第六步UI 状态分离单独 UI StoreUI 使用九、第七步状态驱动 UI示例十、第八步UI 与多端适配写死布局响应式十一、最终 UI 结构页面代码十二、判断 UI 是否“健康”有这些问题正确状态十三、常见错误总结总结引言很多人刚开始用 ArkUI 写鸿蒙游戏 UI会有一种错觉“声明式 UI看起来很简单。”但写着写着就变成这样UI 代码越来越长嵌套越来越深状态到处都是修改一个地方牵一发动全身最后你会得到一个典型结果UI 不是难写而是“写乱了”。在 HarmonyOS 的 ArkUI 体系中UI 设计的核心不是“怎么写”而是“怎么组织”。一、先说结论一个不乱的 UI一定满足1、UI 只做展示不写逻辑 2、状态单向流动Store → UI 3、组件可复用拆分 4、层级清晰结构化如果你现在的 UI有逻辑有网络有复杂计算那一定会乱。二、最常见的“乱 UI”写法一个页面写完一切Column(){Text(玩家)if(this.score10){Text(高手)}Button(攻击).onClick((){this.scorethis.attackEnemy()})ForEach(this.list,item{Row(){Image(item.icon)Text(item.name)}})}问题UI 逻辑 状态 渲染 全混在一起一旦复杂完全不可维护三、第一步UI 只做“展示”UI 写逻辑onClick(()this.score)正确onClick(()gameService.addScore())UI 只负责触发事件 展示数据所有逻辑进 Service。四、第二步状态只来自 Store页面维护状态Statescore:number0正确StatestategameStore.stateUI 永远只读Store → UI不允许UI → 改状态五、第三步组件拆分巨型 UIColumn(){玩家信息 背包 技能栏 地图}拆组件components ├─ PlayerPanel ├─ InventoryPanel ├─ SkillPanel └─ MapView示例PlayerPanel({player:this.state.player})InventoryPanel({items:this.state.items})原则一个组件只做一件 UI 事情六、第四步组件分层UI 不只是“拆”还要“分层”。推荐分层Page页面 ↓ Container容器组件 ↓ Component业务组件 ↓ Atom基础组件示例PageGamePageContainerGameHUD血量分数UI控制ComponentPlayerInfo ScoreBoardAtomIcon Button Text好处层次清晰可复用不会混乱七、第五步避免深层嵌套深层嵌套Column(){Row(){Column(){Row(){Text()}}}}可读性极差。拆出去MainLayout()PlayerInfo()原则嵌套超过 3 层就该拆组件八、第六步UI 状态分离有些 UI 状态弹窗 loading 选中状态不应该和业务混在一起。单独 UI StoreuiStore{loading:false,dialogVisible:false}UI 使用if(this.uiState.loading){LoadingView()}本质UI 状态 ≠ 游戏状态九、第七步状态驱动 UIArkUI 最大优势状态变化 → UI 自动更新示例Text(Score:${this.state.score})不要写this.updateUI()一切交给状态。十、第八步UI 与多端适配鸿蒙特点手机 / 平板 / TV写死布局width(300)响应式if(device.typetv){width(600)}或使用自适应布局。十一、最终 UI 结构pages └─ GamePage components ├─ hud ├─ player ├─ battle └─ common页面代码EntryComponentstruct GamePage{StatestategameStore.statebuild(){Column(){GameHUD({state:this.state})PlayerPanel({player:this.state.player})BattleView({battle:this.state.battle})}}}页面非常干净。十二、判断 UI 是否“健康”有这些问题页面超过 500 行嵌套很深到处写逻辑状态混乱正确状态组件清晰 结构简单 职责单一十三、常见错误总结1、UI 写逻辑2、UI 直接改状态3、不拆组件4、嵌套过深5、UI 和业务状态混用总结鸿蒙游戏 UI 设计的核心UI 只展示 状态来自 Store 组件必须拆 层级要清晰在 HarmonyOS 的 ArkUI 架构中这种设计带来的不是“代码整洁”而是从“写页面”升级为“设计 UI 系统”。最后UI 一旦乱了后面所有开发都会变慢UI 一旦清晰整个项目都会加速。

更多文章