业内首个支持渐进式组件化的开源框架

前言

项目大了，编译慢了，开发效率低了，怎么办？ 也许你已经知道了组件化，但项目迭代任务紧张，根本没有时间进行总体解耦，更惧怕一会儿改动太大致使的风险不可控，不敢大改，怎么办？

先别急着放弃，渐进式组件化了解一下

背景故事

在实行组件化改造以前，咱们对业内的一些技术文章及开源库进行调研以后，发现基本上千篇一概地都是基于路由这种方案做为通讯引擎来实现组件化，重要的是组件化以前得先解耦原来的项目代码。很尴尬，咱们没那么人力和时间来一会儿作这么一大块事情。这时候咱们是这样想的：

• 可不能够先不解耦？

  这个问题问得好，但是...不先解耦，组件怎么单独以app运行呢？
  复制代码

• 新业务新module能够无耦合，总能够单独运行调试了吧？

  组件须要登陆怎么办？
    须要跟其它组件通讯怎么办？
  复制代码

• 用URLScheme来跨app通讯总能够了吧？

  页面跳转还行，虽然有个中转页面，仅在开发期间使用勉强也能接受
    但如何获取服务？那但是要查找接口的实现类，跨app调用时行吗？
  复制代码

• 将须要调用的业务代码一块儿打包总能够了吧？

  确实能够，但这些代码在哪里？主app module看一下？
    难不成要跟主app一块儿打包？没解耦的那些module要所有编译才行哦
  复制代码

• 那...有没有这样一种方案：让咱们能够当即就在新的业务上用组件化的形式进行开发（单组件module以apk的形式编译运行调试，而且能够与其它业务模块互相通讯），享受到组件化编译速度快、调试效率高的好处，又不须要立刻解耦项目，而是在迭代过程当中利用偶尔出现的碎片空闲时间来一个一个慢慢地解耦呢？

  好想法，这就是咱们想要的：当即组件化开发 & 渐进式组件化改造
    不过很遗憾，好像没有什么现成的方案可用。
    那咱们就本身设计一个吧！
  复制代码

正式因为项目代码耦合度高，解耦困难，并且迭代任务紧张，没办法单独抽出时间来解耦，致使组件化改造一直停留在口头上。

为了在不影响业务迭代业务开发的前提下也能用组件化的形式来进行开发，咱们设计了一个支持当即组件化开发 & 渐进式组件化改造的框架：CC（已开源，点这里看源码）

快速了解CC

• CC : Component Caller
• 是一套基于组件总线的组件化实施方案
• 一静一动，开发时运行2个app：
  • 静：主App (经过跨App的方式调用单组件App内的组件)
  • 动：正在开发中的单组件App (经过跨App的方式调用主App内的组件)
• 支持渐进式组件化改造
  • 解耦只是过程，而不是前提

用CC来当即开始组件化开发并渐进式地改造你的项目

先了解一下渐进式组件化改造的概念

以i百联App为例（上海百联集团旗下的一个电商App）来看一下组件化以前项目中存在的耦合状况：

• 先是一个启动页(Splash)，里面会有一些初始化、加载广告等业务，而后跳转到主页，广告可能跳转到商品详情页、用web模块打开H5活动页，存在很多耦合
• 主页中有：首页、分类、发现、购物车、个人等Fragment页面/业务模块，还要处理push等功能，也会存在很多耦合
• 首页中须要跳转到商品搜索，还有各类业务Fragment/业务模块，须要跳转商品详情、各类列表页、各类活动H5页面，耦合程度很是高
• 不少须要用户登陆的功能模块都须要耦合登陆模块
• 商品详情页、Web模块等模块几乎全部的业务模块都会用到，耦合程度不言而喻
• 百联到家、奥莱代购、分享、埋点、收银台、LBS、秒杀等等等等

最终项目的耦合状态是这个样子的(一个圆圈表明一个模块，圆圈交叉表明存在耦合状况)：

为了能让你们看得清楚，图片上仅仅列出了有限的几个模块，但即便是这样，咱们用一团乱麻来形容它也绝不为过。

咱们的工程师一直是在这样的环境下进行业务迭代开发和bug修复，改代码要当心翼翼，生怕引发其它逻辑出bug，最主要的是开发/调试效率很是低：在使用了maven的状况下，在15吋高配的macbook pro上编译运行每次都要花3-5分钟，在16GB内存的windows台式机上更是动辄10-15分钟，严重影响开发效率，组件化势在必行。

但业务迭代排期时间很是紧张，测试资源不足，咱们须要的是：当即组件化开发 & 渐进式组件化改造

在了解渐进式组件化改造以前，先来看看与之相对的非渐进式组件化改造

非渐进式的组件化方案要求咱们必须在组件化初期当即对项目进行解耦，至少是咱们须要被新业务调用到的组件须要解耦成组件，不然新业务组件脱离主app单独运行调试的时候没法正常工做。

在渐进式组件化的方案中，能够先不用解耦，只须要让单独运行的组件可以调用到主App中的功能便可。思路是这样的：

• 新业务以组件形式开发
• 新组件须要调用的主App中的业务，在对应的模块中建立一个组件类，对外暴露对应的服务，供其它组件调用，并不须要如今就将这个模块解耦
• 新组件经过跨App的方式调用主App中的组件
• 主App也能够经过跨App的方式调用到单独运行的组件App中的组件
• 在同一个module中能够建立多个组件类，未来解耦时将对应的组件类移动到解耦后的module中便可

旁白：

• 接入CC后，咱们的项目就已经组件化完成了
• 新业务：会员积分，以组件的形式进行开发：建立一个IComponent接口的实现类，对外暴露自身提供的服务，而且能够独立编译运行调试
• 会员积分组件须要用到登陆、订单和Web模块的功能
• 在登陆、订单、Web模块对应的module或包下建立对应的IComponent接口实现类，对外暴露自身的服务，让会员积分组件可以跨App调用到这些组件
• 此时若是咱们有时间，能够进行解耦，将相对比较容易解耦的登陆模块解耦出来，改形成一个组件
• 这时候又来了新业务：用户浏览记录，仍然以组件的方式开发
• 浏览记录组件须要能打开主App的商品详情页，在商品详情页对应的module或包下建立对应的IComponent接口实现类，对外暴露自身的服务，让浏览记录组件可以跨App调用到商品详情组件
• 其它的业务也能够用一样的方式来作
• 利用每一个迭代过程当中的出现的一些碎片空闲时间，将原来项目中的业务模块逐个从主App中解耦出去变成组件
• 若是遇到有些几个组件暂时没法彻底解耦，但若是做为一个总体能够解耦出来，就像动画中示例的商品详情和订单模块同样，能够将它们做为一个总体解耦出来（一个module，多个IComponent对应多个组件），等未来有时间了再继续拆分
• 持续地按照这个思路进行解耦，最终目标是将整个项目中的全部业务模块都解耦出来变成组件

CC是怎么作到这一点的？

首先，CC的核心通讯引擎采用的不是路由方案，而是组件总线方案（路由 vs 组件总线）

CC采有2套调用流程：App内部组件调用和跨App调用。

框架在接收到组件调用请求时，优先查看当前App内是否有本次CC调用指定的组件

• 有： 执行App内部组件调用流程
• 没有：检查当前app是否开启跨app调用功能：
  • 未开启： 返回-5的状态码，表明未找到指定的组件
  • 已开启： 执行跨App组件调用流程

采用组件总线的方案，在App内部调用组件时，等效于直接调用IComponent.onCall(cc)方法，将调用方设置的调用参数传递给组件，组件执行完以后将执行结果返回给调用方，这个过程当中没有使用反射，执行效率高

在这个过程当中，CC完成了一次调用请求的转发：查找到组件对象，并将调用其onCall方法，将调用参数发送给它，并将组件执行的结果返回给调用方

悄悄地告诉你：CC中自带3种AOP策略，例如动画中显示的CustomerInterceptors就是其中之二：全局拦截器和针对本次CC调用的拦截器。定义一个拦截器也很简单：实现IGlobalCCInterceptor接口便可

经过RemoteCCInterceptor与另外一个App的ComponentService创建链接，将CC中的调用参数传递给ComponentService，在ComponentService中使用这些参数，发起一个App内部的CC调用，最终经过LocalCCInterceptor调用到IComponent.onCall(cc)。

组件的执行结果原路返回给调用方

在这个过程当中，CC完成了2次调用请求转发：

• 跨App转发：将调用参数转发给另外一个App
• App内部转发：找到组件对象，调用其onCall方法将调用参数发送给它

能够看出，跨App调用时：

• 调用组件的代码与在App内部调用时彻底同样，无需任何改动
• 实现组件的代码IComponent.onCall(cc)方法也是在LocalCCInterceptor中调用，与在App内部调用时同样

总结

本文从咱们在实际实施组件化过程当中的一些思考入手，引入了渐进式组件化的概念，介绍了用CC来实现当即组件化开发 & 渐进式组件化改造的实施步骤。

并用动画的方式向你们展现了渐进式组件化与非渐进式组件化的区别以及支撑CC实现渐进式组件化的组件调用流程。

本文中的图片及动画取自上周末(6月9日)在爱奇艺移动技术沙龙分享时的演讲稿，PPT文档可在CC交流群(QQ群:686844583)的群文件中下载，欢迎加群交流。

点击这里了解关于CC的更多内容