鸿蒙HarmonyOS知识开发指南：模块化设计规范

在HarmonyOS应用开发中，模块化不仅是一个设计原则，更是一种开发实践。它旨在将应用程序拆分为多个功能模块，每个功能模块负责特定的功能或特性。功能模块可以独立开发、编译和部署，也可以在不同的设备上灵活组合和调用。

应用程序包结构概念

在进行模块化设计时，需要考虑HarmonyOS的应用包结构选型，HarmonyOS的应用包结构是为了定义应用的组织方式，通过开发态、编译态、发布态阶段应用程序包的形态，了解到不同包类型对应的使用场景以及使用规则。

Ability应用组件设计

HarmonyOS应用的业务逻辑需要通过Ability组件承载，根据业务设备以及业务诉求不同，需要考虑Ability组件的选择以及设计。在多设备的背景下，应用的形态不一定是传统移动设备上的单任务单窗口形式，在一些场景下，多任务多窗口的形态可以让用户获得更好的用户体验，提升使用效率。

例如在手机设备上：

笔记应用，可让用户将信息从笔记的一页复制到另一页。
文档编辑应用，可让用户同时打开编辑多个文档，可让用户将内容从一个文档复制或移动到另一个文档。
导航/打车应用，可以让导航后台运行，回到主页查找新的位置信息或其它信息。
购物类临时客服界面，可让用户通过任务管理快速从商品浏览页切换回到客服会话界面，避免用户一层层打开查找。
应用支付/登录页面，可以切换至应用内其它页面查找并复制相关信息。

在大屏设备上，应用内的多个任务可以以多窗口的形式存在，用户可以并行操作应用的不同功能。

视频播放器应用，可让用户在观看播放内容的同时浏览其他可能感兴趣的视频列表。
电子邮件应用，可让用户在撰写电子邮件的同时查看收到的邮件列表。
地址簿应用，可让用户并排比较多个人员的联系信息。
阅读应用，可让用户在查阅所有标题概要后，打开多篇文章供稍后阅读。

对于这种类似独立应用一样的任务，每个任务对应一个UIAbility组件实例，并且每个任务可以单独显示一个窗口，对用户而言，可以在同个应用不同任务间切换，就像是单独的应用一样，并且在大屏设备上可以独立地移动、调整大小、显示和隐藏应用窗口。所以在进行功能设计时，需要对应用本身是否支持多任务多窗口，结合起来考虑Ability组件的设计，这影响整体工程模块化的结构。

对于单Ability的情况下，可以对应单窗口类型应用，或者通过多实例/指定实例实现的多任务类应用，如上述例子中的笔记、文档编辑应用，这类情况下，建议采用单HAP来承载UIAbility。
对于多Ability有两种情况：
- 对于多窗口类型的应用，这类应用每个窗口对应不同的功能，通过不同的UIAbility承载，如上述例子中导航/打车应用，导航功能界面和主页属于不同的功能，并且要能够作为两个任务呈现给用户，可以将该模块作为Feature类型的HAP承载相应的UIAbility组件。
- 对于应用的一些拓展功能如卡片、分享业务，其不会作为单独的任务和窗口形态运行，但是由于其功能相对来说独立，并且是由系统提供的独立ExtensionAbility来承载，从更好拆分业务来考虑，也建议通过Feature类型的HAP承载单独的ExtensionAbility组件。

应用模块化选型

应用架构是给应用业务服务的，是从技术的角度思考业务如何实现的；而工程模块化模型，是基于技术架构对代码工程所做的模块化技术选型，需要考虑技术到代码工程上如何落地，只有代码工程模型的技术选型合理了，才能在包体积、性能、产品部署等取得一个最优的综合表现。

一般业务是分模块的，比如某购物软件，上面的业务就有主页导航、商品详情、购物车、支付、订单、个人信息等相关的模块；所以技术架构上，就会出现很多业务模块，模块之间是高内聚低耦合的，在代码工程上也就表现为模块（Module）。而在做代码工程模块化的技术选型上，因为Entry类型的HAP是工程默认存在的，且不能存在多个，所以主要考虑的就是几种模块类型：Feature类型的HAP模块，HAR模块和HSP模块。

在技术架构上的某个模块，做代码工程的选择时，是选择哪种模块类型，需要结合业务本身性质/模块的功能等因素综合考虑的。以基于应用常见的模块化模型，在实际的业务考虑中有两大模块：

共享模块：某个功能模块（业务模块或者能力模块）需要在多个应用之间共享其代码逻辑和资源。
按需加载模块：某个功能模块，使用时由用户决定安装时机，动态从应用市场下载安装使用。

共享模块

对于大型软件，不同的业务以及基础能力会分为多个团队开发，多团队之间需要代码仓隔离；如果某个或者若干个HAR工程模块是由某个团队负责开发的，又想代码仓隔离，可以将这些HAR单独在独立的工程内开发，将工程编译产物通过公司私有的OHPM仓进行发布和集成，如下图所示。

图1 多工程合作模式

这部分可以发布到OHPM仓的模块，叫做共享模块，可以将公共能力共享给多个应用使用，如公司内部多个应用使用某个公共能力网络库；或者也可以将该公共能力封装成库贡献给社区，给其他应用集成使用，这样的话这个模块也只能是HAR模块。

按需加载模块

随着应用业务扩大，应用给用户提供的功能越来越多，但是并非所有的功能都是用户常用的，根据用户运营报告分析，对于某些用户月活比较低的特性，可以将该特性做成按需加载模块。用户首次从应用市场安装时，仅会下载不包含按需加载模块的内容，需要使用到对应功能时，由用户选择使用时下载安装对应的功能模块。

设计为按需加载模块有以下好处：

减少包体积：用户从应用市场首次下载的应用不包含按需加载模块，用户看到的包体积减少，从而减少了用户下载和安装时间，减少了用户等待时间。
减少系统资源：应用安装之后所占用的空间也变少（节省ROM空间），应用启动时加载的特性少了（节省了RAM空间）。
架构演进：将特性定义为按需加载之后，对特性的定义和模块间的耦合关系进一步明确，有利于应用架构进一步演进。

如果某个特性做成了按需加载模块，该模块可以设计为Feature类型的HAP或者HSP，HAP和HSP都可以实现按需加载，区别在于Feature类型的HAP可以包含Ability组件，从整体上可以划分两个大的场景如下：

单HAP场景：如果只包含一个UIAbility组件（包括UIAbility多实例/指定实例），无需使用ExtensionAbility组件，优先采用单HAP（Entry类型的HAP）来实现应用开发，其中根据是否需要实现按需加载的来决定选择HSP或者HAR作为模块。
多HAP场景：要实现多任务承载多个UIAbility组件，以及需要使用ExtensionAbility组件实现拓展功能，可以采用多HAP（即一个Entry类型的HAP+多个Feature类型的HAP）来实现应用开发，每个HAP中包含一个UIAbility组件或者一个ExtensionAbility组件，多个HAP情况下，根据是否具有公共能力决定模块的选型。

应用组件的设计，决定了模块化设计中是单HAP工程还是多HAP工程，在设计初期需要考虑应用的任务形态，来决定采用何种模块化结构。

单HAP工程

对于单窗口应用的APP工程而言，其仅包含一个Entry类型的HAP，那么划分的模块则是根据是否有按需加载的需求，来考虑采用HAR模块和HSP模块。

不包含按需加载模块

对于不需要按需加载且仅有一个Entry类型的HAP的App来讲，可以直接全部采用HAR进行开发设计。如下图所示：

说明

这里说的仅有一个HAP指的是一种设备类型仅有一个HAP，而不是.app文件包里面仅有一个HAP。因为.app里面可以包含其他设备的HAP包，如手表、大屏，进行多设备分发。

图2 非按需加载工程模型

上图工程架构中，除了产品模块层中与设备相关的HAP外，其他的均为HAR，这些被依赖的HAR，最终都会被编译进HAP中。

设计成HAR包有如下好处：

全部编译进HAP，无额外的HSP，节省HSP的安装和加载成本。
HAR在编译进HAP时，可以利用ArkTS的语言特性和编译器功能，做类型推断和编译优化。
代码工程架构简单，后续演进较为灵活。

包含按需加载模块

在单HAP工程内，如果要实现按需加载功能，那么对应的组件需要采用HSP作为按需加载组件模块。在这种情况下，由于HAR是静态共享库，多个HAP/HSP如果依赖于同一份HAR，则该HAR在应用内会被存在多份。而HSP是动态共享库，其安装和加载均会有一些性能损失（相比于HAR），所以过多的HSP可能会影响安装效率和App启动性能，需要考虑目前App占用空间（App Size）是否瓶颈以及对启动性能的敏感程度，根据业务实际情况，在App Size与特性启动性能之间做好平衡。

说明

这里所提到的App Size指的是用户已经把按需加载模块安装之后，应用整体的大小。

App Size优先

对于App Size比较看重的，可以考虑将公共依赖的模块封装在一个HSP模块壳中，如下图所示：

图3 公共依赖模块通过HSP模块壳承载

hap_A依赖于独有的共享库har_A，同时需要依赖于har_C和har_D；而按需加载模块hsp_B依赖于独有的共享库har_B，同时需要依赖于har_C和har_D。

说明

这里的共享库har_A、har_B、har_C、har_D不一定本地工程，有可能是从ohpm仓上依赖下载的。

因为har_C和har_D同时被hap_A和hsp_B工程所依赖，所以为了节省App Size，可以将其封装到名为“common_hsp”的Module中，对外暴露har_C和har_D的接口，将har_C和har_D打包到common_hsp中，最后让hap_A和hsp_B依赖于common_hsp工程。common_hsp工程是无实际意义的，它仅是一个“模块壳”，是为了最小化App Size而存在的。

性能优先

对于性能比较敏感的，则不需要再封装一个公共的HSP模块，直接依赖公共HAR包：

图4 公共依赖模块使用HAR模块承载

因为公共HSP包需要安装和加载，所以会有一些性能损耗。对于启动性能敏感型的应用，则将hap_A和hsp_B直接依赖于har_C和har_D。最终编译产物里面有2个，hap_A.hap和hsp_B.hsp，但是这两个编译产物里面均会包含har_C和har_D，App Size会比采用公共HSP模型大。

多HAP工程

对于同一个设备类型，如果要实现不同的独立功能模块，且携带独立，且具有单独的入口的功能特性，建议做成一个独立特性的HAP，按需下载安装。此时一个App包中，就会有多个HAP包，其中有且仅有一个Entry类型的HAP，其他的均是Feature类型的HAP。多HAP之间业务独立，但是可能会有业务能力共享，所以在进行模块化设计时，需要根据是否具有公共能力来进行选择。

包含公共能力模块

对于具备公共能力模块的工程，和上述HAP+HSP组合是类似的，需要考虑在App Size与启动性能之间做平衡。

性能优先

一般多HAP应用架构普适性采用以下模型，除了产品组件中存在HAP包之外，其余的均是HAR包，如下图所示：

图5 多HAP工程模块示意图

从编译产物上看，多HAP之间是存在相同的HAR包的（如har_2、har_3、har_C、har_D、harE），这样App Size可能会比较大，对于App Size不是瓶颈点的应用，或者HAR包的大小比较小，对App Size的影响可控，可以采用这种模型，减少了动态加载的性能损耗。

App Size 优先

上述的重复HAR包，其本质的问题就是HAR包如何在HAP、HSP之间分布可以最小化App Size，减少HAR的重复编译打包，大的思路就是公共能力模块可以封装为公共HSP，最小化App Size，如下图所示：

图6 多HAP工程模块示意图

图7

说明

需要注意，在应用间共享的HAR包，原则上是不允许依赖HSP包，因为HSP包是专属于应用，和bundleName进行了绑定，一旦HAR包依赖于应用内HSP，该HAR包就丢失了共享性，无法再给其他应用共享。

如上图所示，有3个HAP包（一个entry和两个feature），将公共的HAR包封装到HSP工程中，如common_wrap_hsp和feature_wrap_hsp，这两个HSP从严格意义上讲，不能称之为模块，它们仅能称之为模块壳，是为合理放置模块在编译产物中的位置而存在的，本身不具备模块的意义，所以不能共享，仅能在App应用内使用，依赖于这些模块壳的模块也无法在应用间共享。

上述的模型中通过HSP将HAR包合理地分配到编译产物中，使每个HAR包在App编译产物中仅存在一份，从而达到App Size最小，而模块壳不能过多，否则可能会影响安装速度和启动性能。

这两种模型都是理想模型，更多的业务模型是两者的平衡态或者两种模型的组合体，比如某个共享库本身代码和资源比较少，占用的空间不大，例如打印日志模块，那么将该模块编译进所有的编译产物中，增大的App Size比较少，同时性能会相对好一些。

不包含公共能力模块

一般这种应用比较少，即使有的话也是一些小型应用，可以参考单HAP的场景。

总结

应用开发者需要根据自身技术架构选择适合的工程模块化模型，工程模块化模型也不是一成不变的，需要根据业务和技术架构的演进而演进。根据诉求在HAP、HAR和HSP三种类型中进行选择使用。

对于具备独立运行和安装的模块只能选择HAP包，并将其作为Feature类型的HAP存在于App中；对于不具备独立特性部分，用户使用频率较少的模块，将其做成HSP按需加载模块存在于App中。对于需要共享的模块，只能采用HAR包，将其通过OHPM仓共享给其他工程使用。而HAR是静态共享库，在多HAP或者按需加载场景下，在编译后可能会在物理上存在多份，所以需要合理采用公共HSP模块壳，使App Size最小化。

最后

有很多小伙伴不知道学习哪些鸿蒙开发技术？不知道需要重点掌握哪些鸿蒙应用开发知识点？而且学习时频繁踩坑，最终浪费大量时间。所以有一份实用的鸿蒙（HarmonyOS NEXT）资料用来跟着学习是非常有必要的。

点击领取→【纯血版鸿蒙全套最新学习资料】（安全链接，放心点击）希望这一份鸿蒙学习资料能够给大家带来帮助，有需要的小伙伴自行领取，限时开源，先到先得~无套路领取！！

这份鸿蒙（HarmonyOS NEXT）资料包含了鸿蒙开发必掌握的核心知识要点，内容包含了（ArkTS、ArkUI开发组件、Stage模型、多端部署、分布式应用开发、音频、视频、WebGL、OpenHarmony多媒体技术、Napi组件、OpenHarmony内核、（南向驱动、嵌入式等）鸿蒙项目实战等等）鸿蒙（HarmonyOS NEXT）技术知识点。

鸿蒙（HarmonyOS NEXT）最新学习路线