ArkUI 项目结构设计：小项目 vs 大项目

网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。图书作者《ESP32-C3 物联网工程开发实战》图书作者《SwiftUI 入门进阶与实战》超级个体COC上海社区主理人特约讲师大学讲师谷歌亚马逊分享嘉宾科技博主华为HDE/HDG我的博客内容涵盖广泛主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告同时也会提供产品优缺点分析、横向对比并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。展菲您的前沿技术领航员 大家好我是展菲 全网搜索“展菲”即可纵览我在各大平台的知识足迹。 公众号“Swift社区”每周定时推送干货满满的技术长文从新兴框架的剖析到运维实战的复盘助您技术进阶之路畅通无阻。 微信端添加好友“fzhanfei”与我直接交流不管是项目瓶颈的求助还是行业趋势的探讨随时畅所欲言。 最新动态2025 年 3 月 17 日快来加入技术社区一起挖掘技术的无限潜能携手迈向数字化新征程文章目录引言一、小项目为什么“看起来很简单”为什么这样可以小项目的本质二、小项目结构的“隐性问题”一旦项目变大就会出现1、页面爆炸2、逻辑分散3、复用困难4、状态混乱三、大项目结构的核心目标四、推荐的大项目结构基础分层版本各层职责五、从小项目演进到大项目小项目写法大项目写法1、Model2、Service3、Page六、再进阶按“业务模块”拆分示例结构七、状态管理在大项目中的位置小项目大项目示例八、组件设计差异小 vs 大小项目组件大项目组件九、一个非常实用的判断标准如果你开始出现十、常见误区总结小项目中型项目大型项目引言很多人刚开始写 ArkUI 项目时结构都很简单entry ├─ pages ├─ components └─ utils写 Demo、写小工具完全没问题。但只要项目稍微复杂一点就会开始出现熟悉的问题页面越来越大逻辑到处都是状态难以管理改一个功能影响一大片最后你会发现问题不是功能难而是结构撑不住。一、小项目为什么“看起来很简单”先看一个典型小项目结构entry ├─ pages │ ├─ Home.ets │ └─ Detail.ets │ ├─ components │ └─ utils为什么这样可以因为小项目通常有几个特点页面少35个逻辑简单数据量小没有复杂状态所以// 页面里直接写逻辑asyncloadData(){constresawaitfetch(...)this.listres}也不会出大问题。小项目的本质“页面驱动”Page UI 逻辑 数据结论小项目不是结构好而是复杂度还没暴露二、小项目结构的“隐性问题”很多人会说“我这个结构也能用啊”确实能用但问题在于它不具备“扩展能力”一旦项目变大就会出现1、页面爆炸Home.ets →500行 →1000行2、逻辑分散A 页面写接口B 页面写业务C 页面写状态3、复用困难// 同样逻辑写三遍4、状态混乱this.datathis.listthis.user到处都是。本质问题没有分层三、大项目结构的核心目标当项目变大结构设计的目标会发生变化从能跑到可维护、可扩展、可复用所以大项目必须做一件事分层Layered Architecture四、推荐的大项目结构基础分层版本entry ├─ pages ├─ components ├─ services ├─ models ├─ store └─ utils各层职责pages 页面UI 入口 components UI 组件 services 业务逻辑 models 数据结构 store 状态管理 utils 工具函数核心原则UI、业务、数据分离五、从小项目演进到大项目小项目写法EntryComponentstruct HomePage{Statelist:any[][]asyncloadData(){constresawaitfetch(/api/list)this.listawaitres.json()}}大项目写法1、ModelexportinterfaceItem{id:numbername:string}2、ServiceexportclassItemService{asyncgetList():PromiseItem[]{constresawaitfetch(/api/list)returnawaitres.json()}}3、PageEntryComponentstruct HomePage{Statelist:Item[][]service:ItemServicenewItemService()asyncaboutToAppear(){this.listawaitthis.service.getList()}}变化非常关键Page → 不再写业务逻辑 Service → 负责逻辑六、再进阶按“业务模块”拆分当项目继续变大仅仅分层还不够。需要按业务模块拆分Feature-based示例结构entry ├─ features │ ├─ home │ │ ├─ pages │ │ ├─ components │ │ ├─ services │ │ └─ models │ │ │ ├─ user │ │ ├─ pages │ │ ├─ services │ │ └─ models │ ├─ common │ ├─ components │ ├─ services │ └─ utils │ └─ store本质从“技术分层” → “业务分层”七、状态管理在大项目中的位置在 ArkUI 中状态是核心。小项目Statedata大项目store ├─ userStore ├─ appStore └─ gameStore示例classUserStore{user{}setUser(u){this.useru}}核心状态必须集中管理八、组件设计差异小 vs 大小项目组件// 直接写Text(Hello)大项目组件Componentexportstruct UserCard{Propuser:User}区别临时 UI → 可复用组件九、一个非常实用的判断标准你可以用这个来判断是否需要升级架构如果你开始出现页面超过 300 行同一逻辑写了 2 次状态不好管理改一个功能影响多个页面那就说明你的项目已经“超出小项目结构能力”十、常见误区1、一开始就用大项目结构过度设计。2、永远停留在小项目结构后期崩溃。3、只分文件不分职责// 分了目录但还是乱写本质结构不是目录而是职责总结ArkUI 项目结构本质是随着复杂度演进的。小项目pages components utils特点简单快速开发中型项目 services models特点分层清晰可维护大型项目Feature-based Store特点模块化可扩展最后一句话总结在 ArkUI 中项目结构不是一开始就定死的而是随着复杂度“进化”的。而你要做的不是选一个“完美结构”而是在“刚好复杂”的时候做“刚好合理”的拆分。