认识达内从这里开始

组件化编程开发我们在前几期的文章中已经给大家简单分享过一些应用方法了，今天我们就再来了解一下，组件化编程的优势与挑战都有哪些。

1、组件化架构的优势

基于以上这些问题，现在的组件化架构希望可以解决这些问题提升整个交付效率和交付质量。

组件化架构通常具备以下优点：

代码复用-功能封装成组件更容易复用到不同的项目中，直接复用可以提高开发效率。并且每个组件职责单一使用时会带入小的依赖。

降低理解复杂度-工程拆分为小组件以后，对于组件使用方我们只需要通过组件对外暴露的公开API去使用组件的功能，不需要理解它内部的具体实现。这样可以帮助我们更容易理解整个大的项目工程。

更好的解耦-在传统单一工程项目中，虽然我们可以使用设计模式或者编码规范来约束模块间的依赖关系，但是由于都存放在单一工程目录中缺少清晰的模块边界依然无法避免不健康的依赖关系。组件化以后可以明确定义需要对外暴露的能力，对于模块间的依赖关系我们可以进行强约束限制依赖，更好的做到解耦。对一个模块的添加和移除都会更容易，并且模块间的依赖关系更加清晰。

隔离技术栈-不同的组件可以使用不同的编程语言/技术栈，并且不用担心会影响到其他组件或主工程。例如在不同的组件内可以自由选择使用Kotlin或Swift，可以使用不同的跨平台框架，只需要通过规范的方式暴露出页面路由或者服务方法即可。

独立开发/维护/发布-大型项目通常有很多团队。在传统单一项目集成打包时可能会遇到代码提交/分支合并的冲突问题。组件化以后每个团队负责自己的组件，组件可以独立开发/维护/发布提升开发效率。

提高编译/构建速度-由于组件会提前编译发布成二进制库进行依赖使用，相比编译全部源代码可以节省大量的编译耗时。同时在日常组件开发时只需要编译少量依赖组件，相比单一工程可以减少大量的编译耗时和编译错误。

管控代码权限-通过组件化将代码拆分到不同组件git仓库中，我们可以更好的管控代码权限和限制代码变更范围。

管理版本变更-我们通常会使用CocoaPods/Gradle这类依赖管理工具来管理项目中所有的组件依赖。因为每一个组件都有一个明确的版本，这样我们可以通过对比APP不同版本打包时的组件依赖表很清晰的识别组件版本特性的变更，避免带入不合规的组件版本特性。并且在出现问题时也很方便通过配置表进行回滚撤回。

提示：组件化架构是为了解决单一工程架构开发中的问题。如果你的项目中也会遇到这些痛点，那可能就需要做组件化。

2、组件化遇到的挑战

虽然组件化架构可以带来这么多收益，但不是只要使用组件化架构就可以解决所有问题。通常来讲当我们使用一种新的技术方案解决现有问题的时候也会带来一些新的问题，组件化架构能带来多少收益主要取决于整个工程组件化的质量。那在组件化架构中我们如何去评估项目工程的组件化架构质量，我们需要关注哪些问题。对于软件架构来讲，重要的就是管理组件实体以及组件间的关系。

1.组件拆分的粒度、组件职责边界在哪里?

某种程度上组件拆分粒度也是一种平衡的艺术，我们需要在效率和质量之间找到一种相对的平衡。组件拆分粒度太粗：导致组件间耦合紧密，并不能利用更好的复用/解耦/提高编译速度这些优势。组件拆分粒度太细：导致需要维护更多的组件代码仓库、功能变更可能涉及多个组件代码的修改/发布，这些都会带来额外的成本，同时组件过多也会导致组件依赖查找过程变的更复杂更慢。

组件的职责也会影响我们对于组件的拆分方式：每个组件的定位是什么，应该包含什么样的功能，是否可以被复用，添加某个功能的时候应该创建新组件还是添加到现有组件，当组件复杂到一定程度时是否需要拆分出新个组件。

在拆分组件前需要提前去思考这些问题。

2.组件间的依赖关系应该如何管理?

组件间的依赖方式主要分为直接强耦合依赖和间接松耦合依赖。强耦合依赖是对依赖的组件直接使用对应的API进行调用，这种调用方式优点是简单直接性能更好，缺点是一种完全耦合的调用方式。(基础组件通常使用这种方式)。松耦合依赖主要是通过通知、URLScheme、ObjCRuntime、服务接口、事件队列等通信方式进行间接依赖调用。虽然性能相对差一点，但这是一种相对耦合程度比较低并且灵活的依赖方式。(业务组件通常使用这种方式)

组件间的依赖关系很重要是因为在长期的项目开发演化过程中很容易形成一种复杂的网状依赖关系。虽然看似使用组件化的方式将模块拆分成不同的组件，但是组件间可能存在很多相互交叉的依赖耦合关系，很多组件都被其他组件直接依赖或隐式间接依赖。这样我们就背离了组件化架构更好的解耦、更好的复用、更快速的开发/编译/发布的初衷。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。