项目组件化实践

一、项目演进

混沌项目 -> 模块化 -> 组件化

• 混沌项目：所有代码在一个主工程中，仅仅做了分包。
• 模块化：项目按业务拆分多个module，但是各module之间耦合严重。
• 组件化：对模块化的module进一步分层，根据分层确定依赖规则，优化模块化混乱耦合的局面，使各模块间相对独立。

二、组件化描述

2.1 组件形式：

• module 工程模块
• project 独立项目

2.2 分层：

• business 具体业务
• sdk 通用业务能力
• lib 通用库能力
• base 基础库能力

视业务复杂度看是否在business和sdk之间抽个loft层，作为通用业务封装和通信辅助层。

2.3 组件化优势：

• 模块独立：提升编译速度、提高开发效率、降低维护成本、提升测试效率。
• 拓展性好：方便组件的新增和删除，也为项目内部组件的插件化提供环境。

2.4 组件化要解决的问题：

• 独立调试
• 解耦
• 解耦之后组件间的跳转与通信

三、组件化实践

结合自己的工作，来简单整理下项目组件化实践。

3.1 独立调试

独立project肯定不需要考虑调试问题，这里主要是指module的组件形式。需要独立编译的module：gradle中 apply plugin: ‘com.android.library’ 改为apply plugin: ‘com.android.application'，另外需要配置一个能启动系统组件的AndroidMainfest.xml。为了方便修改，可以在gradle.properties配置开关来切换调试模式。

示例：
动态配置组件类型、ApplicationId和AndroidManifest

//gradle.properties 配置统一调试开关
isModule = false
//build.gradle
if (isModule.toBoolean()){
    apply plugin: 'com.android.application'
}else {
    apply plugin: 'com.android.library'
}
//build.gradle (XX module)
android {
...
    defaultConfig {
...
        if (isModule.toBoolean()) {
            // 独立调试时添加 applicationId ，集成调试时移除
            applicationId "包名"
        }
...
    }
    sourceSets {
        main {
            // 独立调试与集成调试时使用不同的 AndroidManifest.xml 文件
            if (isModule.toBoolean()) {
                manifest.srcFile 'src/main/moduleManifest/AndroidManifest.xml'
            } else {
                manifest.srcFile 'src/main/AndroidManifest.xml'
            }
        }
    }
...
}

3.2 解耦

解耦主要就是组件分层，上级可以依赖下级但不跨级依赖，平级之间不互相依赖, 通用功能需要提取则在两层之间抽取loft层，一般来说business可能会抽取通用业务组件作为loft。

基础组件分层改造

1）基础能力库
主要提供整个项目通用的工具、Base页面等等，它自身无任何依赖，因此放在base层。通用型sdk和lib不依赖于Base-Core,方便托管maven成为独立库。

2）网络库(Okhttp)
多个终端项目，下沉一个通用的Base-Network，满足基础网络请求能力，包括：通用请求配置设置、通用请求参数封装、通用响应数据解析等的支持。Lib层梳理出差异化的Lib-Network，主要包括通用业务请求类型封装、网络请求加密策略（不同终端有差异因此放到lib层）等。Base-Network自身可以托管maven。

3）图片库(Glide)、插件化库(RePlugin)、热修复库(Tinker)
这仨算一个类型，放一块说。Glide自身默认使用HttpURLConnection作为网络获取图片方案,这里直接可以使用Base-Network来统一提供网络请求能力。而插件化库、热修复库这两个框架因为都需要下发插件，所以也可以统一依赖Base-Network。真实场景是：图片库、插件化库、热修复库都会作为maven托管，提供终端通用能力，如果各自维护一套网络请求方案显然还是不合理。

4）播放框架
播放框架做了一次大的重构，将之前冗杂的播控功能进行组件化拆分：

• Lib-CorePlayer:支持播放的系统库和三方库。向上统一提供基础播放能力。
• Sdk-PlayerFramework: 播控中心，封装view的基础控制功能以及封装player的基础播放功能
• Loft-Live 、Loft-Vod：分别封装直播和点播两大通用业务。分别实现对应的播控，以及个性化能力。因为是通用型业务，因此这里增加了个Loft层，理解为common business。

3.3 跳转

通过组件分层与依赖限制最大程度已经实现了组件解耦，那接下的问题是，不相互依赖的组件间如何进行跳转和通信 ？
1）Intent隐式跳转

• action跳转

<intent-filter>
   <action android:name=“XXX" />
   <category android:name="android.intent.category.DEFAULT" />
</intent-filter>

intent.setAction(action);
startActivity(intent);

• uri跳转

<intent-filter>
   <action android:name=“XXX" />
   <category android:name="android.intent.category.DEFAULT" />
   <data
       android:host="channel"
       android:path="/channel_page"
       android:scheme=“XXX"></data>
</intent-filter>

intent.setData(Uri.parse(scheme + "://" + host + path));
startActivity(intent);

2)路由 Arouter

3.4 通信

如果组件化分层足够合理的话，需要互相通信的组件大部分都处于上面的业务层，通信方式：或通过Loft层建立依赖关系来注册观察者，或实在不行就发本地广播。