组件化框架调研和思考

1、百链 CC

核心代码量:3K(±) line (&插件)

源码阅读难度(10分制):8(Socket&ASM)

组件自动注册方案: 自动注册

TrasnformAPI + ASM扫描组件类(IComponent接口实现类)并注册到ComponentMananger中,

无需手动维护组件列表

模块间通信机制:

事件总线

组件间跨进程通信机制: Socket

广播 + Service + LocalSocket

组件向外提供服务: 自动注册

在IComponent中实现,自动注册到ComponentMananger

组件依赖隔离:

无需依赖、完全隔离

特点:

  1. 可以跨app调用,初期改造时即可单独编译组件运行
  2. 提供统一的组件调用及实现方式(不管是否跨app调用、页面跳转、服务调用、同步/异步调用)
  3. 组件自动注册,无需维护
  4. 提供了ActionProcessor按需加载的支持

综合成本:中

 侵入性低 
 无混淆
 改造成本中  
 学习成本低  
 维护成本中 

缺点:

 1、使用Socket实现组件间通信,逻辑略复杂,且只支持string
 2、Socket未使用NIO,只能一对一通信
 3、组件与非组件状态下通信机制不统一
 4、无法自动唤醒目标,目标组件被杀后无法通信

2、得到 DDComponentForAndroid 现更名为JIMU

核心代码量:1.2K(±) line (&插件)

源码阅读难度:5(Javassisit)

组件自动注册方案: 自动注册

apt生成各module的路由表

TrasnformAPI + javassist将IApplicationLike的注册代码生成到自定义application.onCreate方法中,

无需手动维护组件列表

模块间通信机制:

路由 + 接口下沉

组件间跨进程通信机制:

不支持

组件向外提供服务: 手动注册

接口下沉到base中,组件中实现接口并在IApplicationLike中手动注册到Router中

组件依赖隔离:

通过插件实现只在打apk包时才添加依赖,编码期间不能直接调用其它组件的代码

特点:

自动添加依赖,只在运行assemble任务的才会添加依赖,因此在开发期间组件之间是完全感知不到的,这是做到完全隔离的关键
支持两种语法:module或者groupId:artifactId:version(@aar),前者之间引用module工程,后者使用maven中已经发布的aar

  1. 编码期间组件依赖通过插件进行隔离,避免直接调用其它组件的代码
  2. 提供了兼容ARouter的方案
  3. 组件自动注册,无需维护

综合成本:中

 侵入性一般
 混淆所有下沉接口、框架中相关接口的实现类等 
 改造成本一般  
 学习成本一般  
 维护成本一般

缺点:

 1、不支持组件间的跨进程通信,这个期望后续能有进展
 2、javassisit经常会占用代码资源无法释放,导致编译失败(mac下不会,wins下经常,无解)
 3、组件与组件联合测试时需要集成打包到一起,而不是两个独立的组件通信

3、58赶集 ModularizationArchitecture

核心代码量:2K(±) line

源码阅读难度:7(AIDL)

组件自动注册方案: 手动注册

1. Action列表在其所属的Provider中注册
2. Provider在其所属的ApplicationLogic中注册
3. ApplicationLogic在主app的Application中注册

模块间通信机制:

 事件总线

组件间跨进程通信机制: AIDL

组件同时安装在设备上即可,实际开发中一般是当前正在开发的组件和主app中的组件互相调用.

组件向外提供服务: 手动注册

实现一个对应的Action并在其所属的Provider中手动注册

组件依赖隔离:

无需依赖、完全隔离

特点:

  1. 可以跨app、app内跨进程调用
  2. 组件运行在各自进程中,单独运行与联合打包切换时需要修改进程名称
  3. 组件需指定同步实现还是异步实现,调用组件时统一拿到RouterResponse作为返回值,可以自行决定同步还是异步方式调用RouterResponse.getData()来获取结果,但异步获取时需要自己维护线程

综合成本:高

 侵入性高
 混淆所有下沉接口、框架中相关接口的实现类等 
 改造成本高 
 学习成本高 
 维护成本高

缺点:

 1、使用AIDL实现组件间通信,逻辑略复杂
 2、组件与非组件状态下通信机制不统一

4、阿里Arouter

组件自动注册方案: 半自动+反射

   1. apt生成各module的路由表
   2. Arouter初始化时扫描所有dex找出指定包名下的路由表,通过反射进行统一注册

模块间通信机制:

路由 + 接口下沉

组件间跨进程通信机制:

urlScheme来统一转发

组件向外提供服务: 反射

接口继承IProvider并下沉到base中,组件中实现接口并通过注解来暴露服务

组件依赖隔离:

未隔离

特点:

 1. 阿里出品,使用者众多,QQ群里交流比较活跃
 2. 自动注册插件正式启用之前扫描所有dex完成注册的方式效率较低且有加固厂商兼容性问题
 3. 分级按需加载

综合成本:一般

 侵入性高
 混淆框架中的所有类及框架相关接口的实现类
 改造成本一般
 学习成本一般 
 维护成本低

5、美团

组件自动注册方案: SPI+javassit

        1. 使用servieloader进行解耦---非显式的调用服务实现类
        2. javassit预处理:大体流程是
            在build的某个阶段拿到所有编译后的class文件(夹)和jar包。
            使用javassit确定哪些类被@autoService修饰,配置文件中如果不存在,在其添加。
            查看serviceConfig配置文件里面的格式是不是正确。
            通过javassit来确定serviceConfig配置文件里面的类是不是在项目中存在,接口类是不是实现了Iprovider接口。

模块间通信机制:

     LocalBroadcast取代eventbus

组件间跨进程通信机制:

     contentProvider

组件向外提供服务: 反射

     接口继承IProvider并下沉到base中,组件中实现接口并通过注解来暴露服务

组件依赖隔离:

     无需依赖、完全隔离

特点:

      1. 解耦使用serviceloader,而不是路由进行
      2. 可以无侵入式的配置各种服务
      3. lib快速便捷多端使用

综合成本:高

      侵入性低
      混淆框架中的所有类及框架相关接口的实现类
      改造成本高
      学习成本高
      维护成本高

6、其它

聚美Router

APT+反射

51信用卡路由方案OkDeepLink

使用aspectJ来实现路由表的自动注册

美柚路由方案RouterKit

通过apt生成每个module的路由表,然后复制到app的assets目录,
运行的时候遍历asset目录,反射对应的activity

7、思考总结

1、组件自动注册方案:

现有APT实现的Router  只需要完成中央注册即可
可选方案复杂度:10分制
        javassisit   7
        ASM           8
        SPI              0
        AspectJ     9
        反射           6

2、组件间通信方案:

 可选方案复杂度:
   ContentProvider   7
   Socket         8
   AIDL             7
   Messenger  3
 
 由于现在的组建内通信方案OkBus  传递的是Message  
 
 进程间通信可以使用Messenger(IPC)来扩展OkBus实现组建间的Message的双向传递  几乎0成本

8、最终实现 Moduler

原理篇: https://www.jianshu.com/p/a73fd5e4cad1

核心代码量:1K(±) line

源码阅读难度(10分制):3(Messenger)

组件自动注册方案: 自动注册

 APT+SPI

模块间通信机制:

 OkBus

组件间跨进程通信机制: Messenger扩展的 OkBus

 OkBus

组件向外提供服务: 自动注册

 OkBus+SPI

组件依赖隔离:

无需依赖、完全隔离

特点:按需加载,自动唤醒

1、最小代价组件化,最简单的配置、最灵活的切换
 2、组件路由自动化注册,中央路由自动化采集
3、服务自动注册,兼容同异步,兼容跨/同进程,经典C/S架 构,一对多通信
4、OkBus实现的通信机制,兼容同异步,兼容跨/同进程,与传统使用方式完全一样,无感知无差别
5、跨组件调用时自动唤醒,单个组件调试时无需手动打开目标组件,即使目标开启后被杀掉进程,同样可以唤醒加通信一步到位

跨进程的优点

 考虑到,a,b两个模块同时修改,联合调试时,编译过程比较麻烦,因此,所有的组件化框架都不建议开发阶段使用aar,而建议直接依赖

 而跨进程通信则完全没有这个烦恼,两个组件单独安装即可,不存在任何依赖

 前者的时间复杂度是2+2  后者的时间复杂度是1+1


 开发初期,多个模块联合改动,分别测试时,使用aar时间成本是指数增长,使用跨进程只是简单的线性增长。

 真正复杂的流程也不是组件化之后的开发过程,而是组件化过程中拆分的各个组件时联合测试的过程,所以一般组件化的过程都会分为两个阶段,组件化开发期,和组件化稳定期

  目前的demo给出的解决方案就是组件化开发期的解决方案,稳定之后,会有后续的aar依赖优化方案

综合成本:低

 侵入性低 
 无混淆
 改造成本低  
 学习成本低  
 维护成本低 

QQ群:AndroidMVP 555343041

参考&致谢:

总结一波安卓组件化开源方案

美团猫眼电影android模块化实战

推荐阅读更多精彩内容