再谈Android组件化

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发布就可以了。

开发友好

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

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

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

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    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
    }
    }
    }
    }
  3. git flow开发。这个不多说了,结合feature多模块平行开发,也算是组件化的优势之一。

总结

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

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

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