【鸿蒙实战开发】har和hsp的转换

鸿蒙应用开发与共享包转换指南

一、场景描述

共享包选型: 应用模块化选型

伙伴开发过程中可能会遇到共享包转型场景,主要有hsp转har包和har转hsp包两种情况,由此经常要求提供har和hsp转换方案。共享包转换核心思路就是将配置文件统一,比如将hsp支持的配置文件转换为har的配置文件,主要涉及module.json5、hvigorfile.ts、build-profile.json5文件,以及路由方式切换等场景。

二、方案描述

场景一:hsp转har包

提供方hsp包转换

1.在hsp下的module.json5中,把"type": “shared"修改为"type”: “har”,删除"deliveryWithInstall"、"pages"字段。

2.由于har中不能声明page,需要先删除原hsp中module.json5的page声明;har不能用router.pushurl路由方式,需要修改原有router.pushurl路由为navigation(推荐)或命名路由跳转方式,以navigation为例,使用组件导航的demo如下:

左entry中Index页面,右har1中pageOne页面

若沿用router的方式,需要使用命名路由的方式,可参考官网指南: 命名路由

3.然后再找到hsp下的hvigorfile.ts文件,将里面的hspTasks改为harTasks。

4.(可选)如需要指定该library被依赖时的混淆规则(该项仅har模块可配置,详情可见 consumerFiles属性介绍 ,可在build-profile.json5添加配置"consumerFiles": ‘./consumer-rules.txt’ 。

5.清理重新安装打包(clean——>build)

引用方引用har包

转化前引用hsp包:

<think>嗯,用户这次询问的是鸿蒙系统中HARHSP的区别。看来用户对鸿蒙开发有一定了解,可能是开发者或技术决策者。此前用户询问过CentOS版本问题,说明ta对操作系统底层技术比较关注。 用户特意强调要参考站内引用,但当前问题与之前的CentOS话题无关,需要专注于鸿蒙生态的技术解析。鸿蒙的模块化设计是重点,HARHSP都是重要的代码共享机制,但定位不同。 先拆解核心差异点:HAR是静态共享包,类似Android的AAR,编译时直接打包进应用;HSP则是动态模块,支持运行时按需加载。这个根本区别会衍生出很多特性差异。 需要着重说明五个关键维度:代码复用方式(静态vs动态)、依赖关系(编译时绑定vs运行时发现)、资源隔离(共享vs独立)、包大小影响(增大应用体积vs按需加载)、适用场景。特别要强调HSP的资源隔离机制——这是鸿蒙多设备适配的重要优势。 用户可能真正关心的是如何选择。生产环境常用HSP实现热更新跨设备适配,但简单工具类用HAR更轻量。可以举例说明:比如相机功能模块用HSP便于不同设备加载不同实现,而日志工具类用HAR就够了。 要注意避免过于学术化的表述,用开发者能理解的类比:HAR像“复印文件”,HSP像“图书馆借书”。最后用表格对比会更清晰,但需确保移动端显示友好性。 用户没问但可能延伸的问题是版本管理调试差异,放在相关问题里比较合适。另外要提醒HSP对API版本有严格要求,这点容易踩坑。 </think>在鸿蒙系统(OpenHarmony/HarmonyOS开发中,**HARHarmony Ability Package)** **HSPHarmony Shared Package)** 是两种模块化共享机制,核心区别在于 **代码复用方式** **运行时行为**。以下是详细对比: --- ### 一、核心区别总结 | **特性** | **HAR(静态共享包)** | **HSP(动态共享包)** | |------------------|--------------------------------------|--------------------------------------| | **复用方式** | 静态绑定(编译时直接打包进应用) | 动态加载(运行时按需加载) | | **代码隔离** | 无隔离(复用代码与主应用合并) | 强隔离(独立进程/沙箱运行) | | **资源复用** | 资源合并到主应用,可能冲突 | 资源独立隔离,避免冲突 | | **包大小影响** | 增加主应用体积 | 按需加载,减小主应用体积 | | **适用场景** | 工具类、Utils 等无状态模块 | 多设备适配、复杂功能模块、热更新需求 | --- ### 二、详细解析 #### 1. **HAR(静态共享包)** - **工作原理** 将公共代码/资源编译为 `.har` 文件,**直接打包**到依赖它的应用中,编译后与主应用代码合并。 - **特点**: - ✅ **编译时绑定**:依赖关系在编译阶段确定。 - ❌ **无代码隔离**:复用代码与主应用运行在同一进程,全局变量可能冲突。 - ❌ **资源合并**:相同资源名会被主应用覆盖(需手动规避命名冲突)[^1]。 - **典型场景**: 工具函数库(如日期处理)、通用组件(无复杂状态)。 #### 2. **HSP(动态共享包)** - **工作原理** 编译为独立的 `.hsp` 文件,**不打包进主应用**,运行时通过动态加载机制按需调用。 - **特点**: - ✅ **运行时加载**:通过 `import()` 动态导入,减少主包体积。 - ✅ **强隔离性**:运行在独立线程或沙箱中,避免全局污染[^2]。 - ✅ **资源隔离**:每个 HSP 有独立资源路径,规避命名冲突。 - ✅ **跨设备适配**:可为不同设备(手机/手表)提供定制化实现(如 `phone.hsp`/`watch.hsp`)。 - **典型场景**: 多设备适配模块、热修复包、大型功能插件(如支付模块)。 --- ### 三、关键差异场景对比 #### 1. **资源冲突问题** ```typescript // HAR 中的资源引用(可能冲突) @Resource(R.string.app_name) // 若主应用有同名资源,会被覆盖 public title: string; // HSP 中的资源引用(安全隔离) const context = getContext(this); const appName = context.resourceManager.getString($r('app.string.app_name')); ``` #### 2. **动态加载示例(HSP)** ```typescript // 动态加载地图模块(HSP) import("com.example.mapmodule").then(module => { module.showMap(); // 运行时加载,未使用时无需包含 }); ``` #### 3. **多设备适配(HSP优势)** ``` 应用代码 ├── entry(主模块) └── shared ├── phone.hsp // 手机端实现 └── watch.hsp // 手表端实现 ``` 设备运行时自动加载匹配的 HSP 包,实现 **“一次开发,多端部署”**[^3]。 --- ### 四、如何选择? | **需求** | **推荐方案** | |------------------------|------------| | 小型工具类库 | ✅ HAR | | 大型功能模块/热更新 | ✅ HSP | | 多设备差异化实现 | ✅ HSP | | 避免资源/全局变量冲突 | ✅ HSP | > ⚠️ **注意**:HSP 需 API 9+ 支持,且对调试工具链要求更高[^2]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值