Android编译相关

什么是编译，可以简单理解为将高级语言转化为机器或虚拟机所能识别的低级别语言的过程。对于Android来说，这个过程就是把Java或者Kotlin转变为Android虚拟机运行的Dalvik字节码的过程。

Android编译

 

Gradle是Android官方的编译工具，它是GitHub上的一个开源项目。目前开源的项目有FaceBook的Buck以及Google的Bazel。
自己”造轮子”有如下好处：

• 统一编译工具
• 代码组织管理架构

• 极致的性能追求

   

  

编译速度

关于编译速度，我们最关心的可能还是编译Debug包的速度，尤其是增量编译的速度，希望可以做到更加快速的调试。

 

• 编译时间，把Java或者Kotlin代码编译为“.class”文件，然后通过dx编译为dex文件，对于增量编译，我们希望编译尽可能少的代码和资源，最理想的情况是只编译变化的部分。

• 安装时间，我们要先经过签名校验，校验成功后会有一大堆的文件拷贝工作，例如APK文件、Library文件、Dex文件等。之后我们还需要变Odex文件，对于增量编译，最好的优化即使直接应用新的代码，无需重新安装APK。
  对于增量编译，Gradle的官方方案是Instant Run。在Android Plugin2.3之前，它使用multidex实现，之后使用Android 5.0新增的Split APK机制，如图所示，资源和Manifest都放在Base APK中，在Base APK中代码只有Instant Run框架，应用本身的代码都在Split APK中。

   

  

   

  Instant Run有三种模式，如果是热交换和温交换，我们都无需重新安装新的Split APK，他们的区在于是否重启Activity。对于冷交换，我们需要通过adb install-multiple -r -t重新安装改变Split APK，应用也需要重启。
  无论哪一种模式，我们都不需要重新安装Base APK，看起来效果不错，但是它的性能依然非常糟糕，主要原因是：

• 多进程问题，如果应用存在多进程，热交换和温交换都不成生效。
• Split APK安装问题，虽然Split APK的安装不会生成Odex文件，但是这里依然会有签名校验和文件拷贝（APK安装的乒乓机制），这个时间可能需要几秒到几十秒，是不能接受的。
• javac问题，在Gradle 4.6之前，如果项目中运用了Annotation Processor，本次修改以及它依赖的模块需要全量javac，而这个过程非常慢。
  编译读优化建议：
• 更换编译机器
• Build cache
• 升级Gradle和SDK Build Tools
• 使用Buck
  最近几个版本Google使用AAPT2替换了AAPT来编译Android资源，AAPT2实现了资源的增量编译。

代码优化

对于debug包编译，我们更关心速度，但对于Release包来说，我们更在意应用的性能，因而代码优化更加重要。

ProGuard

加入ProGuard之后，应用的构建过程如下：

 

 

ProGuard主要有混淆、裁剪和优化三大功能，它的整个处理流程是：

 

其中优化包括内联、修饰符、合并类和方法等30多种。

d8

Android Studio 3.0推出了d8， 并在3.1正式成为默认工具，它的作用是将“.class”文件编译为Dex文件，取代之前的dx工具。

 

 

d8除了更快的编译速度之外，还有一个优化是减少生成Dex大小。

R8

R8在Android Studio 3.1中引入，目标是取代ProGuard和d8，R8可以把“.class”文件变成Dex。

 

 

同时R8还支持ProGuard中混淆、裁剪、优化三大功能，R8的最终目的，一个是加快编译速度，一个更强大的代码优化。

ReDex

Facebook内部的很多项目都已经全部切换到ReDex，不再使用ProGuard，跟ProGuard不同的是，它直接输入的对象是Dex，而不是“.class”文件，也就是直接针对最终产物的优化。

• Interdex：类重排和文件重排、Dex分包优化
• Oatmeal：直接生成Odex文件
• stripDebugInfo：去除Dex中的Debug信息

持续交付

Gradle、Buck、Bazel它们代表的都是狭义上的编译，广义上的编译应该包含打包构建、Code Review、代码工具管理、代码扫描等流程，也就是业界最近经常提起的持续集成。

 

 

目前最重用的持续集成工具有Jenkins、GitLab CI、Travis CI等，

• 自定义代码检查
• 第三方代码检查
• Code Review