入口hap+多个特性hap+多个公共hsp才是合理架构吧 HarmonyOS 鸿蒙Next

入口hap+多个特性hap+多个公共hsp才是合理架构吧 HarmonyOS 鸿蒙Next 鸿蒙推荐的三层应用架构——产品定制层、基础特性层、公共能力层，我理解在实际工程层面分别对应单个entry+多个feature+多个share library(动态)。

公共能力层使用sharelibrary的原因是要被基础特性层的多个feature复用，如果用static library(静态)会导致代码重复复制问题，

所以公共能力层用share library实现会好一点，但我看开发者联盟的一些最佳实践案例，他们都是用static library实现公共能力层，也就是入口hap+多个特性hap+多个公共har的方式。我就搞不懂了。这样做有什么好处吗？


更多关于入口hap+多个特性hap+多个公共hsp才是合理架构吧 HarmonyOS 鸿蒙Next的实战教程也可以访问 https://www.itying.com/category-93-b0.html

5 回复

HAR和HSP的使用场景不同，最主要的差异是：

  1. HAR支持应用内共享，也可以发布后供其他应用使用。具体可查看：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V14/har-package-V14

  2. HSP不支持独立发布，而是跟随其宿主应用的APP包一起发布，与宿主应用同进程，具有相同的包名和生命周期。具体可查看：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V14/har-package-V14。

场景分析：

  • 场景1：如果一个公司有多个APP，都需要使用一个公共库，比如日志SDK、下载SDK等。

  • 架构方案：那么就需要这个公共组件，需要支持发布成一个公共组件，而且这个组件不会与某个具体的App绑定。此时，就应该是一个HAR，而不是一个HSP。

  • 场景2：一个APP是一个entry + 多个feature + 多个 hsp组成时

  • 架构方案：为避免同一个APP之中包含重复性的代码，比如feature和hsp都依赖于同一个HAR的情况。此时应该将公共的组件，存放于hsp之中。可仔细查看：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V14/application-package-structure-stage-V14。

    • 如果这个HAR希望对外发布，也要避免依赖于HSP组件；
    • 如果这个HAR不会对外发布，则可以依赖于HSP组件。

更多关于入口hap+多个特性hap+多个公共hsp才是合理架构吧 HarmonyOS 鸿蒙Next的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


这样看的话hsp的使用场景就有点局限了，使用hsp的时候最好只包括一些固定的长期不变的公共代码，还要时刻避免依赖其他har。感觉扩展性差一点，适合长期不更新的那种公共代码。

所以HSP被分成了两种：

  1. 应用内HSP：在编译过程中与应用包名（bundleName）强耦合，只能给某个特定的应用使用。

  2. 集成态HSP：构建、发布过程中，不与特定的应用包名耦合；使用时，工具链支持自动将集成态HSP的包名替换成宿主应用包名。

但两种应该都是不支持独立发布。

明白了。

在HarmonyOS鸿蒙Next中，合理的架构设计通常包括入口hap、多个特性hap和多个公共hsp。入口hap是应用的主模块，负责启动和基础功能；特性hap是独立的功能模块，可按需加载；公共hsp是共享资源库，供多个hap调用。这种架构支持模块化开发，提升代码复用性和系统灵活性。

回到顶部