博客已经很久没有更新内容，一方面工作最近很忙，另一位方面最近在陆续把博客内容同步到公共账号，在重新整理SDK这个系列的过程中才发现关于自动构建提到的或者介绍的地方很多，但是对于自动构建具体介绍的内容很少，因此现在再补上一篇。
这里同样不会过度分析Android的自动构建工具有哪些以及他们的优缺点，为什么要使用自动构建等等。本文的侧重点还是集中在SDK的自动化构建中主要做那些工作。
Android自动构建工具
早期的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构建相关的内容，后续根据情况看能不能推出。
SDK自动构建包括的内容
使用自动构建最大的优势就是可以降低很多因为人为失误引起的低级错误。因此一般会先梳理版本发布前的一些检查项，然后把他们都添加到自动构建中。下面就介绍下我们的自动构建都做了什么工作：
- 分配版本号 我们SDK早期的版本号由人工维护，因此在SDK开发经验之测试（点击查看）介绍过，我们会在版本发布的checklist里面增加版本号的确认，确保发出去版本的版本号是正确的。 目前我们最新的SDK版本中，版本号不再人工维护，因此SDK在每次正式发布前，都会去专门分配一个新的版本号。
- 更新版本号 之前遇到过代码中版本号忘记更新的情况，因此后来在前面提到的版本发布的checklist里面 增加了版本号的人工确认，但最终还是不够方便，因此最新的版本会在编译版本前先动态修改了代码和配置文件中的版本号。
- SDK编译 代码编译，这一步仅仅为了获取SDK相关的发布内容。
- 生成版本信息文件 为了能第一时间确认SDK的版本相关的细节信息，我们会在SDK里面增加一个版本信息文件，里面保存SDK的构建时间、版本、对应SVN的版本以及对应svn tag的标签。这一步主要是做这部分工作。
- 生成资源文件 生成SDK对外发布的内容、因为目前项目是AS的，为了兼容ADT的项目，因此我们会提供提供AS下的aar和ADT下的libs、jni和res。这里主要是根据之前的编译结果汇总出最总版本发布的内容。 这里不只是简单的资源的拷贝、要在SDK的jar中加入一些版本信息、构建不同的插件包或者删除一些不对外暴露的内容等都是在这里完成。
- 生成demo工程 开发中的demo是依赖SDK的源码的，但是对外提供的demo不能用这样的方式。因此在自动构建的时候，我们会通过自动脚本生成一个独立的Demo工程，新的工程删除了对SDK的源码的依赖，而是直接使用上一步生成的资源文件。 在生成demo工程以后，直接编译生成Demo对应的APK，由于我们的demo内部使用和对外提供的并不一致，因此这里会比较复杂，先用Demo工程生成内部APK，然后删除demo中不对外暴露的内容，脚本处理代码依赖，之后再次编译生成对外提供的APK。
- 创建SVN tag
至此编译相关的工作都已经完成，开始处理收尾工作。首先是把该版本对应的代码创建新的tag，这样后续遇到问题可以第一时间找到对应版本的代码来进行验证和问题定位。
- 备份mapping文件
把该版本对应的混淆后mapping文件备份，方便后续问题定位时使用。
- 生成版本包
把前面步骤生成的资源文件、demo工程、对外发布的APK以及文档等内容check到某一个位置然后集中打包为对外发布提供的版本包。后续测试以及发布都是用这个包。
SDK自动构建怎么去做
可以看到我们的自动构建涉及到的内容还是很多的，这一系列内容怎么完成呢？
在使用ant的时候，我们全部都是在ant中完成，通过不同的task任务去实现。因此当时的ant脚本还是比较复杂（之前只是简单写过一个关于ant使用SVN的文档：Ant中的SVN 使用）。在切换到gradle以后，我们上面的所有内容都是放在shell中完成，gradle仅仅是完成代码编译。这部分可以参考之前写的一个存在多个模块（包含Native）的工程的gradle构建的事例（点击查看），在里面有一个类似的事例，后续看情况把目前在用的完整的构建脚本分享出来。
