【HarmonyOS实战开发】鸿蒙中实现组件化通信解耦

1、前言

在鸿蒙项目初期开发中，我们的代码结构可能是这样，features功能模块目录中，涉及到所有功能模块都调用的功能，都放到【公共功能】har中。但是，随着功能的不断增加，和时间推移。这种结构可能会有以下几种问题。

1.公共功能har，代码臃肿，业务耦合严重，维护成本增加
2.公共功能har，功能无法拆分，假如有手机、手表、汽车三种产品。公共功能har中不同产品可能需3.要得功能也是不一样的。无法做到产品功能隔离
4.实现一个功能，还要去改动很多别人模块的代码？

修改某个历史功能，但不知不觉导致其他模块出现bug？

有没有方法能完全隔离各功能之间的业务模块，通讯之间通过一定协议规则来约束，业务部门开发过程中只专注自己的模块，从物理上杜绝跨业务修改代码？

2、组件化理解

组件化，去除模块间Module[har]的耦合，使得每个业务模块Module[har]可以独立当做App[通过hap壳工程引入]存在，对于其他模块没有直接的依赖关系。 此时业务模块就成为了业务组件。
除了业务组件，还有抽离出来的业务基础组件，是提供给业务组件使用，但不是独立的业务，例如分享组件、广告组件；还有基础组件，即单独的基础功能，与业务无关，例如 图片加载、网络请求等。

组件化带来的好处 ：

1提高协作效率：解耦 使得组件之间 彼此互不打扰，组件内部代码相关性极高。 团队中每个人有自己的责任组件，不会影响其他组件；降低团队成员熟悉项目的成本，只需熟悉责任组件即可；对测2试来说，只需重点测试改动的组件，而不是全盘回归测试。

2.功能重用：组件 类似我们引用的第三方库，只需维护好每个组件，一建引用集成即可。业务组件可上可下，灵活多变；而基础组件，为新业务随时集成提供了基础，减少重复开发和维护工作量。

下图是我们期望的组件化架构：

1.组件依赖关系上层依赖下层，修改频率上层高于下层。

2.基础组件是通用基础能力，修改频率极低，作为SDK可共公司所有项目集成使用。

3.module_common组件，作为支撑业务组件、业务基础组件的基础，同时依赖所有的基础组件，提供多数业务组件需要的基本功能，并且统一了基础组件的版本号。所以 业务组件、业务基础组件 所需的基础能力只需要依赖common组件即可获得。【组件化通信的核心就是common 组件】

4.业务组件、业务基础组件，都依赖common组件。但业务组件之间不存在依赖关系，业务基础组件之间不存在依赖关系。而 业务组件 是依赖所需的业务基础组件的，例如几乎所有业务组件都会依赖广告组件 来展示Banner广告、弹窗广告等。

3、 组件化开发的问题点

在深入探讨组件化的原则与策略之际，我们已然领悟到了组件化理念的核心所在，以及其所蕴含的优势与结构特性。在此之后，倘若我们欲将组件化的理念付诸实践，首要的任务便是清晰地界定我们需要解决的一系列挑战。

首要任务是确保业务组件的解耦性。解耦性，乃是构建一个健壯、可维护系统的关键。在此过程中，我们首先需识别可能存在的耦合形式，举例来说，即是页面间的导航跳