CC：基于总线的android组件化开发框架

时间  2019-11-05
标签 基于 总线 android 组件 开发 框架 栏目 主板 繁體版
原文   原文链接

*本篇文章已受权微信公众号 guolin_blog （郭霖）独家发布html

CC：Component Caller，一个android组件化开发框架， 已开源，github地址：github.com/luckybilly/… 本文主要讲解框架实现原理，若是只是想了解一下如何使用，可直接到github上查看README文档java

前言

首先说明一下，本文将讲述的组件化与业内的插件化（如：Atlas, RePlugin等）不是同一个概念android

组件化 vs 插件化
【图片来源于网络】

组件化开发：就是将一个app分红多个Module，每一个Module都是一个组件(也能够是一个基础库供组件依赖)，开发的过程当中咱们能够单独调试部分组件，组件间不须要互相依赖，但能够相互调用，最终发布的时候全部组件以lib的形式被主app工程依赖并打包成1个apk。git

插件化开发：和组件化开发略有不用，插件化开发时将整个app拆分红不少模块，这些模块包括一个宿主和多个插件，每一个模块都是一个apk（组件化的每一个模块是个lib），最终打包的时候将宿主apk和插件apk(或其余格式)分开或者联合打包。github

本文将主要就如下几个方面进行介绍：web

1、为何须要组件化？数据库

2、CC的功能介绍api

3、CC技术要点安全

4、CC执行流程详细解析服务器

5、使用方式介绍

6、老项目进行组件化改造的成本有多高？

1、为何须要组件化？

关于使用组件化的理由，上网能搜到不少，如业务隔离、单独以app运行能提升开发及调试效率等等这里就很少重复了，我补充一条：组件化以后，咱们能很容易地实现一些组件层面的AOP，例如：

  • 轻易实现页面数据(网络请求、I/O、数据库查询等)预加载的功能
  • 组件被调用时，进行页面跳转的同时异步执行这些耗时逻辑
  • 页面跳转并初始化完成后，再将这些提早加载好的数据展现出来
  • 在组件功能调用时进行登陆状态校验
  • 借助拦截器机制，能够动态给组件功能调用添加不一样的中间处理逻辑

2、CC的功能介绍

  1. 支持组件间相互调用（不仅是Activity跳转，支持任意指令的调用/回调）
  2. 支持组件调用与Activity、Fragment的生命周期关联
  3. 支持app间跨进程的组件调用(组件开发/调试时可单独做为app运行)
  • 在独立运行组件时很是有用，好比：一个组件的某个功能要用到用户的登陆信息，若未登陆则调起登陆组件的登陆页面，若已登陆则获取当前用户信息。此时能够直接使用主app中的登陆组件及用户在主app中的登陆状态，该组件做为app独立运行时无需依赖登陆组件，能够始终保持独立运行状态进行开发。
  1. 支持app间调用的开关及权限设置（知足不一样级别的安全需求，默认打开状态且不须要权限）
  2. 支持同步/异步方式调用
  3. 支持同步/异步方式实现组件
  4. 调用方式不受实现方式的限制（例如:能够异步调用另外一个组件的同步实现功能。注：不要在主线程同步调用耗时操做）
  5. 支持添加自定义拦截器（按添加的前后顺序执行）
  6. 支持超时设置
  7. 支持手动取消
  8. 编译时自动注册组件(IComponent)，无需手动维护组件注册表(使用ASM修改字节码的方式实现)
  9. 支持动态注册/反注册组件(IDynamicComponent)
  10. 支持组件间传递Fragment等非基础类型的对象（组件在同一个app内时支持、跨app传递非基础类型的对象暂不支持）
  11. 尽量的解决了使用姿式不正确致使的crash：
  • 组件调用处、回调处、组件实现处的crash所有在框架内部catch住
  • 同步返回或异步回调的CCResult对象必定不为null，避免空指针，同时能够根据CCResult的结果进行降级处理。

demo效果演示

组件A打包在主app中，组件B为单独运行的组件app，下图演示了在主app中调用二者的效果，并将结果以Json的格式显示在下方。demo下载地址）：

demo

3、 CC技术要点

实现CC组件化开发框架主要须要解决的问题有如下几个方面：

  • 组件如何自动注册？
  • 如何兼容同步/异步方式调用组件？
  • 如何兼容同步/异步方式实现组件？
  • 如何跨app调用组件？
  • 组件如何更方便地在application和library之间切换？
  • 如何实现startActivityForResult？
  • 如何阻止非法的外部调用？
  • 如何与Activity、Fragment的生命周期关联起来

3.1 组件如何自动注册？

为了减小后期维护成本，想要实现的效果是：当须要添加某个组件到app时，只须要在gradle中添加一下对这个module的依赖便可（一般都是maven依赖，也能够是project依赖）

最初想要使用的是annotationProcessor经过编译时注解动态生成组件映射表代码的方式来实现。但尝试事后发现行不通，由于编译时注解的特性只在源码编译时生效，没法扫描到aar包里的注解（project依赖、maven依赖均无效），也就是说必须每一个module编译时生成本身的代码，而后要想办法将这些分散在各aar种的类找出来进行集中注册。

ARouter的解决方案是：

  • 每一个module都生成本身的java类，这些类的包名都是'com.alibaba.android.arouter.routes'
  • 而后在运行时经过读取每一个dex文件中的这个包下的全部类经过反射来完成映射表的注册，详见ClassUtils.java源码

运行时经过读取全部dex文件遍历每一个entry查找指定包内的全部类名，而后反射获取类对象。这种效率看起来并不高。

ActivityRouter的解决方案是(demo中有2个组件名为'app'和'sdk')：

  • 在主app module中有一个@Modules({"app", "sdk"})注解用来标记当前app内有多少组件，根据这个注解生成一个RouterInit类

  • 在RouterInit类的init方法中生成调用同一个包内的RouterMapping_app.map

  • 每一个module生成的类(RouterMapping_app.java 和 RouterMapping_sdk.java)都放在com.github.mzule.activityrouter.router包内（在不一样的aar中，但包名相同）

  • 在RouterMapping_sdk类的map()方法中根据扫描到的当前module内全部路由注解，生成了调用Routers.map(...)方法来注册路由的代码

  • 在Routers的全部api接口中最终都会触发RouterInit.init()方法，从而实现全部路由的映射表注册

    这种方式用一个RouterInit类组合了全部module中的路由映射表类，运行时效率比扫描全部dex文件的方式要高，但须要额外在主工程代码中维护一个组件名称列表注解: @Modules({"app", "sdk"})

还有没有更好的办法呢？

Transform API: 能够在编译时(dex/proguard以前)扫描当前要打包到apk中的全部类，包括: 当前module中java文件编译后的class、aidl文件编译后的class、jar包中的class、aar包中的class、project依赖中的class、maven依赖中的class。

ASM: 能够读取分析字节码、能够修改字节码

两者结合，能够作一个gradle插件，在编译时自动扫描全部组件类(IComponent接口实现类)，而后修改字节码，生成代码调用扫描到的全部组件类的构造方法将其注册到一个组件管理类(ComponentManager)中，生成组件名称与组件对象的映射表。

此gradle插件被命名为：AutoRegister，现已开源，并将功能升级为编译时自动扫描任意指定的接口实现类(或类的子类)并自动注册到指定类的指定方法中。只须要在app/build.gradle中配置一下扫描的参数，没有任何代码侵入，原理详细介绍传送门

3.2 如何兼容同步/异步方式调用组件？

经过实现java.util.concurrent.Callable接口同步返回结果来兼容同步/异步调用：

  • 同步调用时，直接调用CCResult result = Callable.call()来获取返回结果
  • 异步调用时，将其放入线程池中运行，执行完成后调用回调对象返回结果: IComponentCallback.onResult(cc, result)
ExecutorService.submit(callable)
复制代码

3.3 如何兼容同步/异步方式实现组件？

调用组件的onCall方法时，可能须要异步实现，并不能同步返回结果，但同步调用时又须要返回结果，这是一对矛盾。 此处用到了Object的wait-notify机制，当组件须要异步返回结果时，在CC框架内部进行阻塞，等到结果返回时，经过notify停止阻塞，返回结果给调用方

注意，这里要求在实现一个组件时，必须确保组件必定会回调结果，即：须要确保每一种致使调用流程结束的逻辑分支上(包括if-else/try-catch/Activity.finish()-back键-返回按钮等等)都会回调结果，不然会致使调用方一直阻塞等待结果，直至超时。相似于向服务器发送一个网络请求后服务器必须返回请求结果同样，不然会致使请求超时。

3.4 如何跨app调用组件？

为何须要跨app进行组件调用呢？

  1. 对现有项目进行组件化改造的过程，确定不是一蹴而就，而是一个个组件逐步从主工程中抽离，这就涉及到主工程与组件间的通讯。若是不能跨app进行组件调用，开发时就须要跟主工程一块儿打包，失去了组件化开发的一个很是大的优点：组件单独编译运行提升开发&测试效率。
  2. 当独立运行的组件须要调用到其余组件的功能时，不须要将其余组件编译进来一块儿打包，能够调用主app中的组件，能够始终保持单module编译运行的状态进行开发。

目前，常见的组件化框架采用的跨app通讯解决方案有：

  • URLScheme(如：ActivityRouter、阿里ARouter等)
    • 优势：
      • 基因中自带支持从webview中调用
      • 不用互相注册（不用知道须要调用的app的进程名称等信息）
    • 缺点:
      • 只能单向地给组件发送信息，适用于启动Activity和发送指令，不适用于获取数据(例如：获取用户组件的当前用户登陆信息)
      • 须要有个额外的中转Activity来统一处理URLScheme，而后进行转发
      • 若是设备上安装了多个使用相同URLScheme的app，会弹出选择框（多个组件做为app同时安装到设备上时会出现这个问题）
      • 没法进行权限设置，没法进行开关设置，任意app均可调用，存在安全性风险
  • AIDL (如：ModularizationArchitecture)
    • 优势：
      • 能够传递Parcelable类型的对象
      • 效率高
      • 能够设置跨app调用的开关
    • 缺点：
      • 调用组件以前须要提早知道该组件在那个进程，不然没法创建ServiceConnection
      • 组件在做为独立app和做为lib打包到主app时，进程名称不一样，维护成本高

设计此功能时，个人出发点是：做为组件化开发框架基础库，想尽可能让跨进程调用与在进程内部调用的功能一致，对使用此框架的开发者在切换app模式和lib模式时尽可能简单，另外须要尽可能不影响产品安全性。所以，跨组件间通讯实现的同时，应该知足如下条件：

  • 每一个app都能给其它app调用
  • app能够设置是否对外提供跨进程组件调用的支持
  • 组件调用的请求发出去以后，能自动探测当前设备上是否有支持这次调用的app
  • 支持超时、取消

基于这些需求，我最终选择了BroadcastReceiver + Service + LocalSocket来做为最终解决方案：

若是appA内发起了一个当前app内不存在的组件:Component1，则创建一个LocalServerSocket，同时发送广播给设备上安装的其它一样使用了此框架的app，同时，若某个appB内支持此组件，则根据广播中带来的信息与LocalServerSocket创建链接，并在appB内调用组件Component1，并将结果经过LocalSocket发送给appA。 BroadcastReceiver是android四大组件之一，能够设置接收权限，能避免外部恶意调用。而且能够设置开关，接收到此广播后决定是否响应(伪装没接收到...)。 之因此创建LocalSocket连接，是为了能继续给此次组件调用请求发送超时和取消的指令。

用这种方式实现时，遇到了3个问题：

  • 因为广播接收器定义在基础库中，全部app内都有，当用户在主线程中同步调用跨app的组件时，调用方主线程被阻塞，广播接收器也在须要主线程中运行，致使广播接收器没法运行，直至timeout，组件调用失败。
    • 将广播接收器放到子进程中运行问题获得解决
  • 被调用的app未启动或被手动结束进程，遇到广播接收不到的问题
    • 这个问题暂时未很好的解决，但考虑到组件化开发只在开发期间须要用到跨进程通讯，开发者能够经过手动在系统设置中给对应的app赋予自启动权限来解决问题
  • 跨进程调用时，只能传递基本数据类型，没法获取Fragment等java对象
    • 这个问题在app内部调用时不存在，app内部来回传递的都是Map，能够传递任何数据类型。但因为进程间通讯是经过字符串来回发送的，暂时支持不了非基本数据类型，将来能够考虑支持Serializable

3.5 组件如何更方便地在application和library之间切换？

关于切换方式在网络上有不少文章介绍，基本上都是一个思路：在module的build.gradle中设置一个变量来控制切换apply plugin: 'com.android.application'或apply plugin: 'com.android.library'以及sourceSets的切换。 为了不在每一个module的build.gradle中配置太多重复代码，我作了个封装，默认为library模式，提供2种方式切换为application模式：在module的build.gradle中添加ext.runAsApp = true或在工程根目录中local.properties中添加module_name=true

使用这个封装只需一行代码：

// 将原来的 apply plugin: 'com.android.application'或apply plugin: 'com.android.library'
//替换为下面这一行
apply from: 'https://raw.githubusercontent.com/luckybilly/CC/master/cc-settings.gradle'
复制代码

注：cc-settings.gradle源码传送门

3.6 如何实现startActivityForResult？

android的startActivityForResult的设计也是为了页面传值，在CC组件化框架中，页面传值根本不须要用到startActivityForResult，直接做为异步实现的组件来处理(在原来setResult的地方调用CC.sendCCResult(callId, ccResult)，另外须要注意：按back键及返回按钮的状况也要回调结果)便可。

若是是原来项目中存在大量的startActivityForResult代码，改形成本较大，能够用下面这种方式来保留原来的onActivityResult(...)及activity中setResult相关的代码：

  • 在原来调用startActivityForResult的地方，改用CC方式调用，将当前context传给组件

    CC.obtainBuilder("demo.ComponentA")
	.setContext(context)
	.addParams("requestCode", requestCode)
	.build()
	.callAsync();
复制代码

  • 在组件的onCall(cc)方法中用startActivityForResult的方式打开Activity

    @Override
   public boolean onCall(CC cc) {
       Context context = cc.getContext();
       Object code = cc.getParams().get("requestCode");
       Intent intent = new Intent(context, ActivityA.class);
       if (!(context instanceof Activity)) {
           //调用方没有设置context或app间组件跳转，context为application
           intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
       }
       if (context instanceof Activity && code != null && code instanceof Integer) {
           ((Activity)context).startActivityForResult(intent, (Integer)code);
       } else {
           context.startActivity(intent);
       }
       CC.sendCCResult(cc.getCallId(), CCResult.success());
       return false;
   }
复制代码

3.7 如何阻止非法的外部调用？

为了适应不一样需求，有2个安全级别能够设置：

  • 权限验证（给进程间通讯的广播设置权限，通常可设置为签名级权限校验），步骤以下：

    • 新建一个module
    • 在该module的build.gradle中添加对基础库的依赖，如： compile 'com.billy.android:cc:0.3.0'
    • 在该module的src/main/AndroidManifest.xml中设置权限及权限的级别，参考component_protect_demo
    • 其它每一个module都额外依赖此module，或自定义一个全局的cc-settings.gradle，参考cc-settings-demo-b.gradle

  • 外部调用是否响应的开关设置（这种方式使用起来更简单一些）

    • 在Application.onCreate()中调用CC.enableRemoteCC(false)可关闭响应外部调用

为了方便开发者接入，默认是开启了对外部组件调用的支持，而且不须要权限验证。app正式发布前，建议调用CC.enableRemoteCC(false)来关闭响应外部调用本app的组件。

3.8 如何与Activity、Fragment的生命周期关联起来

背景：在使用异步调用时，因为callback对象通常是使用匿名内部类，会持有外部类对象的引用，容易引发内存泄露，这种内存泄露的状况在各类异步回调中比较常见，如Handler.post(runnable)、Retrofit的Call.enqueue(callback)等。

为了不内存泄露及页面退出后取消执行没必要要的任务，CC添加了生命周期关联的功能，在onDestroy方法被调用时自动cancel页面内全部未完成的组件调用

  • Activity生命周期关联

    在api level 14 (android 4.0)以上能够经过注册全局activity生命周期回调监听，在onActivityDestroyed方法中找出全部此activity关联且未完成的cc对象，并自动调用取消功能：

    application.registerActivityLifecycleCallbacks(lifecycleCallback);
复制代码

  • android.support.v4.app.Fragment生命周期关联

    support库从 25.1.0 开始支持给fragment设置生命周期监听：

    FragmentManager.registerFragmentLifecycleCallbacks(callback)
复制代码

    可在其onFragmentDestroyed方法中取消未完成的cc调用

  • andorid.app.Fragment生命周期关联（暂不支持）

4、 CC执行流程详细解析

组件间通讯采用了组件总线的方式，在基础库的组件管理类(ComponentMananger)中注册了全部组件对象，ComponentMananger经过查找映射表找到组件对象并调用。

当ComponentMananger接收到组件的调用请求时，查找当前app内组件清单中是否含有当前须要调用的组件

  • 有： 执行App内部CC调用的流程：

App内部组件调用总线

  • 没有：执行App之间CC调用的流程

    App之间组件调用总线

4.1 组件的同步/异步实现和组件的同步/异步调用原理

  • 组件实现时，当组件调用的相关功能结束后，经过CC.sendCCResult(callId, ccResult)将调用结果发送给框架
  • IComponent实现类(组件入口类)onCall(cc)方法的返回值表明是否异步回调结果：
    • true: 将异步调用CC.sendCCResult(callId, ccResult)
    • false: 将同步调用CC.sendCCResult(callId, ccResult)。意味着在onCall方法执行完以前会调用此方法将结果发给框架
  • 当IComponent.onCall(cc)返回false时，直接获取CCResult并返回给调用方
  • 当IComponent.onCall(cc)返回true时，将进入wait()阻塞，知道得到CCResult后经过notify()停止阻塞，继续运行，将CCResult返回给调用方
  • 经过ComponentManager调用组件时，建立一个实现了java.util.concurrent.Callable接口ChainProcessor类来负责具体组件的调用
    • 同步调用时，直接执行ChainProcessor.call()来调用组件，并将CCResult直接返回给调用方
    • 异步调用时，将ChainProcessor放入线程池中执行，经过IComponentCallback.onResult(cc, ccResult)将CCResult回调给调用方

执行过程以下图所示：

CC兼容同步/异步调用和实现原理图

4.2 自定义拦截器(ICCInterceptor)实现原理

  • 全部拦截器按顺序存放在调用链(Chain)中

  • 在自定义拦截器以前有1个CC框架自身的拦截器：

    • ValidateInterceptor

  • 在自定义拦截器以后有2个CC框架自身的拦截器：

    • LocalCCInterceptor（或RemoteCCInterceptor)
    • Wait4ResultInterceptor

  • Chain类负责依次执行全部拦截器interceptor.intercept(chain)

  • 拦截器intercept(chain)方法经过调用Chain.proceed()方法获取CCResult

    拦截器调用流程

4.3 App内部CC调用流程

当要调用的组件在当前app内部时，执行此流程，完整流程图以下：

App内部CC调用流程图

CC的主体功能由一个个拦截器(ICCInterceptor)来完成，拦截器造成一个调用链(Chain)，调用链由ChainProcessor启动执行，ChainProcessor对象在ComponentManager中被建立。 所以，能够将ChainProcessor看作一个总体，由ComponentManager建立后，调用组件的onCall方法，并将组件执行后的结果返回给调用方。 ChainProcessor内部的Wait4ResultInterceptor ChainProcessor的执行过程能够被timeout和cancel两种事件停止。

4.4 App之间CC调用流程

当要调用的组件在当前app内找不到时，执行此流程，完整流程图以下：

App之间CC调用流程图

5、使用方式介绍

CC的集成很是简单，仅需4步便可完成集成：

  1. 添加自动注册插件

    buildscript {
    dependencies {
        classpath 'com.billy.android:autoregister:1.0.4'
    }
}
复制代码

  2. 引用apply cc-settings.gradle文件代替 'app plugin ...'

    apply from: 'https://raw.githubusercontent.com/luckybilly/CC/master/cc-settings.gradle'
复制代码

  3. 实现IComponent接口建立一个组件类

    public class ComponentA implements IComponent {
    
    @Override
    public String getName() {
        //组件的名称，调用此组件的方式：
        // CC.obtainBuilder("demo.ComponentA").build().callAsync()
        return "demo.ComponentA";
    }

    @Override
    public boolean onCall(CC cc) {
        Context context = cc.getContext();
        Intent intent = new Intent(context, ActivityComponentA.class);
        if (!(context instanceof Activity)) {
            //调用方没有设置context或app间组件跳转，context为application
            intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
        }
        context.startActivity(intent);
        //发送组件调用的结果（返回信息）
        CC.sendCCResult(cc.getCallId(), CCResult.success());
        
        return false;
    }
}
复制代码

  4. 使用CC.obtainBuilder("component_name").build().call()调用组件

    //同步调用，直接返回结果
CCResult result = CC.obtainBuilder("demo.ComponentA").build().call();
//或 异步调用，不须要回调结果
CC.obtainBuilder("demo.ComponentA").build().callAsync();
//或 异步调用，在子线程执行回调
CC.obtainBuilder("demo.ComponentA").build().callAsync(new IComponentCallback(){...});
//或 异步调用，在主线程执行回调
CC.obtainBuilder("demo.ComponentA").build().callAsyncCallbackOnMainThread(new IComponentCallback(){...});
复制代码

更多用法请看github上的README

PS:配合个人另外一个库（PreLoader）一块儿食用味道更佳：AOP实如今打开页面以前预加载页面所需的数据，而且这个预加载功能彻底在组件内部实现，与外部无耦合。

6、老项目进行组件化改造的成本有多高？

有些同窗很想尝试组件化开发，但仅仅停留在了解的阶段，缘由是担忧在老项目上进行改造的工程量太大，不敢大改。

CC框架自己就是在老项目进行组件化改造的需求下设计出来的，考虑到了组件化过程当中的一些痛点：

  • 万事开头难，不要太多配置：CC将配置封装到了一个gradle文件，须要组件化的module在其build.gradle中添加apply from: 'https://raw.githubusercontent.com/luckybilly/CC/master/cc-settings.gradle'便可
  • 万事开头难，不要改动太大：其实，在组件化改造以前，若是封装的比较好的话，不少lib module与主工程的耦合仅仅是Activity的类名。例如咱们项目中的收银台，组件化以前经过startActivityForResult的方式打开收银台主界面并经过setResult的方式返回结果给调用方，只须要在收银台module中增长一个IComponent的实现类，在其onCall方法中调用cc.getContext().startActivityForResult打开收银台页面，并将原来经过startActivityForResult打开收银台的地方改为CC调用便可，收银台module原来的代码纹丝不动。后续优化时再将结果的返回方式从setResult换成CC.sendCCResult(callId, result)就完全完成了收银台的组件化改造工做。
  • BaseActivity/BaseFragment/Util类/MVP封装的各类Base等：组件化改造并非让全部module都变成组件，还有一些能够下沉做为公共库，
  • 模块太复杂，短期内改不动： 页面改版是个很好的机会，提早与产品经理沟通，获知那些模块即将改版，乘着改版对模块进行组件化改造一箭双雕。咱们的详情页、购物车、首页都是在这个过程当中完成组件化改造的。
  • 依赖太多，解耦不便：在改造初期，能够先粗粒度定义组件，熟练以后再继续优化
  • 组件化开发框架学习成本高，要团队内每一个人都了解须要较长时间：CC为全部的组件调用提供了统一的调用方式和实现方式，没有任何注解、仅1个接口类。另外library模式切换成application的方式简化为在local.properties中配置一行module名称=true便可。几乎零门槛进行组件化开发

结语

本文比较详细地介绍了android组件化开发框架《CC》的主要功能、技术方案及执行流程，并给出了使用方式的简单示例。 你们若是感兴趣的话能够从GitHub上clone源码来进行具体的分析，若是有更好的思路和方案也欢迎贡献代码进一步完善CC。

系列文章

CC框架实践(1)：实现登陆成功再进入目标界面功能

CC框架实践(2)：Fragment和View的组件化

CC框架实践(3): 让jsBridge更优雅

致谢

ActivityRouter

ARouter

ModularizationArchitecture

Android架构思考(模块化、多进程)

开源最佳实践：Android平台页面路由框架ARouter

DDComponentForAndroid

Router

交流

billy(齐翊)的微信二维码
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程