子玥酱掘金 / 知乎 / CSDN / 简书 同名大家好我是子玥酱一名长期深耕在一线的前端程序媛 ‍。曾就职于多家知名互联网大厂目前在某国企负责前端软件研发相关工作主要聚焦于业务型系统的工程化建设与长期维护。我持续输出和沉淀前端领域的实战经验日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。技术方向前端 / 跨端 / 小程序 / 移动端工程化内容平台掘金、知乎、CSDN、简书创作特点实战导向、源码拆解、少空谈多落地文章状态长期稳定更新大量原创输出我的内容主要围绕前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读展开。文章不会停留在“API 怎么用”而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍希望能帮你在实际工作中少走弯路。子玥酱 · 前端成长记录官 ✨ 如果你正在做前端或准备长期走前端这条路 关注我第一时间获取前端行业趋势与实践总结 可领取11 类前端进阶学习资源工程化 / 框架 / 跨端 / 面试 / 架构 一起把技术学“明白”也用“到位”持续写作持续进阶。愿我们都能在代码和生活里走得更稳一点 文章目录引言一、先说结论二、最常见错误“万能 Service”按技术拆三、正确思路按“业务能力”拆正确结构四、第一层拆分核心业务 Service示例PlayerService示例TaskService五、第二层拆分领域内部再细化错误正确示例六、第三层Service 调用关系错误随意调用正确由“调度 Service”统一七、第四层接入 AI错误正确AI → Service调用 Service八、第五层接入网络错误正确示例九、第六层支持多端Service 不关心设备十、最终 Service 架构十一、判断你 Service 是否健康有这些问题正确状态十二、常见错误总结总结引言很多人写鸿蒙游戏一开始都会把 Service 层当成“工具层”UserService GameService DataService看起来已经“分层”了但只要项目一复杂很快就会出现Service 越写越大方法越来越多调用关系越来越乱AI / 多端接入困难最后你会发现Service 不是没写而是“没拆对”。在 HarmonyOS 的架构中Service 层不是“工具集合”而是“业务调度中心”。下面我们讲清楚Service 层应该怎么拆才能支持 AI 多端 可扩展一、先说结论一个健康的 Service 层必须做到1、单一职责每个 Service 只做一类事 2、面向业务按功能拆而不是按技术拆 3、只操作 Store不操作 UI 4、作为数据流入口UI / AI / 网络统一走这里如果你现在的 Service又请求网络又改 UI又写逻辑那一定有问题。二、最常见错误“万能 Service”exportclassGameService{asyncfetchData(){}movePlayer(){}playSound(){}login(){}}问题一个类 整个系统后果不可维护不可扩展无法拆模块按技术拆NetworkService StorageService UtilService问题没有业务语义调用会变成networkService.fetch(...)storageService.save(...)代码越来越碎。三、正确思路按“业务能力”拆正确结构services ├─ player │ └─ PlayerService ├─ task │ └─ TaskService ├─ battle │ └─ BattleService ├─ ai │ └─ AIService原则一个 Service 一个业务领域四、第一层拆分核心业务 Service示例PlayerServiceexportclassPlayerService{move(dx:number){gameStore.dispatch({type:MOVE_PLAYER,payload:dx})}takeDamage(value:number){gameStore.dispatch({type:DAMAGE,payload:value})}}特点只做“玩家相关逻辑”不关心 UI不直接请求网络示例TaskServiceexportclassTaskService{acceptTask(taskId:string){gameStore.dispatch({type:ACCEPT_TASK,payload:taskId})}completeTask(){gameStore.dispatch({type:COMPLETE_TASK})}}清晰、独立。五、第二层拆分领域内部再细化当某个 Service 变大错误PlayerService1000行正确player ├─ PlayerMoveService ├─ PlayerCombatService ├─ PlayerStateService示例exportclassPlayerCombatService{attack(){gameStore.dispatch({type:ATTACK})}}好处职责更清晰更容易维护六、第三层Service 调用关系错误随意调用taskService.complete()playerService.addScore()battleService.end()没有统一入口。正确由“调度 Service”统一exportclassGameFlowService{completeTask(){taskService.completeTask()playerService.addScore(10)battleService.end()}}本质流程统一调度七、第四层接入 AIAI 不应该直接操作 Store。错误gameStore.dispatch({type:ADD_SCORE})正确AI → ServiceclassNPCAgent{decide(){return{action:COMPLETE_TASK}}}调用 Serviceif(actionCOMPLETE_TASK){gameFlowService.completeTask()}本质AI 通过 Service 控制系统八、第五层接入网络错误UI→ fetch正确Service → Network示例exportclassRankService{asyncfetchRank(){constdataawaithttpClient.get(/rank)gameStore.dispatch({type:SET_RANK,payload:data})}}Service 负责请求 转换 入 Store九、第六层支持多端Service 不关心设备dispatch(action){this.reduce(action)this.sync(action)}Service 只负责触发 ActionStore 负责多端同步十、最终 Service 架构UI / AI / 网络 ↓ Service ↓ Action ↓ Store分层业务 Serviceplayer / task ↓ 子 Servicecombat / move ↓ 流程 Serviceflow十一、判断你 Service 是否健康有这些问题一个 Service 很大方法杂乱UI 调用多个 ServiceAI 直接改 Store正确状态职责清晰 调用简单 扩展容易十二、常见错误总结1、把 Service 当工具类2、按技术拆network / util3、Service 直接操作 UI4、AI 绕过 Service5、没有流程调度层总结鸿蒙游戏 Service 层的正确拆分方式按业务拆player / task / battle 内部细化move / combat 流程调度flow AI / 网络统一入口在 HarmonyOS 的架构中Service 的角色是连接 UI、AI、网络和 Store 的“中枢层”。最后Service 拆得好你的游戏是系统拆不好只是一堆函数。