前言：单一工程架构遇到的问题
在组件化架构之前，传统使用的工程架构主要是以Monolithic方式的单一工程架构，也就是将所有代码放在单个代码仓库里管理。单一工程架构使用了这么多年为什么突然遇到了问题，这也引入了APP项目开发的一个大背景，现有中大型APP项目变的越来越复杂：
多APP项目并存- 集团内部存在多个APP项目，不同APP希望可以复用现有组件能力快速搭建出新的APP。功能增多- 随着项目功能越来越多，代码量增多。同时需要更多的开发人员参与到项目中，这会增加开发团队之间协作的成本。多语言/多技术栈- 引入了更多的新技术，例如使用一种以上的跨平台UI技术用于快速交付业务，不同的编程语言、音视频、跨平台框架，增加了整个工程的复杂度。
以上这些业务发展的诉求就给传统单一工程架构方式带来了很多新的技术要求
一、组件化可以带来什么
工程效率
- 工程代码量过大会导致
编译速度缓慢。 - 单
git工程提交同时可能带来更多的git提交冲突和编译错误。
质量问题
- 如何将
git提交关联到对应的功能模块需求。发版时进行合规检查避免带入不规范的代码，对整个功能模块回滚的诉求。 - 如何在单仓库中管控这么多开发人员的代码权限，尽可能避免不安全的提交并且限制改动范围。
更大范围的组件复用
- 基础组件从支持
单个APP复用到支持多个APP复用。 - 不只是
基础能力组件，对于业务能力组件也需要支持复用。（例如一个页面组件同时在多个APP使用） 跨平台容器需要复用底层组件能力避免重复开发，同时不同跨平台容器API需要尽量保持统一，底层基础设施向容器化发展支持业务跨APP复用。
跨技术栈通信
- 由于页面导航多技术栈混合共存，页面路由需要支持跨技术栈。
跨组件通信需要支持跨语言/跨技术栈通信。
更好的解耦
-
页面解耦。由于页面导航栈混合共存，页面自身不再清晰的知道上游和下游页面由什么技术栈搭建，所以页面路由需要做到
完全解耦隔离技术栈的具体实现。 -
业务组件间维持松耦合关系，可以灵活
添加/移除，基于现有组件能力快速搭建出不同的APP。 -
对于同一个服务或页面可以插件化方式灵活提供多种不同的实现，不同的APP宿主也可以提供不同的实现并且提供
A/B能力。 -
由于
包体积限制和不同组件包含相同符号导致的符号冲突问题，在复用组件的时候需要尽可能引入最小依赖原则降低接入成本。
二、组件化拆分原则
区分组件间的界限。
基础组件- 如果不需要依赖业务公共层那应当划分为一个基础组件。业务组件- 依赖了业务公共层或者网络库，那就应该划分为一个业务组件。 业务组件不能相互依赖，但是可以依赖基础组件，比如Foundation、UIKit。 基础组件拆分原则：基础组件通常根据职责单一原则进行拆分比较容易拆分，但是会有一些拆分场景需要考虑。
使用分层思想拆分：
通常我们可以首先使用分层架构的思想将所有组件纵向拆分为多层组件，上面层级的组件只能依赖下面层级的组件。一般至少可以划分为四层组件：
基础层- 提供核心的与上层业务无关的基础能力。可以被上层组件直接依赖使用。业务公共层- 主要包含页面路由、公共UI组件、跨组件通信以及服务接口，可被上层组件直接依赖使用。业务实现层- 业务核心实现层，包含原生页面、跨平台容器、业务服务实现。组件间不能直接依赖，只能通过调用页面路由或跨组件通信组件进行使用。APP宿主层- 主要包含APP主工程、启动流程、页面路由注册、服务注册、SDK参数初始化等组件，用于构建打包生成相应的APP。
划分层级可以很好的指导我们进行组件拆分。在拆分组件时我们需要先识别它应该在哪一层，它应该以哪种调用方式被其他组件使用，新添加的功能是否会产生反向依赖，帮助我们规范组件间的依赖关系。同时按层级拆分组件也有利于底层基础组件的复用。
三、注意点
在组件发布时添加一个安全检查，避免不符合依赖规范的组件发布成功。通常我们可以添加以下依赖检查规则：
- 第三方库不可依赖其他组件
- 基础组件不可依赖业务组件
- 业务组件不可直接依赖业务组件
- 组件间通常不可相互依赖
- 不允许组件层级间反向依赖
四、额外成本
组件化架构可能会带来以下这些额外的成本：
- 管理更多的组件
git仓库 - 每次组件发布都需要重新编译/发布
- 由于组件使用方都是使用相应的组件二进制库，所以调试源码会变的更困难
- 开发组件管理平台，管理组件版本、版本配置表等能力
- 每个组件需要有自己的
Example工程进行日常开发调试 - 处理可能存在的组件版本不一致导致的依赖冲突、编译错误等问题
- 需求可能会涉及到多组件改动，如何进行
Code Review、版本合入检查
