网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。图书作者《ESP32-C3 物联网工程开发实战》图书作者《SwiftUI 入门进阶与实战》超级个体COC上海社区主理人特约讲师大学讲师谷歌亚马逊分享嘉宾科技博主华为HDE/HDG我的博客内容涵盖广泛主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告同时也会提供产品优缺点分析、横向对比并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。展菲您的前沿技术领航员 大家好我是展菲 全网搜索“展菲”即可纵览我在各大平台的知识足迹。每周定时推送干货满满的技术长文从新兴框架的剖析到运维实战的复盘助您技术进阶之路畅通无阻。文章目录引言一、传统 App 构建本质是“页面打包”二、鸿蒙 PC 为什么完全不一样三、DevEco 到底在做什么四、鸿蒙构建的真正核心Module 化五、HAP真正的运行单元六、HAR为什么它不是普通 Library七、真正的大项目一定是“多层构建体系”1、Foundation Layer2、Runtime Layer3、Domain Layer4、Workspace Layer八、为什么很多鸿蒙项目后期构建越来越慢九、真正稳定的构建体系领域隔离十、鸿蒙 PC 为什么天然适合“动态化”十一、真正复杂的不是 UI而是 Runtime十二、发布阶段真正发生了什么1、能力注册2、Runtime 绑定3、设备能力适配4、安全与签名十三、为什么鸿蒙 PC 构建越来越像“系统工程”十四、真正的未来构建“状态运行系统”十五、总结引言很多人第一次做鸿蒙 PC 应用时会下意识觉得不就是“写完代码 → 点发布”吗因为在很多移动开发场景里构建 ≈ 打包但真正开始做鸿蒙 PC 项目之后很快就会发现多模块越来越复杂HAP / HAR 开始混乱多设备构建越来越重Debug 与 Release 行为不一致DevEco 编译越来越慢多窗口资源开始失控AI / 分布式模块越来越难管理最后团队会慢慢意识到鸿蒙 PC 的“构建体系”其实已经不是简单打包。而是一套完整的“系统运行组织结构”。因为鸿蒙 PC 真正复杂的地方不是页面 而是状态系统 多模块协同所以构建体系 本质上就是系统结构一、传统 App 构建本质是“页面打包”过去很多移动应用页面 ↓ 资源 ↓ 安装包本质就是静态资源打包所以APKIPAWeb Bundle核心都围绕页面与资源组织。二、鸿蒙 PC 为什么完全不一样因为鸿蒙 PC 真正运行的不是“页面” 而是“状态系统”它天然具备多窗口Workspace分布式状态动态能力Task RuntimeAI Runtime跨设备协同这些意味着构建目标不再只是“生成页面”。而是组织系统运行结构三、DevEco 到底在做什么很多人把 DevEco Studio 理解成一个 IDE其实不是它真正核心更像HarmonyOS Runtime Organizer也就是说DevEco 不只是“编译代码”。而是在组织ModuleAbilityStateResourceRuntimeDevice Capability四、鸿蒙构建的真正核心Module 化很多人第一次接触鸿蒙工程时会看到entry feature library har hap然后开始迷糊其实核心思想非常简单鸿蒙不是“页面组织”。而是能力组织五、HAP真正的运行单元很多人误以为HAP ≈ APK其实差异很大在鸿蒙里HAP 更像“动态能力容器”它不只是页面资源还包括AbilityService状态能力分布式能力也就是说HAP 本质是 Runtime Module。六、HAR为什么它不是普通 Library很多团队会把HAR当成工具库但真正大型鸿蒙项目里HAR 更像领域能力模块例如order.har message.har workspace.har ai.har这里面不只是 UI还包括StoreTaskRepositoryRuntimeFocus Logic所以HAR 本质是领域系统单元七、真正的大项目一定是“多层构建体系”成熟鸿蒙 PC 项目通常会变成App ↓ Workspace Layer ↓ Domain Layer ↓ Runtime Layer ↓ Foundation Layer1、Foundation Layer负责网络日志存储分布式能力AI Runtime例如foundation.har2、Runtime Layer负责Task 调度FocusWorkspace生命周期例如runtime.har3、Domain Layer负责订单用户消息AI Agent例如order.har user.har4、Workspace Layer负责多窗口布局状态投影例如workspace.har八、为什么很多鸿蒙项目后期构建越来越慢因为模块边界失控很多项目所有模块互相依赖Store 到处引用System 横向耦合HAR 无限膨胀最后一次修改 全量重编译九、真正稳定的构建体系领域隔离后来很多成熟团队都会慢慢演化成领域独立构建例如user.har绝不能依赖order.har而应该通过 Runtime 通信否则整个工程会越来越重十、鸿蒙 PC 为什么天然适合“动态化”这一点很多人忽略传统 App页面编译完成 ↓ 功能固定但鸿蒙能力可动态加载因为系统核心是 Runtime不是静态页面所以未来AI Plugin动态 WorkspaceTask ModuleAgent Skill都会越来越重要。十一、真正复杂的不是 UI而是 Runtime很多人后期会发现UI 根本不是最难的真正复杂的是Task Runtime状态同步分布式状态多窗口生命周期AI Runtime所以构建体系最终会越来越像“操作系统”而不是页面工程十二、发布阶段真正发生了什么很多人觉得Release 生成安装包其实鸿蒙发布真正做的是1、能力注册例如AbilityService分布式能力2、Runtime 绑定例如Workspace RuntimeFocus RuntimeTask Runtime3、设备能力适配例如PC手机平板分布式设备4、安全与签名包括权限分布式身份设备可信关系十三、为什么鸿蒙 PC 构建越来越像“系统工程”因为应用已经开始“系统化”传统 App页面 接口而鸿蒙 PCWorkspace Runtime State Flow复杂度已经完全不同。十四、真正的未来构建“状态运行系统”未来大型鸿蒙 PC 项目真正核心会慢慢变成Task Runtime Workspace Runtime AI Runtime Distributed Runtime而不是页面打包这也是为什么鸿蒙 PC 后期越来越不像“传统 App”。而越来越像一个持续运行的状态系统十五、总结如果一句话总结鸿蒙 PC 构建体系从 DevEco 到发布本质上是在组织“系统运行结构”。很多人以为构建 编译代码其实真正发生的是状态能力组织 Runtime 装配 Workspace 构建这已经不是传统页面工程而是系统级 Runtime 工程真正成熟的鸿蒙 PC 构建体系一定具备Runtime 分层Workspace 中心化HAR 领域隔离Task Runtime 独立状态边界清晰分布式能力解耦因为未来真正复杂的 不是“页面” 而是“持续运行的状态系统”最终你会发现DevEco 不只是一个 IDE。而是鸿蒙状态系统的“运行时装配中心”。
