博客已经很久没有更新内容,一方面工作最近很忙,另一位方面最近在陆续把博客内容同步到公共账号,在重新整理SDK这个系列的过程中才发现关于自动构建提到的或者介绍的地方很多,但是对于自动构建具体介绍的内容很少,因此现在再补上一篇。
这里同样不会过度分析Android的自动构建工具有哪些以及他们的优缺点,为什么要使用自动构建等等。本文的侧重点还是集中在SDK的自动化构建中主要做那些工作。
早期的Android项目使用ADT(Eclipse)来开发,当时的自动构建工具大多是用ant。随着Android Studio的兴起和google停止对ADT的支持,越来越多的项目开始使用gradle来构建。因为上面的原因,目前Android项目的自动构建也主要是使用ant和gradle。这里同样也不展开介绍ant和gradle这两种自动构建的原理和语法。
我们项目早期是使用ADT,而且当时的自动构建也是使用ant,目前已经全部转为AS + gradle,个人之前写过一篇关于SDK的Gradle构建的博客(一个存在多个模块(包含Native)的工程的gradle构建的事例(点击查看)),里面有对SDK的gradle的简单介绍,以及对应的事例代码。关于ant构建相关的内容,后续根据情况看能不能推出。
使用自动构建最大的优势就是可以降低很多因为人为失误引起的低级错误。因此一般会先梳理版本发布前的一些检查项,然后把他们都添加到自动构建中。下面就介绍下我们的自动构建都做了什么工作:
至此编译相关的工作都已经完成,开始处理收尾工作。首先是把该版本对应的代码创建新的tag,这样后续遇到问题可以第一时间找到对应版本的代码来进行验证和问题定位。
把该版本对应的混淆后mapping文件备份,方便后续问题定位时使用。
把前面步骤生成的资源文件、demo工程、对外发布的APK以及文档等内容check到某一个位置然后集中打包为对外发布提供的版本包。后续测试以及发布都是用这个包。
可以看到我们的自动构建涉及到的内容还是很多的,这一系列内容怎么完成呢?
在使用ant的时候,我们全部都是在ant中完成,通过不同的task任务去实现。因此当时的ant脚本还是比较复杂(之前只是简单写过一个关于ant使用SVN的文档:Ant中的SVN 使用)。在切换到gradle以后,我们上面的所有内容都是放在shell中完成,gradle仅仅是完成代码编译。这部分可以参考之前写的一个存在多个模块(包含Native)的工程的gradle构建的事例(点击查看),在里面有一个类似的事例,后续看情况把目前在用的完整的构建脚本分享出来。