组件化方案调研

组件化方案调研

组件化概念

组件化就是将一个app分成多个Module，如下图，每个Module都是一个组件(也可以是一个基础库供组件依赖)，开发的过程中我们可以单独调试部分组件，组件间不需要互相依赖，但可以相互调用，最终发布的时候所有组件以lib的形式被主app工程依赖并打包成一个apk。

1.png

模块化、插件化和组件化的关系

对于这三者的关系：有不同的说法。
截取一些，以供参考，其实虽然每个人都有每个的不通过的理解和说法，但是内涵其实是一样的。

模块化与组件化

1. 得到（张明庆）

   在技术开发领域，模块化是指分拆代码，即当我们的代码特别臃肿的时候，用模块化将代码分而治之、解耦分层。具体到 android 领域，模块化的具体实施方法分为插件化和组件化。

2. 《 Java 应用架构设计：模块化模式与 OSGi 》一书中对它的定义是：模块化是一种处理复杂系统分解为更好的可管理模块的方式。

3. 《安居客》（张磊）组件和模块做个区别定义

   • 组件：指的是单一的功能组件，如地图组件（MapSDK）、支付组件（AnjukePay）、路由组件（Router）等等；
   • 模块：指的是独立的业务模块，如新房模块（NewHouseModule）、二手房模块（SecondHouseModule）、即时通讯模块（InstantMessagingModule）等等；模块相对于组件来说粒度更大。

综上所述，模块化与组件化都是对于一个整体功能的封装，只不过粒度不一样。我们本文中所指的组件化，和上述3中提到的模块化是一致的。

插件化与组件化

1. 一套完整的插件化或组件化都必须能够实现单独调试、集成编译、数据传输、UI 跳转、生命周期和代码边界这六大功能。

2. 插件化和组件化最重要而且是唯一的区别的就是：插件化可以动态增加和修改线上的模块，组件化的动态能力相对较弱，只能对线上已有模块进行动态的加载和卸载，不能新增和修改。

3. 插件化让我们的App的运行的时候能够动态的进行组装，就像我们使用chrome的插件一样，非常的方便，甚至演变到后期，插件化越来越像［虚拟机］发展，使用一个类似［boot］的壳，就可以像Java虚拟机加载Java文件一样加载一个App。插件化主要涉及对系统加载dex的依赖，所以适配起来坑比较多。

4. 组件化可以说和插件化有异曲同工之妙，只不过插件化是在［运行时］，而组件化是在［编译时］。换句话说，插件化是基于多APK的，而组件化本质上还是只有一个APK。编译一个大型App的时间时间很长，可能2，3分钟都不够.［组件化］ 就可以很好的解决这样的问题，此外，由于整个App的各个业务被分离了，所以它们之间的耦合度也就被降低了，各个业务线可以由专门的开发同学进行开发，相互之间也不会有干扰，提升开发效率

组件化详细方案

代码组件之间解耦

按照业务逻辑划分模块,对于一般app来说，可以分为三层。

1. 基础库（比如网络库，数据库，utils，图片加载库）
2. 基础模块，但是没有独立运行调试的必要，一般只是当作com.android.library被别的独立模块引用（比如登陆模块，分享模块，视频播放模块）
3. 业务模块，可以进行单独编译，打包，测试（比如拍摄模块，搜索模块，视频流模块，小视频模块）

这三个层次只能向下依赖，比如3层依赖2层，2层依赖1层。每一层里面互相不能依赖。
这符合依赖倒置原则

业界模块划分的例子

• 安居客

  
  
  4.jpg

• 滴滴组件化的图

  
  
  3.jpg

• 微信

6.png

组件工程单独开发调试

先来看看Android组件化需要实现的目标。(什么是组件化构建？)

1. 项目模块能够单独启动测试
2. 能够根据需求引入或删除某些业务模块
3. 通过不同模块的组合，组成不同的App

对于第一点：Android是通过应用com.android.application或com.android.library来决定该模块是以App模式还是以Library模式构建。App模式和Library模式的最大区别就是，App能够启动，而Library不可以。所以如果我们的模块能独立启动的话，我们需要每次手动去改动模块的build.gradle文件。好一点的做法定义一个布尔值来判断是否处于debug模式，但是这里有个问题是，不是每个模块都能独立启动的。所以无论采用何种方案，都需要我们手动管理。

对于第二点：当我们开发好业务模块后，可能我们需要频繁的新增或删除某些业务模块。如果是这样的话，我们也是需要频繁手动修改App的build.gradle。

对于第三点：有时候，我们可能会在不同的App中引用相同的组件（例如：滴滴的普通版和企业版，普通版包含企业版的功能），这个时候，我们也不希望要频繁手动管理组件依赖，特别是在组件还可以独立运行的时候。

所以，在我们实践组件化的时候，最大的问题就是，我们需要频繁的手动build.gradle文件来管理组件应用的插件和App的依赖。

对于这一部分，主要的就是开发一个gradle插件，对工程进行自动化管理，避免人为切换导致的各种错误。

组件之间互相通信

由于组件之间完全解耦，互相无法直接进行调用，所以通过接口+实现的结构进行组件间的通信。每个组件声明自己提供的服务 Service API，这些 Service 都是一些接口，组件负责将这些 Service 实现并注册到一个统一的路由 Router 中去，如果要使用某个组件的功能，只需要向Router 请求这个 Service 的实现，具体的实现细节我们全然不关心，只要能返回我们需要的结果就可以了。在组件化架构设计图中 Common 组件就包含了路由服务组件，里面包括了每个组件的路由入口和跳转。

由于各个模块是严格划分解耦的，各个模块对与彼此的存在是完全不知道的，所以各个组件的互相通信就需要一个通用的协议来进行。于是引入了路由框架。

8.png

通过上图可以看到，我们在最基础的Common库中，创建了一个路由Router，中间有n个模块Module，这个Module实际上就是Android Studio中的module，这些Module都是Android Library Module，最上面的Module Main是可运行的Android Application Module。

这几个Module都引用了Common库，同时Main Module还引用了A、B、N这几个Module，经过这样的处理之后，所有的Module之间的相互调用就都消失了，耦合性降低，所有的通信统一都交给Router来处理分发，而注册工作则交由Main Module去进行初始化。这个架构思想其实和Binder的思想很类似，采用C/S模式，模块之间隔离，数据通过共享区域进行传递。模块与模块之间只暴露对外开放的Action，所以也具备面向接口编程思想。

图中的红色矩形代表的是行动Action，Action是具体的执行类，其内部的invoke方法是具体执行的代码逻辑。如果涉及到并发操作的话，可以在invoke方法内加入锁，或者直接在invoke方法上加上synchronized描述。

图中的黄色矩形代表的是供应商Provider，每个Provider中包含1个或多个Action，其内部的数据结构以HashMap来存储Action。首先HashMap查询的时间复杂度是O(1)，符合我们对调用速度上的要求，其次，由于我们是统一进行注册，所以在写入时并不存在并发线程并发问题，在读取时，并发问题则交由Action的invoke去具体处理。在每一个Module内都会有1个或多个供应商Provider（如果不包含Provider，那么这个Module将无法为其他Module提供服务）。

途中蓝色矩形代表的是路由Router，每个Router中包含多个Provider，其内部的数据结构也是以HashMap来存储Provider，原理也和Provider是一样的。之所以用了两次HashMap，有两点原因，一个是因为这样做，不容易导致Action的重名，另一个是因为在注册的时候，只注册Provider会减少注册代码，更易读。并且由于HashMap的查询时间复杂度是O(1)，所以两次查找不会浪费太多时间。当查找不到对应Action的时候，Router会生成一个ErrorAction，会告之调用者没有找到对应的Action，由调用者来决定接下来如何处理。

一次请求流程
通过Router调用的具体流程是这样的:

9.png

任意代码创建一个RouterRequest，包含Provider和Action信息，向Router进行请求。
Router接到请求，通过RouterRequest的Provider信息，在内部的HashMap中查找对应的Provider。
Provider接到请求，在内部的HashMap中查找到对应的Action信息。
Action调用invoke方法。
返回invoke方法生成的ActionResult。
将Result封装成RouterResponse，返回给调用者。
上述描述，引用：Android架构思考

这只是一个原理性的描述，不同的开源框架具体实现细节可能不同，想了解具体实现细节，可以研究一下开源路由代码。

开源框架实现：

• WMRouter（美团方案）
• ARouter（阿里方案）
• Andromeda（支持跨进程）
• DDComponentForAndroid（得到方案）
• ModularizationArchitecture(支持跨进程)

UI 跳转问题

可以说 UI 跳转也是组件间通信的一种，但是属于比较特殊的数据传递。不过一般 UI 跳转基本都会单独处理，一般通过短链的方式来跳转到具体的 Activity。每个组件可以注册自己所能处理的短链的 Scheme 和 Host，并定义传输数据的格式，然后注册到统一的 Router 中，Router 通过 Scheme 和 Host 的匹配关系负责分发路由。但目前比较主流的做法是通过在每个 Activity 上添加注解，然后通过 APT 形成具体的逻辑代码。

目前开源的框架有：

• ARouter 框架，通过注解方式进行页面跳转，阿里出品
• ActivityRouter
• WMRouter 美团开源框架
• DeepLinkDispatch

资源冲突

• 对于多个 Bussines Module 中资源名冲突的问题，可以通过在 build.gradle 定义前缀的方式解决：

defaultConfig {
   ...
   resourcePrefix "new_house_"
   ...
}

• 多个mainfest问题
  每个可以独立运行的组件，都需要自己独立的mainfest，根据组件是否是独立运行，配置不同的Manifest路径

sourceSets {
    main {
        if (isDebug.toBoolean()) {
            manifest.srcFile 'src/debug/AndroidManifest.xml'
        } else {
            manifest.srcFile 'src/release/AndroidManifest.xml'
        }
    }
}

组件加载

• 多个application的问题
  可以尝试用两种方式

  • 字节码插入模式是在dex生成之前，扫描所有的ApplicationLike类（其有一个共同的父类），然后通过javassist在主项目的Application.onCreate()中插入调用ApplicationLike.onCreate()的代码。这样就相当于每个组件在application启动的时候就加载起来了。

  • 反射调用的方式是手动在Application.onCreate()中或者在其他合适的时机手动通过反射的方式来调用ApplicationLike.onCreate()。之所以提供这种方式原因有两个：对代码进行扫描和插入会增加编译的时间，特别在debug的时候会影响效率，并且这种模式对Instant Run支持不好；另一个原因是可以更灵活的控制加载或者卸载时机。

对于1，2方案，具体可以查看得到（DDComponentForAndroid）方案中的实现。

业内一些组件化开源方案

• 得到方案(DDComponentForAndroid)
• CC(ComponentCaller)，渐进式组件方案
• ModularizationArchitecture
• Atlas（阿里方案）

可行性（组件化与****项目如何结合）

综上所述，组件化是一个系统性工程，需要从编译，代码结构，通信框架，打包，测试等各个环节进行重构。
对于已有的app来说，采用渐进式的组件化是比较稳妥地方式。
下面针对****进行一些分析，将****中的module库进行一个划分

• 基础库

    baseAppInfoLib
    common-lib-net
  

• 功能库

    sohuUpload
    downloadsdk
    sohuMediaPlayerSdk
    sohuMediaPlayerLib
    sohuDanmuLib
    scaleview 
    sohuVideoEditor 
    sohuPrivilegeLib
  

• 组件库

    qianliyanlib
    sohuVideoMobile
    fivesixapp
  

短期规划

目前拍摄模块(qianliyanlib)相对独立，先从拍摄模块进行解耦

首先与拍摄模块有直接耦合关系的是上传视频组件，上传视频组件中，耦合了一部分视频转码的状态展示。
可以考虑先将拍摄模块与上传模块先行进行组件化。两个模块中的状态互相依赖，则通过注册各自模块提供的service进行接口编程方式实现。

后期如果有新的需求，并且是比较大的功能模块，那么就直接用组件模式进行开发。

通过这个组件化后，整个拍摄模块与上传模块，就可以单独调试与运行，在解耦过程中，逐步探索组件化的一些细节。为后期整体app组件化积累经验。

后期规划

可以按照功能模块进行划分如下：

1. 红包模块
2. 搜索模块
3. 商场订单模块
4. 首页框架模块
5. 小视频播放模块（包含列表与详情）
6. 视频信息流模块（包含首页tab，热点tab，订阅流，包含流播放，视频详情中播放）
7. 个人中心模块

参考资料

http://blog.spinytech.com/2016/12/28/android_modularization/

https://github.com/luckybilly/AndroidComponentizeLibs

https://mp.weixin.qq.com/s/6Q818XA5FaHd7jJMFBG60w

http://blog.zhaiyifan.cn/2016/10/20/android-new-project-from-0-p11/

https://mp.weixin.qq.com/s/6Q818XA5FaHd7jJMFBG60w

http://zjutkz.net/2016/10/07/%E5%85%B3%E4%BA%8EAndroid%E4%B8%9A%E5%8A%A1%E7%BB%84%E4%BB%B6%E5%8C%96%E7%9A%84%E4%B8%80%E4%BA%9B%E6%80%9D%E8%80%83/

http://www.trinea.cn/android/didi-internationalization-android-evolution/

http://tangpj.com/2018/07/22/calces-componentization/