尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

传统游戏引擎 vs 鸿蒙 System 架构

传统游戏引擎 vs 鸿蒙 System 架构 网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。图书作者《ESP32-C3 物联网工程开发实战》图书作者《SwiftUI 入门进阶与实战》超级个体COC上海社区主理人特约讲师大学讲师谷歌亚马逊分享嘉宾科技博主华为HDE/HDG我的博客内容涵盖广泛主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告同时也会提供产品优缺点分析、横向对比并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。展菲您的前沿技术领航员 大家好我是展菲 全网搜索“展菲”即可纵览我在各大平台的知识足迹。每周定时推送干货满满的技术长文从新兴框架的剖析到运维实战的复盘助您技术进阶之路畅通无阻。文章目录引言一、先说结论二、传统游戏引擎在解决什么问题三、鸿蒙 System 架构在解决什么问题四、核心对比控制权在哪里传统引擎鸿蒙架构五、一个非常关键的区别渲染权在 Unity 中在 ArkUI 中六、架构形态对比传统引擎结构鸿蒙 System 架构七、开发方式的差异传统引擎思维鸿蒙 System 思维Unity 写法鸿蒙写法八、扩展性的差异传统引擎鸿蒙架构九、多端能力的本质差异传统引擎鸿蒙 System 架构十、性能模型差异传统引擎鸿蒙架构十一、开发者最容易犯的错误错误 1在鸿蒙里写“伪引擎”错误 2忽略 System错误 3用帧驱动思维写状态系统十二、一个终极认知传统世界鸿蒙世界总结引言当你真正把鸿蒙游戏做复杂之后你大概率会产生一个疑问我现在这套 System 架构和传统游戏引擎到底是什么关系很多人会本能地对标Unity Unreal甚至会试图“在鸿蒙里复刻一个引擎”。但如果你这么做很快就会踩坑架构越来越重 代码越来越绕 性能未必更好 开发体验反而下降原因只有一个你在用“旧时代的引擎思维”套“新时代的系统架构”一、先说结论传统游戏引擎 引擎驱动游戏鸿蒙 System 架构 状态驱动世界这是两套完全不同的范式。二、传统游戏引擎在解决什么问题以 Unity、Unreal Engine 为代表传统引擎核心解决的是渲染 物理 动画 输入 生命周期典型结构GameLoop ↓ Update() ↓ Render()特点开发者控制一切 帧循环是核心 所有系统挂在引擎上一句话总结引擎是“中心控制器”三、鸿蒙 System 架构在解决什么问题在鸿蒙尤其是 ArkUI里很多事情已经变了渲染 → 系统负责 UI → 声明式 状态 → 自动驱动更新你不再需要写render()你只需要改变状态于是问题变成状态如何变化答案就是System四、核心对比控制权在哪里传统引擎Engine 控制 什么时候更新 怎么渲染 调谁执行鸿蒙架构System 控制 状态如何变化 规则如何执行Engine 只负责调度五、一个非常关键的区别渲染权在 Unity 中voidUpdate(){transform.positionvelocity}你在“手动控制每一帧”。在 ArkUI 中Text(store.hp.toString())你只描述“状态”。系统决定什么时候渲染 怎么渲染 如何优化结论传统引擎你控制像素鸿蒙架构你控制状态六、架构形态对比传统引擎结构GameEngine ┌─────┼─────┐ Render Physics Input │ │ │ GameObject / Component鸿蒙 System 架构Store │ ┌──────────┼──────────┐ │ │ │ Battle AI System Drop System \ | / └── Engine ─┘ │ UI本质差异传统围绕“引擎”组织 鸿蒙围绕“状态”组织七、开发方式的差异传统引擎思维写一个对象 挂组件 在 Update 里写逻辑鸿蒙 System 思维定义状态 拆分 System 通过规则改变状态一个简单对比Unity 写法if(hp30){RunAway()}鸿蒙写法constactionai.decide(store)battle.execute(store,action)区别行为被“抽象” 逻辑被“分层”八、扩展性的差异传统引擎增加功能加组件 改 Update 加依赖容易耦合增长 维护困难鸿蒙架构增加功能新增 System 接入 Engine特点天然解耦 按领域扩展九、多端能力的本质差异这是最关键的一点。传统引擎多端 多套适配问题同步困难 状态分裂 逻辑重复鸿蒙 System 架构多端 同一 Store 的多视图因为状态唯一 UI 多实例所以天然支持多设备一致性十、性能模型差异传统引擎性能取决于 帧循环效率 渲染优化鸿蒙架构性能取决于 状态变更频率 System 执行效率 UI diff 成本换句话说你优化的不是“帧”而是“状态变化”十一、开发者最容易犯的错误错误 1在鸿蒙里写“伪引擎”classSuperEngine{render()physics()}问题重复造轮子 违背框架设计错误 2忽略 System逻辑写在 UI / Engine结果架构崩塌错误 3用帧驱动思维写状态系统每 16ms 改状态问题不稳定 不可控十二、一个终极认知当你真正理解这两套体系后你会发现你不是在“换引擎”而是在换一套“世界运行方式”传统世界时间驱动Frame ↓ 对象变化 ↓ 渲染鸿蒙世界状态驱动State ↓ System 执行 ↓ UI 自动呈现总结传统游戏引擎与鸿蒙 System 架构的本质区别传统Engine 驱动一切 鸿蒙System 定义一切如果用一句话总结传统引擎在“模拟世界的运行”而鸿蒙架构是在“定义世界的规则”。
返回列表