HarmonyOS 鸿蒙Next 模块化哪种方案比较好

发布于 1周前 作者 wuwangju 来自 鸿蒙OS

HarmonyOS 鸿蒙Next 模块化哪种方案比较好 我试过以下几种方案：

  1. 多hap，每个feature模块都是一个单独的hap，每个模块都有自己的uiability，但是这样的话有个问题，uiability跳转会在最近任务列表中出现，而且如果要想一起运行需要勾选mutil Hap

  2. 多har，每个feature模块都是一个单独的har，但是这样模块里面不能注册pages，所有的pages需要注册到entry模块，类似于codelabs里面的商城那个项目，开发起来比较反人类。

  3. 多hsp，每个feature模块都是一个单独的hsp，每个模块可以有各自的pages，但是我发现hsp模块必须放在根目录下，如果我想通过文件夹来区分app架构层级就实现不了。比如这样，运行的时候就识别不到文件夹里面的会报错（也可能是我用法问题？），而且如果要想一起运行需要勾选mutil Hap，我理解这个hsp也是个hap？只不过是个纯代码的hap

请问大佬们哪种方案好，该怎么设计呢


更多关于HarmonyOS 鸿蒙Next 模块化哪种方案比较好的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html

Harmonyos Next教程
9 回复

HAP不支持打包成库来使用，怎么搞工程解耦呢

更多关于HarmonyOS 鸿蒙Next 模块化哪种方案比较好的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


复杂的项目，比如组件化架构的话，使用多hap+多hsp

单一依赖模块，比如整个应用内只有一个地方引用登录模块，登录模块就可以作为hap

多引用模块，比如自己封装的网络请求框架，多个模块都需要引用，使用hsp，避免使用har导致包体过大

然后就是各个模块之间通过路由跳转页面，组合应用

个人见解

另外我想问下har存在的意义是什么？har能做的，有什么hsp做不到的吗？

har能对外使用，类似jar/aar但奇葩的是har不能有page，而hsp设计上是强于har，但用法就很恶心只能对内，对外就得提供源码，

求问为什么不能对外使用？hsp中的是源码，给别人就会暴露源码？

请问一下，如果hsp作为网络请求封装，如何回传数据给HAP呢？

可以用多hap模式，每个模块使用一个feature，然后用router导航，链接写成

@bundle:<bundleName>/<moduleName>/<页面相对路径，以Main文件夹为起点> 模式

个人觉得第一种好点。

同问，在一个大型项目中分很多模块分属不同功能，按需加载。

比如我们不管是什么项目，主模块只加载“启动页面和主页Tab框架”，将“登录+用户管理”作为单独的模块。另外的商城、CRM，工单等模块是分开的，按需加载。

刚学，遇到个问题，请问大神解决了模块间 page 互相跳转的问题了吗？暂时不知姿势怎么不对，也没找到文档说明。如下：

主模块 怎么 跳转到 login 模块，代码 error.code = 16000001

cke_13447.png

同时，在Tab 主框架分别加在的shop模块page，shop里的page 居然不能互相

router.pushUrl 跳转了。

如图：如果运行主模块entry时，TabPage 使用 login 模块的组件 LoginPage，router.pushUrl 无法跳转到ForgetPwdPage。运行 login 模块，因为两个page 在同一模块下可以跳转。

router.pushUrl({
            url: 'pages/password/ForgetPwdPage',
            params: null
          }

cke_26057.png

我尝试过看看对你有没有帮助
如果是page push page 需要@bundle/包名/模块名/路径 具体可以看下文档
如果是ability跳转ability 就用Want
需要在运行的时候勾选Muti hap，

针对HarmonyOS鸿蒙Next的模块化方案选择，以下提供几种常见的方案概述，每种方案都有其特点和适用场景：

  1. 微内核方案：此方案强调系统的安全性和模块化。通过微内核设计，可以实现各模块间的低耦合，提高系统的稳定性和可维护性。同时，微内核设计有助于提升系统的响应速度和效率。

  2. 组件化方案：组件化方案将系统拆分为多个独立的组件，每个组件可以独立开发、测试和部署。这种方案提高了系统的可扩展性和灵活性，便于快速迭代和更新。

  3. 服务化方案：服务化方案将系统功能以服务的形式提供，各服务之间通过接口进行通信。这种方案有助于实现系统的松耦合和高内聚，同时提高了系统的可重用性和可扩展性。

  4. 模块化框架方案：模块化框架方案提供了一个统一的框架来管理和协调各个模块。这种方案有助于实现模块间的有序协作和高效管理，同时降低了系统的复杂度和开发成本。

在选择模块化方案时，需要根据HarmonyOS鸿蒙Next的具体需求和目标进行权衡。考虑系统的安全性、稳定性、可扩展性、灵活性以及开发成本等因素，选择最适合的方案。

如果问题依旧没法解决请联系官网客服，官网地址是：https://www.itying.com/category-93-b0.html，

回到顶部