客户端组件化技术方案

一、解决方案：组件化

1、 极大提高工程编译速度

进行组件化拆分后，每个业务或者功能都是一个单独的工程，这个单独的工程可以独立编译运行。
拆分后的工程通常都比较小，代码量也比较少，我再也不用像以前编译一下得等待半个小时了。

2、业务模块解耦，有利于多人团队协作开发

业务组件之间不能相互引用，每个组件都把对应的业务功能收敛在一个工程里，彼此互不打扰。
在多人团队里，每个人只负责自己的业务模块，他对业务功能的增删改查，都只限定在自己的这个业务模块里，不会影响其他人的业务，他代码质量的好坏也只会影响到自己的业务模块；
对测试来说，也十分方便，大部分情况下，我们只需要着重测试修改过的业务组件即可，而不用老是进行全部回归测试。

3、组件化是功能重用的基石

业务组件类似一个个积木一样，我们可以用积木搭建出不同的房子，同理我们也可以创建多个不同的APP（东芝、布谷、集团事业部都能直接使用）。
我们只需要维护好每个组件，需要用到该组件的功能时，一建引用集成就可以了。

4、安全

独立的组件，可以交付给独立的团队（外包）负责开发，该团队也不需要拿到整个工程的代码。

组件化的缺点：

组件化落地要花费更多的时间来进行模块拆分；

一个人的小项目完全没必要组件化开发，那样只会给自己带来更多的工作量；

组件化可能会带来更多重复的代码；

组件化需要良好的架构设计，包括怎么拆分业务，组件之间怎么通信等等，需要有个高水平的架构师统筹全局，经验不足的同学盲目进行组件化反而会适得其反，带来更多的麻烦；

二、组件化架构

说明：

1、整个App分为4层：Base（基础功能层）、Service（解决方案服务层）、Business（业务模块层）、App（壳App层）

2、Base层按照功能的不同，提供基础的功能库。包括：日志组件、图片管理组件、网络请求组件、工具集组件等。

3、Service层按照解决方案的不同，提供各种服务能力库。包括：二维码扫码组件、消息推送组件、分享组件等。

4、Business层按照业务模块划分，提供App表现的各个业务能力。包括登录、电商、食谱、首页等。

5、顶层的App此时就是一个简单的壳，承载着各个业务组件。

6、各个组件之间通过Base.Core这个核心组件来通信。它提供了各种松耦合的能力：

EventBus：用观察者模式来解耦事件通信

ServiceLoader：解耦接口的实现和使用

LifeCycler：解耦组件启动初始化和前后台切换

DOFRouter：解耦组件间UI跳转

7、每个组件都是一个独立的工程，放到独立的git上管理。

8、组件统一发布到私有maven库，组件间的依赖通过gradle implementation来引用

三、组件化落地方案

如果在项目没有一开始就采用组件化方案，那美居App如何才能完美的做好组件化落地方案呢？

经过充分的探讨和尝试，组件化落地方案有了具体的执行步骤：

1、搭建核心base层基础组件：base.log、base.core、base.http、base.image等，创造完整的解耦条件。

2、按照业务模块划分，在项目工程上，先把业务代码抽离成独立的模块。

3、解耦业务模块的底层组件依赖，按照蚂蚁搬家的方式，把业务模块依赖的代码抽离到它适合的组件中。

4、底层组件解耦完后，抽离到独立的git目录，并发布到maven仓库。

5、业务组件抽离到独立的git目录，并发布到maven仓库。

6、App壳工程顺利解耦，并切换到完全组件化状态。

四、组件化开发注意事项

1、资源文件冲突

为了防止各个组件之间资源文件冲突，推荐对每个组件的资源文件进行统一前缀命名。

在组件中，通过build.gradle配置来规范命名：

2、依赖库版本统一管理

为了统一管理各个依赖库，我们提供了统一的config.gradle：

工程中的引入方式是：

1、gradle.properties中增加：

CONFIG_URL=http://172.16.10.165:8888/repository/maven-releases/com/midea/base/core/config/0.0.20/config-0.0.20.gradle

2、工程的build.gradle中增加：

3、使用：

implementation “com.midea.service:location:$service_location_version”

3、maven库上传管理

各个组件放在我们自己的maven私服上，引入方式：

4、AppLike

AppLike的产生是为了解耦组件初始化，避免在Application的Oncreate或者其他方法中加入代码。

实现原理才用apt生成自动化代码的方式来实现。

使用如下：

1、继承默认适配器类DefaultAppLike

2、记得加@AppLifeCycle

3、build.gradle中记得加

kotlin:

kapt “com.midea.base.core:lifecycle-apt:$base_core_lifecycle_version”

java:

annotationProcessor “com.midea.base.core:lifecycle-apt:$base_core_lifecycle_version”

4、build完后，记得验证有没有自动构建出辅助类：

安卓组件化开发模式：

美居目前按照组件化为开发模式：

每个业务组件在各自的工程中独立开发，

base和service层组件提供各种服务，

最终通过美居App工程集成并打包发布，

所有的组件版本通过config url的方式来统一管理，避免各组件引用版本不一致的问题（第三方库或者组件）。

为了提高开发效率，避免重复发版，在开发过程中通常优先选择发布快照版本，比如：

business_config_version = “0.12.0-SNAPSHOT”
而当发布正式版本的时候，拉取release分支之后，通常需要重新发布一个正式版本的组件：

business_config_version = “0.12.1”
因此，当我们拉取release分支之后，需要增加一个额外的定版工作，让每个组件都切换到正式版本状态。

后续可以考虑采用自动发布来避免此项额外工作。

这里说明一下定版所需要的注意事项和步骤：

1、升级CONFIG_URL

config url位于base仓库的config模块，修改config.gradle脚本来升级对于的各组件的版本，并发布。

2、发布Base层新组件

只需要发布有修改的组件

各组件module升级到最新的config url，并删除掉根目录build.gradle对组件版本的临时修改。

3、发布Service层新组件

只需要发布有修改的组件

各组件module升级到最新的config url，并删除掉根目录build.gradle对组件版本的临时修改。

4、发布iot_common和midea_sdk组件

只需要发布有修改的组件，没修改就不发

各组件module升级到最新的config url，并删除掉根目录build.gradle对组件版本的临时修改。

5、发布Business层新组件

只需要发布有修改的组件

各组件module升级到最新的config url，并删除掉根目录build.gradle对组件版本的临时修改。