本文最后更新于 1033 天前，其中的信息可能已经有所发展或是发生改变。
在公司也快三年了，感觉项目多了之后，基础库在很多项目里面都有用，每次新开项目都是 import 一下 基础库，导致当基础库代码有变化的时候。需要同步代码到很多的项目里面很麻烦。
而且好几个基础库还有互相耦合的问题 ，用起来很难受。
我只需要一个库里面的某个功能，结果一下引进来一堆库，所以决定把公司的项目进行组件化拆分。
组件化思路
- 基础模块和其他模块解耦，配置构建流程到私有源。确保每个单独项目通过远程依赖的方式引用基础模块，当基础模块有改动的时候，只需要每个 android sdk 项目重新构建即可
- 抽离业务组件对基础模块的调用逻辑，书写中间件，耦合逻辑降低至单一的中间件模块
- 根据业务组件抽离出业务基础组件，比如某个业务需要用到微信 sdk，那么微信 sdk 就属于业务基础组件的一部分，将微信 sdk 的调用封装好就是一个完整的业务基础组件。后续其他项目需要用到的话，就不需要考虑接入 微信 sdk 而是可以直接引入 业务基础组件
- 业务组件只需要专注于具体的业务逻辑
设计规范（个人理解）
- 项目组件化对设计模式的掌握需要有一定的水平
- 对公司业务的理解能力比较深，不然就会出现代码封装的很好，但是为了适应公司业务频繁改动，最后又反而破坏代码的封装，尤其是 业务基础组件 的封装。
- 对基础组件的封装必须有高质量的代码，基础组件之间避免耦合，避免频繁的修改。
- 所有对基础组件的调用都必须通过中间件，无论是基础组件之间互相调用还是业务组件对基础组件的调用都遵循这个约定。或许一开始写起来代码很冗余繁琐，但是对长远的多项目管理以及编码规范是很有好处的。
我是怎么做的
当我打算推进目前公司项目的组件化，那么第一步就是以自己的业务理解，把项目代码分类，重构代码。
基础组件：
- 网络请求组件
- 日志打印组件
- 基础信息组件（用来获取设备基础信息，以及当前应用的相关信息）
- 本地持久化组件
- 权限请求组件
- ui 寻址组件（游戏 sdk 一般不会用 R 文件的固定 id 去引用xml资源，所以会有寻址组件）
- H5 webview 渲染组件（其实 ui 渲染的不应该作为基础组件，但是webview 很多业务逻辑中都有，出于业务考虑，我这里将它分类到基础组件，增加可复用性，降低了拓展功能的便利性）
业务基础组件（这里只列举 sdk 行业内基本都有的业务举例）：
- 悬浮球组件
- 广告平台 ocpc SDK 组件
- loading 组件
业务基础组件其实我在进公司第二年的时候就抽离封装过一遍，但是没有基础组件的封装，导致其他项目用业务组件的时候还是很乱，很麻烦，要将基础代码全部拷贝一遍，后面就没维护了，所以组件化项目一定要对整个项目处理，而不是单一功能处理。
业务组件（实际业务很多，只是举例一下比较常见的）
- 用户协议与隐私政策组件
- 实名认证组件
- 手机绑定组件
- 强制更新组件
- 登录组件（含注册）
- 支付组件
根据自己的组件从基础组件开始把代码重构，中间件是整个环节中比较重要的部分，只要按照调用约定来书写中间件，其实也不难。根据项目大小以及业务复杂度，一个 游戏 SDK 项目的组件化大概要3个月，
基础组件和业务基础组件需要弄个私服传上去，给业务组件通过中间件使用，这样基础组件更新的时候，只用重新构建项目就可以更新代码
构建私有仓库我是参考这篇文章：https://www.jianshu.com/p/6954613c13ef
这个链接的搭建方式有点过时，我自己用 docker 搭建了一遍，有把搭建方法写在博客里