浅析Android 项目构建

Google自从2014推出Android Studio之后就宣布在来年结束对Eclipse Android开发工具的支持，所以这里直说使用Android Studio对于Android项目的构建。

对于Android 开发者来说 Gradle 是一个强大的工具，它提供便捷的方式帮助开发者构建APP，下面是维基上对Gradle的解释

Gradle是一个基于Apache Ant和Apache Maven概念的项目自动化建构工具。它使用一种基于Groovy的特定领域语言来声明项目设置，而不是传统的XML。当前其支持的语言限于Java、Groovy和Scala，计划未来将支持更多的语言。

通俗的理解：

1. Gradle是一种构建工具,它可以帮你管理项目中的差异,依赖,编译,打包,部署......,你可以定义满足自己需要的构建逻辑,写入到build.gradle中供日后复用.
2. Gradle不是一种编程语言,它不能帮你实现软件中的任何实际功能

Android APP 从编译，打包流程又是怎样的呢？流程如下图： 

 概述如下：

1.使用AAPT（Android资源打包工具）打包工程的资源文件(res文件夹下的文件)，通过AAPT打包成R.java类(资源索引表)，以及.arsc资源文件。

2.如果有aidl，通过aidl工具，打包成java接口类

3.R.java和aidl.java通过java编译成想要的.class文件。

4.源码class文件和第三方jar或者library通过dx工具打包成dex文件。dx工具的主要作用是将java字节码转换成Dalvik字节码，在此过程中会压缩常量池，消除一些冗余信息等。

5.apkbuilder工具会将所有没有编译的资源，.arsc资源，.dex文件打包到一个完成apk文件中中。

6.签名，5中完成apk通过配置的签名文件(debug和release都有)，jarsigner工具会对齐签名。得到一个签名后的apk,signed.apk

7.zipAlign工具对6中的signed.apk进行对齐处理，所谓对齐，主要过程是将APK包中所有的资源文件距离文件起始偏移为4字节整数倍，这样通过内存映射访问apk文件时的速度会更快。对齐的作用主要是为了减少运行时内存的使用。

Android 打包相关细节很多这里我想着重说一下我认为与开发相关较多的几个知识点：

代码混淆

1.ProGuard是什么

ProGuard是ADT r8开始被默认集成到了Android SDK中用于压缩，优化，混淆代码的工具。主要作用是可以移除代码中无用的类，字段，方法和属性。同时混淆代码增加反编译的难度。

2.ProGuard技术的功能

• 压缩        移除无效的类、属性、方法等
• 优化        优化编译后的字节码，移除无用的指令
• 混淆        使用无意义的字母替换类名、属性名、方法名
• 预检测    在Java平台上将编译后的代码再次做检测

3.ProGuard的工作原理

这里主要说一下EntryPoint。EntryPoint可以理解为一种标志，它是在ProGuard过程中不会被处理的类或者方法，在压缩的过程,ProGuard会从上述的EntryPoint中开始遍历搜索出哪些类和类的成员在使用（被标记为EntryPoint的类和方法有些是在使用的而且这些是我们在混淆文件中配置不希望被混淆的类和方法，有些是没有使用的）。对于那些没有被使用的类和成员，就会在压缩阶段被丢弃。然后在接下来的优化步骤中，那些非EntryPoint的类，方法都会被设置为private，static或者final，而且不使用的参数都会被移除。接着在混淆的步骤中，ProGuard会对非EntryPoint的类和方法进行重命名。最后就会对代码进行预检测，以便保证稳定性。

ProGuard可以减小APP体积，优化性能以及提高安全性和稳定性的工具，它不是必须的但是是官方极度推荐使用的。

Jenkins

Jenkins是一个开源软件项目，是基于Java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。Jenkins的功能包括：

1、持续、自动地构建/测试软件项目。  
2、监控软件开放流程，快速问题定位及处理，提示开放效率。

使用Jenkins可以实现Android打包的自动化，大大减少开发人员随时打包的烦恼，它的好处不仅仅是这些，谁用谁知道，哈哈。

Git

Git是 Linus Torvalds 开发的一个开放源码的版本控制软件, 是一个快速的分布式版本控制系统，拥有强大的分支管理。

有一定开发经验的人相信对Git都不会太陌生，这里主要说一下Git的四种的工作流：

1.fork/clone

它有一个公开的中央仓库，其他贡献者可以Fork（克隆）这个仓库作为你自己的私有仓库，开源项目维护者可以直接往中央仓库push代码，而代码贡献者只能将代码push到自己的私有仓库，只有项目维护者接受代码贡献者往中央仓库发起的pull request才会真正合入。

这种模式比较适合大型项目的开发，保证项目代码的质量以及稳定，易于维护。

2.clone

这种工作方式跟svn类似，它只有一个master分支，开发者会先把远程的仓库克隆到本地，之后的修改和提交都在本地操作，直到在某个合适的时间点将本地的代码合入到远程master。这种工作流比较适合小团队，因为小团队可能不会太多的协作和合流的动作。

在开发者提交自己的修改到master前，需要先fetch在master的新增提交，rebase自己的提交于master的最新版本。

这样做的意思是在说，『我要把自己的修改加到别人已经完成的修改之上』。如果本地修改和上游提交有冲突，Git会暂停rebase过程，给你手动解决冲突的机会。

3.feature

这种工作流关注功能开发，不直接往master提交代码保证它是稳定并且干净的，而是从master拉取feature分支进行功能开发，团队成员根据分工拉取不同的功能分支来进行不同的功能开发，这样就可以完全隔离开每个人的工作。当功能开发完成后，会向master分支发起Pull Request，只有审核通过的代码才真正允许合入master，这样就加强了团队成员之间的代码交流，也就是我们常说的Code Review。

4.Gitflow

Gitflow是很多团队会采用的工作流，它会相对复杂一点，但它非常适合用来管理大型项目的发布和维护。master和develop分支在整个开发周期是一直存在的，master分支可以被视为稳定的分支，而develop分支是相对稳定的分支，特性开发会在feature分支上进行，发布会在release分支上进行，而bug修复则会在hotfix分支上进行。

我们团队目前对Gitflow的一些实践：

• master：主分支，不允许直接往这个分支提交代码，只允许release分支往这个分支发起merge request进行合流，发布完成后合并release分支并打tag
• release：发布分支，发布完成后发起merge request向master进行合流
• test：测试分支，用于回归测试，bug修复，结束之后向release发起merge request进行合流
• develop：开发分支，用于日常开发，包括代码优化、功能性开发，结束之后合并到test
• feature：特性分支，从develop分支拉取，用于下个迭代版本的功能特性开发，功能开发完毕合并到develop分支

大家可能会发现我们这个跟标准的Gitflow工作流有些差别，其实也没有什么标准不标准的，前面说到要结合团队的实际情况，我们团队对于目前所采用的工作方式都是达成共识的，所以有一些差异并没有关系。关于git工作流，只有选用最合适自己团队的工作流才能有效的提高开发效率，上面提到的一些工作流模式都有各自的适用场景，如何选用适合自己团队的工作流得结合团队成员的实际情况，看团队成员对于工作流的理解程度，还有对于工作流的执行程度。

以上就是对于项目构建一些自己想要记录的。

参考文档：

https://www.jianshu.com/p/2a7474ee3527

https://blog.csdn.net/binbinqq86/article/details/81033707