1年半前我在博客中写了一篇关于Android组件化的文章，那个时候组件化在国内还不是很流行，我也是一个偶然的机会接触到了这个技术，并且很神奇的在Github上找到了当时还是同事的志涛同学的一个demo(感叹一下他对gradle的理解之深，虽然从这个demo中看不出来，但是在平时的交流过程中，确实可以学习到很多)。

看完上面这个demo之后，又和提出这个思想的冯老师交流了一下，感觉这个技术确实是对平时的开发，特别是多人开发有帮助的，于是在公司的项目中尝试了一下(大概是16年的年底)，效果还不错。

17年整一年几乎都在做一个创新型App的研发，在年中的时候把之前的组件化方案改造了一下并用在了新项目中。

到现在接触并使用组件化也有快2年的时间了，决定再回过头来写一篇关于组件化的文章，有不足之处还望大家能指出并交流。

为什么要写

其实我原本是不想再写和组件化相关的文章了，但是国内最近关于Android组件化的文章如雨后春笋一样的冒了出来，这样的情景和16年全名hotpatch的“盛况”一模一样，好像不搞这个东西就落伍了一样。其中几乎每一篇文章我都看过，说实话，四个字：千篇一律。上来先讲一下非组件化的坏处(编译时间长，模块混乱)，然后讲一下组件化的好处，接着讲一下路由的重要性，最后再给你整一点gradle插件(基本都是通过transform去注入代码)。这样的文章在我看来有一些浅显了，对于不了解组件化的同学来说看一篇这样的文章确实可以快速入门，但是如果你真的要在实际项目中使用组件化，这样的文章是远远不够的。

所以我的这篇文章不会聚焦于上面提到的组件化的优点，路由以及gradle插件，更多的是一些经验，如果更好的进行组件化。

对外友好

这一章节的主旨思想就是：模块不仅要对自己负责，更好对其他模块负责。

举个例子，我们现在有一个图片模块，还有一个编辑模块，而编辑模块需要用到图片模块中的一些方法(我更喜欢称之为”服务”)，这个时候我们需要建立图片模块和编辑模块的依赖关系，简而言之，就是要让编辑模块能够使用图片模块的服务。这在gradle这样的构建系统中很容易做到，但是如果不假思索的去建立依赖关系，会有一个很严重的问题，既图片模块会暴露不改暴露的类和方法。简单的依赖关系会让整个图片模块暴露给编辑模块，这样做的坏处就是一些内部使用的util类编辑模块也可以使用，从而带来蝴蝶效应。比如图片模块中有一个util叫StringUtil，它将暴露给编辑模块，如果编辑模块的开发者在import的时候不留意，就会import到这个StringUtil，而图片模块的开发者认为这个StringUtil是给自己用的，可能会随意修改里面的方法签名或者返回值等，这是很危险的。

其实这样的问题，如果你有web开发的经验，会很好解决。在web开发中，如果你的系统需要对别的系统暴露一些服务，不论是rpc服务或者http服务，都会在client模块中新建一个接口，而在core模块中实现它，最终对外暴露的只有client模块，也就是只暴露了对应的服务，而core模块的一些util类是不会被引用到的。

这样面向接口编程有很多的好处：第一就是解决了上面所说的过多暴露类和方法，第二就是对于调用者和被调用者来说都十分的清晰，我所提供的服务就是接口中的方法，所有对外的增删改都是基于接口的，在多人协作的情况下减小了沟通的成本。

基于以上的想法，在Android的模块化协作中，我也建议大家使用这样的方式去进行模块间的调用。

针对于上面的例子，我们对图片模块创建2个module：image和image-export。image-export就是前面提到的client，里面存放需要对外暴露的接口，可能还有一个bean等，image依赖image-export，实现其中的接口，并将一些只希望内部使用的类放在其中。对于这种的架构模式，我们还需要一个容器去注册这些服务，并让其他模块来调用它们，我们会有一个componentManager类在做这样的操作，在App初始化的时候去收集所有需要注册的类并通过反射初始化实例，运行时按需调用。

持续集成友好

我看过的几乎所有的组件化文章里提到的优点都有一个：减少编译时间。但是真的到项目中你就会发现，单独编译模块的时候确实比较爽，但是当集成之后，编译时间会呈几何形式形式的增长，原因就是在集成之后，每一个模块都需要编译，时间当然会很长。而那些文章里多没有提到这个问题，更没有说如何解决。

就我而言，这样的情况是不太能够忍受的，既然是优化，怎么能有这样开倒车的事情发生。其实要解决这个问题也比较简单，那就是在集成的时候通过aar的形式集成，当我们在开发完成之后，可将对应的模块通过gradle上传至仓库中(对于本地开发，上传至本地仓库；对于云端构建，则上传至自己的maven私服中)。这样就可以做到按需更新，比如你有10个module，这一次只在对其中2个更新，在构建的时候只需要针对这2个module进行aar发布就可以了。

开发友好

对于组件化开发，我们可以做很多操作让日常的开发变得简单，下面我举几个例子：

AndroidStudio模板开发。组件化开发需要在gradle文件中做一些操作，包括新建一个module的时候，我们最好不要让对应的开发去copy已有的代码，太低效了。通过AndroidStudio模板的开发，可以做到一键生成组件化所需要的gradle文件。

gradle文件优化。对于上面的例子，module和module-export里面肯定是比较多的重复代码的，我们可以抽取一个公共的gradle文件去做这样的事，结合AndroidStudio模板，将会让文件变得十分简洁易懂并且可复用。而对于模块间的依赖，因为我们可能是lib依赖，也可能是aar依赖，而在依赖中我们也可能通过api，implementation，compileOnly等方式去依赖，我们也可以通过定义一个gradle方法去完成：

void aarOrLib(String moduleName, String scope = null){

   if(useAAR() || isDebug()){

       project.dependencies {

           switch (scope){

               case 'api':

                   api "xx.xx.xx:${moduleName}:${AAR_VERSION_NAME}"

                   break

               case 'compileOnly':

                   compileOnly "xx.xx.xx:${moduleName}:${AAR_VERSION_NAME}"

                   break

               default:

                   implementation "xx.xx.xx:${moduleName}:${AAR_VERSION_NAME}"

                   break

           }

       }

   } else {

       project.dependencies {

           switch (scope){

               case 'api':

                   api project(":${moduleName}")

                   break

               case 'compileOnly':

                   compileOnly project(":${moduleName}")

                   break

               default:

                   implementation project(":${moduleName}")

                   break

           }

       }

   }

}

git flow开发。这个不多说了，结合feature多模块平行开发，也算是组件化的优势之一。

总结

这篇文章几乎没什么代码，主要是对1年半来组件化开发的一个总结。

在看我来，组件化的前提是所有基础SDK下沉。这一点必须要满足，比如登录组件，如果这个组件没有下沉而是存在于App中，在模块化的时候就势必会让模块反向依赖App，这是不合理的。

此外，基础组件横向划分，业务纵向划分，拒绝无意义的横向，跨级以及反向依赖，这是在组件化进行中必须要遵守的原则。