鸿蒙NEXT开发【模块化设计】应用架构

ADgai1987

于 2024-09-18 20:24:11 发布

阅读量906

点赞数 26

分类专栏：鸿蒙开发实例文章标签： harmonyos 架构华为鸿蒙鸿蒙系统 ui 模块测试

本文链接：https://blog.csdn.net/ADgai1987/article/details/142342697

版权

鸿蒙开发实例专栏收录该内容

67 篇文章 0 订阅

订阅专栏

模块化设计理念

在大型软件工程中，一般会伴随着多团队开发，而各个团队之间，都是弱耦合交互，团队交付的业务之间以一种契约化形式的接口，定义了业务之间的接口，以此来满足各个团队的业务独立发展，互不影响，实现快速迭代演进，这就需要业务模块化。模块化是现代软件工程的核心原则之一，它通过将大型的复杂系统拆解为更小、更容易管理和理解的部分——功能模块，来提高系统的可维护性和可拓展性。每个功能模块都是一个独立的单元，具有清晰定义的接口和职责，能够与其他模块交互以完成复杂的任务。

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

应用程序包结构概念

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

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模块。

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

[共享模块]：某个功能模块（业务模块或者能力模块）需要在多个应用之间共享其代码逻辑和资源。
[按需加载模块]：某个功能模块，使用时由用户决定安装时机，动态从应用市场下载安装使用。
[多HAP/HSP引用相同HAR包的影响]：从性能角度出发，需要减少多HAP/HSP对相同HAR包的引用。

共享模块

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

图1 多工程合作模式

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

按需加载模块

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

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

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

如果某个特性做成了按需加载模块，该模块可以设计为Feature类型的HAP或者HSP，HAP和HSP都可以实现按需加载，区别在于Feature类型的HAP可以包含Ability组件，结合前面的[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/HSP引用相同HAR包的影响

在应用开发的过程中，可以使用[HSP]或[HAR]的共享包方式将同类的模块进行整合，用于实现多个模块或多个工程间共享ArkUI组件、资源等相关代码。

由于共享包的动态和静态差异，在多HAP/HSP引用相同HAR包的情况下，会存在HAR包中的单例失效，从而影响到应用冷启动的性能。

图2 HAP包和HSP包分别引用相同HAR包

如上图所示，工程内存在三个模块，HAP包为应用主入口模块，HSP为应用主界面显示模块，HAR_COMMON集成了所有通用工具类，其中funcResult为func方法的执行结果。

由于HAP和HSP模块同时引用HAR_COMMON模块时会破坏HAR的单例模式，所以HAP和HSP模块使用HAR_COMMON中的funcResult时，会导致func方法在两个模块加载时各执行一次，使得文件执行时间耗时增长。

如果仅从性能的角度考虑，可以使用以下方式进行修改，从而达到缩短冷启动阶段耗时的目的。

图3 切换为HAP包和HAR包分别引用相同HAR包

说明

在多HAP/HSP引用相同HAR包的情况下，若HSP包和HAR包均能满足业务需求，建议将HSP包改成HAR包。
若使用的HSP为[集成态HSP]，可跳过该优化方案。

在被引用HAR_COMMON包中写入功能示例。

// har_common/src/main/ets/utils/Utils.etsconst LARGE_NUMBER = 100000000;function func(): number {  let count = 0;  while (count < LARGE_NUMBER) {    count++;  }  return count;}export let funcResult = func();

分别通过使用HSP包和HAR包来引用该HAR_COMMON包中的功能进行性能对比实验。

使用HAP包和HSP包引用该HAR_COMMON包中的功能。

HAP包引用HAR_COMMON包中的功能。

// entry/src/main/ets/pages/Index.etsimport { MainPage } from 'hsp_library';import { funcResult } from 'har_common';

HSP包引用HAR_COMMON包中的功能。

// hsp_library/src/main/ets/pages/MainPage.etsimport { funcResult } from 'har_common';

使用HAP包和HAR包引用该HAR_COMMON包中的功能。

HAP包引用HAR_COMMON包中的功能。

// entry/src/main/ets/pages/Index.etsimport { MainPage } from 'har_library';import { funcResult } from 'har_common';

HAR包引用HAR_COMMON包中的功能。

// har_library/src/main/ets/pages/MainPage.etsimport { funcResult } from 'har_common';

使用Launch模板，对优化前后启动性能进行对比分析。

分析阶段的起点为启动Ability（即H:void OHOS::AppExecFwk::MainThread::HandleLaunchAbility的开始点），阶段终点为应用第一次接到vsync（即H:ReceiveVsync dataCount:24Bytes now:timestamp expectedEnd:timestamp vsyncId:int的开始点）。

图4 优化前，使用HSP包

图5 优化后，使用HAR代替HSP

优化前后的对比数据如下：

方案	阶段时长(毫秒)
（优化前）使用HSP包	3125
（优化后）使用HAR代替HSP	853.9

说明

上述示例为凸显出差异，func执行函数循环次数为100000000，开发者实际修改后收益需根据实际情况测试。

从测试数据可以看出，将HSP替换为HAR包后，应用启动的阶段耗时明显缩短。

单HAP工程

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

不包含按需加载模块

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

说明

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

图6 非按需加载工程模型

上图工程架构中，除了产品模块层中与设备相关的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模块壳中，如下图所示：

图7 公共依赖模块通过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包：

图8 公共依赖模块使用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包，如下图所示：

图9 多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，如下图所示：

图10 多HAP工程模块示意图

说明

需要注意，在应用间共享的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最小化。