一种简单的低侵入性的组件化方案

本组件化方案已开源在github，欢迎转载和star。github.com/beyondxia/m…

传统组件化方案问题

    上篇中咱们对传统的组件化方案的实现原理进行了简单的介绍，以及对其优缺点进行了相应的分析。针对接口通讯机制的方案，有以下缺点：
a、须要提供一个公共的目录或者公共模块用做为服务层，全部接口文件和中间共享的文件都须要手动拷贝至服务层。
b、组件若须要提供服务，除了自己的实现类，还须要提供一个或多个中间接口文件，增长了开发量和组件集成的复杂度以及维护成本。
c、因为服务实现类与服务接口存在依赖关系，因此业务方须要实现暴露的接口，并要实现具体须要暴露的业务功能。
d、全部的组件服务的注册都须要手动进行，增长了开发量与风险。
e、与接口相关的一些中间类（特别model）也须要同步下沉至公共目录。

优化方案

1. APT生成接口文件

    针对不足点a和b，若是能够自动生成并拷贝接口文件，那为题就迎刃而解，那该如何作呢？
    咱们知道，APT(Annotation Processing Tool 的简称)能够在代码编译期解析注解，生成新的Java文件，能够减小手动的代码输入.
    本框架就是利用APT进行接口文件的自动生成。用户要作的只是给须要暴露的服务以及服务中须要暴露的方法添加相应的注解（@ExportMethod），APT将根据注解自动生成接口。以下图所示，Message即为组件提供的服务类，IMessage为生成的接口。

2. javassist修改字节码

    APT能够生成对外暴露接口，那接下来咱们须要作的就是让业务方实现该接口，并完成真正功能的实现，那又改如何作呢？
    其实从代码层面看，咱们只须要Message类实现IMessage，因为Message在IMessage接口生成前就已经由模块内部实现，因此若是要修改Message，最好的方法仍是编译阶段修改Message.class字节码。
    Javassist 是一个执行字节码操做的库。它能够在一个已经编译好的类中添加新的方法，成员，或者实现某个接口、继承某个父类等。
    针对不足点c：Javassist恰好能够知足咱们的需求，编译阶段经过修改字节码，让Message实现接口IMessage。这样就实现了服务类Message与服务接口类IMessage的实现关系。

    这样还有一个好处：若服务类进行版本升级，框架会经过APT与gradle transform技术能够对服务接口作到静默自动同步，对组件开发者彻底无感知，开发者只需专一于开发本身的组件业务便可。

3. APT完成组件的搜集和注册

    针对不足点d：框架经过APT技术，对有ExportService注解标识的服务类进行收集，并在框架初始化的时候进行自动注册，开发者彻底不须要参与注册工做。而且咱们根据服务的使用场景以及频率提供了不一样的实例化时机，可根据组件的使用场景在注解上进行相应的配置便可。

4. 自定义BCDictionary代替传统Model

    针对不足点e：咱们不提倡组件间以自定义的model传输数据，但传输复杂类型的数据类型又是不可避免的，固然能够选择现有的序列化方式传输，如json，但在序列化和反序列化时须要开发者作诸多繁琐的操做。为此，框架提供了一种简单易用的的传输复杂类型数据类型的方式，极大程度上简化了序列化与反序列化的操做。

其余问题：

若是组件间由于业务须要，须要共享复杂数据结构，如：

    须要暴露一个自定义view。 从原则上来说，组件化设计不建议组件间共享复杂类型，即便有这类类型，更建议以通用数据下沉至base层的方式。 可是针对一个大型项目作组件化拆分的时候，有时必然要设计这类问题。针对这样的问题，是须要手动拷贝文件至服务层。

    经过以上介绍的方案，框架基本上解决了接口通讯方式存在的缺点。大部分工做已经由框架在编译阶段完成，极大的减小了业务接入的成本，对代码侵入性极小，使开发者能够专一于组件功能的开发。

上一篇：一种低侵入性的组件化方案 之 传统组件化方案的问题