业务组件单独运行

前言

使用组件化方案 Component 也可以再单独接入那些切换 lib 和 application 的 gradle 插件. 但是也请认真读完下面的文字

大家对其他组件化框架有了解的话,就会知道有些组件化框架提供了所谓的 gradle plugin 来实现一个业务组件的 Application 和 Library 的切换,配置成功的情况下确实失挺方便的,但是！这里要敲黑板!!! gradle plugin 在提供了你看的便利的同时,也给你的项目埋下了不可预料的问题.因为每一个项目的配置和机器的环境等等,都可能让插件的行为变得不正常.这个从那些组件化项目的插件使用者反馈的 issue 就能看出来.一旦出现了问题,其实基本上失很难去解决的,作者不可能远程你的电脑解决,而你的问题又不容易让作者知道.所以我在这里强调的是,插件你如果用,那么就要承担上面我说的风险.下面说两种 0 风险的方案

配置 Gradle 常量属性

我随便找了几篇文章来说明如何使用,我自己就不在陈述了

• https://www.jianshu.com/p/5014bc7cf0de
• https://juejin.im/post/5ab09423f265da23731446b1
• Google 相关的搜索

方式1：单独新建 Module

比如您的项目结构如下：

• app
  • module1
  • module2
  • module3

如果你要单独运行每一个业务模块,您可以新建几个单独的 module,如下

• app
  • module1Run
  • module1
  • module2Run
  • module2
  • module3Run
  • module3

module1Run 是一个 Application,包含了 module1 Library,其他的同理.

好处

这样子是百分百不可能出问题的,这些 xxxRun 模块最终打包是不会参与的,这也很好的做到了 debug 的代码、资源等都不会污染参与打包的代码

坏处

项目中的 Module 可能会很多,毕竟一个业务 Module 就需要一个新的 ModuleRun.但是这依然是我组件化方案中单独运行模块的首选,因为百分百兼容,百分百不会出问题

方式2：壳工程 app 只包含指定的业务模块运行

这种方式就是, 在壳工程的 build.gradle 文件中, 注释掉你不想依赖的业务模块, 留下你想要运行的模块即可.

好处

这种方式比上面那个方式还要好.

坏处

可能要频繁修改 build.gradle 文件中的模块依赖