鸿蒙开发入门指南一文了解HAP、HAR、HSP应用程序包基础知识一、先理解最核心的一句话二、HAP的两种类型entry和feature三、共享包的两种形式HAR和HSP3.1 HAR静态共享包3.2 HSP动态共享包四、一张图看懂三者的关系五、模块化设计从“能用”到“好用”5.1 为什么需要模块化5.2 UIAbility应用的任务单元六、实际项目怎么选四种场景一次讲清楚场景一简单应用一个HAP就够了场景二单HAP 按需加载场景三多HAP 各自独立场景四多HAP 公共能力共享七、重要提醒多HAP引用相同HAR的坑问题场景实际测试数据解决方案八、实战在DevEco Studio里创建一个HAP九、新手最常问的三个问题Q1我写一个小应用需要搞懂这些吗Q2什么时候需要用HARQ3什么时候用HSP而不是HAR十、总结一张表记住所有概念结语写给正在读这篇文章的你大家好我是木斯佳。很多刚接触鸿蒙的朋友打开官方文档看到“应用程序包概述”这一章往往就被绕晕了HAP、HAR、HSP、entry、feature、模块化设计……这些概念到底有什么区别我写代码的时候到底该用哪个别慌。今天这篇文章我就用跨界开发者的视角帮你把这些概念一次性理清楚。文章有点长但保证你看完就能懂懂了就能用。一、先理解最核心的一句话一个鸿蒙应用 一个或多个HAP包就这么简单。就像我们写前端项目一个项目可能包含多个页面、多个组件最后打包成一个dist目录。鸿蒙也是一样只不过它把每个功能模块打包成一个叫HAP的东西。HAP是什么你可以把它理解为鸿蒙版的“页面模块包”。阅读下文前我希望你可以先把官网的应用程序包基础知识速读一下。二、HAP的两种类型entry和featureHAP分为两种记住这个类比就行类型前端类比作用entry首页 入口JS应用的主模块包含入口图标和核心功能feature路由懒加载的页面应用的动态特性模块按需加载通俗理解entry就像你网站的index.html是用户打开应用第一个看到的东西feature就像“个人中心页”、“设置页”需要的时候再加载约束条件记住这个面试可能会问一个应用在同一设备类型上最多只能有一个entry类型的HAPfeature类型的HAP可以有多个也可以没有三、共享包的两种形式HAR和HSP除了HAP还有两个概念叫HAR和HSP。它们都是“共享包”就像前端的npm包。类型前端类比特点HARnpm包静态引入每个用它的模块都会拷贝一份代码HSP共享模块动态加载多个模块共享同一份代码运行时只有一份3.1 HAR静态共享包HAR就像你npm install一个包然后在多个组件里import使用。每个组件都会把它的代码打包进自己的产物里。优点简单直接发布方便可以发到OHPM中心仓相当于npm官方仓库编译时可以利用ArkTS的语言特性做类型推断和优化无运行时加载成本缺点如果多个HAP都用同一个HAR那每个HAP里都会有一份HAR的代码包体积会变大3.2 HSP动态共享包HSP就是为了解决HAR的“重复拷贝”问题。多个HAP共享同一份HSP代码打包后只有一份。优点节省包体积缺点只能应用内共享不能发到公共仓库有额外的安装和加载性能损耗四、一张图看懂三者的关系┌─────────────────────────────────────┐ │ App Pack (应用包) │ ├─────────────────────────────────────┤ │ ┌─────────┐ ┌─────────┐ │ │ │ entry.hap│ │feature.hap│ │ │ └─────────┘ └─────────┘ │ │ ↓ ↓ │ │ ┌─────────┐ ┌─────────┐ │ │ │ HAR/HSP │ │ HAR/HSP │ │ ← 共享包被多个HAP引用 │ └─────────┘ └─────────┘ │ └─────────────────────────────────────┘核心结论HAP 应用的页面模块可以独立安装运行HAR/HSP 共享的代码库不能独立运行只能被HAP引用五、模块化设计从“能用”到“好用”理解了基础概念我们来看看模块化设计。这其实是所有大型应用的必修课。5.1 为什么需要模块化想象一下你写一个电商App有首页、商品详情、购物车、支付、订单、个人中心……如果所有代码都塞在一个文件里那维护起来就是灾难。模块化的好处多团队协作不同团队负责不同模块互不影响独立开发编译每个模块可以单独开发、测试按需加载用户用不到的模块可以不下载5.2 UIAbility应用的任务单元在鸿蒙里UIAbility是承载业务逻辑的组件。你可以把它理解为一个独立的任务窗口。什么时候需要多个UIAbility看看这些场景设备类型场景是否需要多UIAbility手机简单游戏❌ 单UIAbility就够了手机笔记应用想同时打开两页✅ 需要多UIAbility手机打车应用导航后台运行还能查其他位置✅ 需要多UIAbility大屏视频应用一边看视频一边浏览列表✅ 需要多UIAbility大屏邮件应用一边写邮件一边看收件箱✅ 需要多UIAbility结论如果你的应用需要多任务并行就需要多个UIAbility也就意味着需要多个HAP。六、实际项目怎么选四种场景一次讲清楚场景一简单应用一个HAP就够了适用小工具、简单游戏、Demo练习方案只用entry类型的HAP所有代码都放里面优点简单不用纠结选型场景二单HAP 按需加载适用功能较多但入口单一的应用。比如一个应用里有“拍照识图”这种低频功能。方案entry HAP HSP按需加载模块┌─────────────────────┐ │ entry.hap (主模块) │ ├─────────────────────┤ │ hsp_scan (扫码) │← 用户点的时候才下载 │ hsp_share (分享) │← 用户点的时候才下载 └─────────────────────┘优点首次安装包小用户体验好场景三多HAP 各自独立适用应用内有多个相对独立的功能模块比如一个办公应用包含“文档编辑”、“表格处理”、“演示文稿”。方案entry HAP 多个feature HAP┌─────────────────────┐ │ entry.hap (启动器) │ ├─────────────────────┤ │ feature_doc.hap │← 文档编辑模块 │ feature_sheet.hap │← 表格处理模块 │ feature_ppt.hap │← 演示文稿模块 └─────────────────────┘每个feature HAP可以独立安装、独立运行有自己的入口。场景四多HAP 公共能力共享适用多个HAP之间有共享代码网络库、工具类、UI组件库方案这时候就要考虑用HAR还是HSP了七、重要提醒多HAP引用相同HAR的坑这是很多开发者容易踩的坑我专门拿出来说一下。问题场景假设你有HAP_A 和 HAP_B两个HAP都引用了同一个 HAR_COMMON里面有个工具函数执行耗时操作问题HAR_COMMON 会被打包进两个HAP每个HAP都有一份独立拷贝。如果你的HAR里有单例模式或者有初始化逻辑它会在每个HAP里执行一次。实际测试数据官方做了一个测试在HAR_COMMON里放一个执行1亿次循环的函数然后对比两种方案方案启动耗时HAP_A HAP_B 都引用HAR_COMMON3125ms改成HAP_A引用HAR_COMMONHAP_B改成HAR包853.9ms差了3.7倍解决方案原则如果多个HAP/HSP引用同一个HAR而这个HAR里有初始化逻辑或单例尽量让它们通过HSP共享而不是各自拷贝。八、实战在DevEco Studio里创建一个HAP光看概念容易晕咱们动手创建一个试试打开DevEco Studio创建工程选择Empty Ability模板默认生成的就是一个entry类型的HAP如果想添加feature模块在项目名上右键 → New → Module选择模板时注意Module Type那里可以选择entry或feature就这么简单。九、新手最常问的三个问题Q1我写一个小应用需要搞懂这些吗不需要。如果你是写一个简单的Demo或者只有一个模块的小应用直接用entry类型的HAP就够了不需要管feature、HAR、HSP这些概念。Q2什么时候需要用HAR当你有多个模块都需要用同一套代码的时候。比如封装了一个网络请求库要在多个HAP里用写了一套UI组件库要在多个HAP里用公司内部的基础库不想重复写Q3什么时候用HSP而不是HAR当你的包体积太大或者多个HAP引用同一个库导致包体积膨胀的时候可以考虑把HAR改成HSP。但要注意HSP有性能损耗需要在“包体积”和“启动性能”之间做权衡。十、总结一张表记住所有概念包类型全称前端类比能否独立运行作用HAPHarmony Ability Package页面模块✅应用的安装运行单元└─ entry-首页✅应用入口唯一└─ feature-其他页面✅扩展功能可有多个HARHarmony Archivenpm包静态❌共享代码多份拷贝HSPHarmony Shared Package共享模块❌共享代码单份拷贝选型口诀简单应用只用entry HAP多模块无共享entry feature HAP多模块有共享考虑HAR性能优先或HSP体积优先公共库给多应用用只能用HAR结语写给正在读这篇文章的你写完这篇教程我想和你聊几句心里话。最近我在更新鸿蒙专栏的时候把市面上能找到的新手教程都看了一遍。说实话看得有点失望——太多教程其实是“复制粘贴”出来的。有的是直接把官方文档搬运过来稍加排版就变成了“原创”有的是用AI跑一遍示例代码连注释都没改就发了出来还有的是把官方案例demo换个标题就当实战教学了。我并不反对借助外力。AI是很好的助手官方文档是最好的参考书官方demo是最权威的范例。这些都是我们学习的利器我自己也在大量使用。但是如果只是把这些内容简单拼接不加思考、不消化吸收那写出来的东西永远只能是“知识的搬运工”而不是“技术的引路人”。就像今天讲的这些概念——HAP、HAR、HSP、模块化设计官方文档里都有洋洋洒洒几千字。但为什么很多人看了还是晕因为文档只告诉你“是什么”没告诉你“为什么”和“怎么用”。所以我花了一整天时间把这些概念重新梳理、重新组织。——希望不只是告诉你知识点而是帮你建立起做决策的能力。这只是一个开始。鸿蒙的世界很大需要学的东西还很多。未来的路我们慢慢走。如果你觉得这篇文章对你有帮助欢迎点赞、收藏、转发。也欢迎在评论区告诉我你还想了解鸿蒙的哪些内容。我是木斯佳下篇教程见。