项目组件化实践

2021-01-27 本文已影响0人 Stan_Z

一、项目演进

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

混沌项目：所有代码在一个主工程中，仅仅做了分包。
模块化：项目按业务拆分多个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层建立依赖关系来注册观察者，或实在不行就发本地广播。