吐槽gradle

我自己比较喜欢传统的构建方式,但随着android的不断进步,只能切换到gradle来构建了。但gradle真的很不方便,往往只是修改其中的一个模块,就需要将其他的模块统一整理一下,有时候只是想测试一下,临时修改一下而已。

gradle的settings.gradle部分

所有需要的模块都需要include进去,如果模块没有进去,就会找不到。如果修改了某个字模块(A)的构建脚本,构建其他与这个子模块完全无关的模块(B,C,D等)的时候,也会检查这个模块(A)的脚本合法性.

我的单个gradle工程下面有很多模块,因为偷懒以及尽可能的适用性,很多项目的代码直接适用子模块的方式构建,但不同项目的版本号可能不是一样的,而有些部分真的是一些功能模块,是不需要版本号之类的。 在构建需要版本号功能的时候,我会在构建的时候,传入正确的版本号,比如:

gradlew bundleRelease -Pversion_code=1 -Pversion_name=0.0.1

在构建功能模块的时候,是完全不需要参数的,然后在功能模块下,适用下面的命令:

gradlew build

这样是会失败的,因为在构建的预处理阶段,会去检查项目的代码,然后发现参数没有定义。

如果象我这样,每个模块,每个项目都是使用git+repo来管理的话,为了单独一个项目或者子模块的参数,需要更新几乎所有项目的脚本。看着我的整个项目的几百个git,实在太无语了。

gradle构建过程中的依赖部分

gradle 在每次构建过程中,会自动检查依赖的版本,如果版本号使用’+’的方式,则会使用最新的版本。 而我有些项目的依赖比较多,于是就发生各种各样古怪的事情:

某天我构建出来的包突然比前一天的包大了近20MB,这让我难以接受,毕竟除了资源,我原来的包只有10多MB,然后不断的检查依赖和最终包内容, 发现facebook的sdk在更新中加入了某个国际化的utf-8的表情支持之类的。然后只好固定facebook的版本号才得以解决

某天我突然构建失败,提示什么某些依赖无法找到,然后各种详细日志检查,发现是sdk提供方的服务器挂了,返回502了,又赶上对方周末或者休假, 过几天又自己好了。

模块之间的依赖

几个模块, A(native,build),B,C,A是项目的主体,包含最终的打包动作(A.build)和native构建部分(A.native),B在构建的时候依赖 A的java编译部分, C是动态模块部分,依赖B的java编译部分,并最终作为资源放到A的资源目录中。

对于传统的makefile部分,只需要将各部分的动作作为任务依赖即可自动跟踪检查,而使用gradle,尤其尽量复用插件的情况下, 就必须进行各种的hook或者注入。于是我不得不在每个项目或者模块中,在任务添加的时候,动态的添加某部分的依赖。

构建过程

在使用第三方代码的时候,最好祈祷构建脚本需要的gradle版本,android工具的gradle版本和现有的没有太大的冲突, 不然,又要找资料,找方案,折腾好半天环境。

我希望的构建系统是尽可能的稳定的,在项目的开发,迭代过程中没有太大的变化,这样一旦开发环境搭建 完成,就不需要反复的确认环境问题。而这一点上,gradle显然有各种问题,这也许是因为我没有对gradle进行 详尽仔细的学习的原因,但gradle的文档也太多太长了,再加上不同版本的变化,再加上google的插件 又比较随意,真的很让人头疼啊。

回头还是将android的源代码下载下来看看大家都是如何使用gradle的吧。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据