【HarmonyOS Next】鸿蒙中App、HAP、HAR、HSP概念详解
对于任何鸿蒙应用开发者来说App、HAP、HAR、HSP这四个概念是绕不开的基础也是构建一个结构清晰、性能优异的鸿蒙应用的基石。简单来说它们的关系可以这样理解App是最终上架和安装在用户手机上的完整应用而HAP、HAR和HSP则是组成这个 App 的、不同角色和性质的“积木块”。下面我将为你逐一拆解。一、App Pack最终呈现在用户面前的形态App Pack应用程序包就是我们通常意义上所说的“应用安装包”。当开发完成后需要将应用上架到华为应用市场时所有编译产物HAP、HSP等会统一打包成一个以.app为后缀的文件这个文件就是 App Pack。关键特性发布形态它是应用发布和分发的最终格式只用于上架应用市场。不可直接安装.app文件并不能直接发给用户安装到设备上它需要经过应用市场的解析和处理。内部包含一个 App Pack 内部包含了应用所需的一个或多个 HAP 包以及 HSP 包。在开发过程中App更像一个“容器”或“项目”的概念代表你正在开发的整个应用。二、HAP应用运行的基本单元HAPHarmony Ability Package是应用安装和运行的基本单元。一个 App 可以包含一个或多个 HAP。HAP 包是代码、资源、第三方库和配置文件的集合体。根据功能和角色HAP 分为两种类型1. Entry 类型 HAP定义应用的主模块是应用的入口。作用它包含了应用启动图标、应用的基础和核心功能。特性一个应用中对同一种设备类型必须有且仅有一个 Entry 类型的 HAP。它具备独立安装运行的能力。2. Feature 类型 HAP定义应用的动态特性模块用于扩展应用的能力。作用用于承载应用的附加功能如支付模块、直播模块、特定活动页面等。特性一个应用可以包含零个或多个 Feature 类型的 HAP。Feature HAP 最大的特点是可按需安装。通过在module.json5文件中将deliveryWithInstall设置为false该模块便不会在应用首次安装时下载而是当用户需要使用时例如点击某个功能入口才从应用市场动态加载从而达到为应用“瘦身”的目的。三、HAR 与 HSP代码复用的两种方式在开发过程中我们通常会抽取公共代码或组件以便复用。HarmonyOS 提供了两种共享包HAR静态共享包和 HSP动态共享包。它们的核心区别在于复用时机和对包大小的影响。1. HARHarmony Archive静态共享包HAR 是静态共享包可以理解为代码和资源的“拷贝粘贴”式复用。工作机制当模块 A 引用了 HAR 包在编译时这个 HAR 包中的代码和资源会被完整地复制一份到模块 A 的编译产物HAP 或 HSP中。如果模块 B 也引用了同一个 HAR那么同样的副本也会被打包进模块 B。优点由于代码在编译时就已集成所以运行时的加载效率非常高无需额外开销。缺点如果多个模块引用同一个 HAR会导致应用包体积显著增大代码冗余。适用场景发布到公共仓库作为二方库公司内部 OHPM 私仓或三方库OHPM 中心仓供其他应用使用。基础工具库比如网络请求封装、通用工具函数、UI 组件库等如果它们只被一两个模块引用使用 HAR 是最佳选择因为它效率最高且没有动态加载的复杂性。2. HSPHarmony Shared Package动态共享包HSP 是动态共享包实现了代码和资源的“运行时共享”。工作机制无论有多少个模块HAP 或 HSP引用了同一个 HSP在打包时这个 HSP 只会保留一份。在运行时所有引用它的模块共享这唯一的一份代码和资源实例内存中也只存在一份。优点能有效减小应用最终的包体积并节省运行时内存。缺点动态加载会带来一些性能开销查找、加载、初始化。不支持独立发布必须随宿主应用HAP一起打包和安装。不能声明 UIAbility 或 ExtensionAbility 组件。适用场景多模块共享的公共能力当一个公共模块如登录组件、分享组件被多个 HAP 或 HSP 引用时使用 HSP 可以避免代码冗余是优化包体积的最佳选择。按需加载的大功能模块虽然 HAP 支持按需加载但如果你有一个内部功能模块不能独立运行只是一个功能集也需要按需加载HSP 是更好的选择。总结与选择指南为了更直观地对比这里汇总了一张表格特性维度HAPHARHSP全称Harmony Ability PackageHarmony ArchiveHarmony Shared Package核心角色应用的功能模块静态共享包动态共享包复用方式独立存在编译时拷贝多副本运行时共享单实例能否独立安装运行是(Entry/Feature)否否可包含UIAbility是否否可包含 pages 页面是是(通过命名路由)是对应用包大小影响基础大小增大(多引用会膨胀)减小(避免重复)典型使用场景应用入口、核心功能、按需加载特性基础工具库、公司内部/公开的SDK被多个模块共享的公共UI组件、业务逻辑信息综合自如何选择核心建议HAP 的选择Entry HAP每个项目都必须有。Feature HAP当一个功能模块非常大或者你希望它具备独立的按需分发能力例如只有部分用户或特定设备才需要使用且该功能可以独立运行有自己的 Ability 入口那么选择 Feature HAP。HAR vs. HSP 的选择优先考虑 HAR对于大多数情况下的代码复用尤其是工具类、数据模型、纯逻辑组件以及需要发布到 OHPM 仓库供他人使用的库应该优先选择 HAR。它的实现简单调试方便且加载效率最高。考虑使用 HSP当一个公共模块被多个 HAP/HSP 频繁引用并且你非常在意应用包体积时应该使用 HSP。一个典型的例子是当你的应用采用了多 HAP 架构并且这些 HAP 都需要引用同一个登录或支付页面时HSP 是唯一的正确选择。