欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  移动技术

用Android Studio3.0新功能加快构建速度

程序员文章站 2023-11-21 16:37:10
android studio3.0很多新的功能,他们可以直接加快android studio的构建速度从而加快开发效率,构建速度直接影响到开发效率,浪费时间即浪费生命,可以...

android studio3.0很多新的功能,他们可以直接加快android studio的构建速度从而加快开发效率,构建速度直接影响到开发效率,浪费时间即浪费生命,可以通过修改一些配置,优化下构建速度。

android studio3.0之前的做法

通过配置dex 资源缩短构建时间

gradle 添加以下代码

android {
 ...
 dexoptions {
  maxprocesscount 4 // this is the default value
  javamaxheapsize "2g"
 }
}

maxprocesscount

设置可以并行启动的 dex 进程的最大数量

javamaxheapsize 设置 dex 操作的最大内存分配池大小
根据自己电脑的配置,设置这两个值,通常情况下这两个值越大越好

启用 dexing-in-process 和增量 java 编译

android plugin for gradle 版本 2.1.0 及更高版本还引入了其他的构建流程改进,包括增量 java 编译和 dexing-in-process。增量 java 编译默认情况下处于启用状态,这种编译方式仅对发生变化或需要重新编译的源代码部分进行重新编译,可以缩短开发过程中的编译时间。

dexing-in-process 在构建流程而不是单独的外部 vm 流程中执行 dexing。这样不仅可以让增量构建更快,也可以显著提高完整构建的速度。要启用此功能,您需要将 gradle 后台进程的最大堆大小设置为至少 2048 mb。要进行设置,您可以将以下代码包含到项目的 gradle.properties 文件中

org.gradle.jvmargs = -xmx2048m

如果您已经在模块级别的 build.gradle 文件中为 javamaxheapsize 定义值,则需要将后台进程的最大堆大小设置为 javamaxheapsize 的值 + 1024 mb。例如,如果您已将 javamaxheapsize 设为“2g”,则需要将以下代码添加到项目的 gradle.properties 文件中:

org.gradle.jvmargs = -xmx3072m

3.0之后的做法

使用用d8 编译器作为dex 编译器

android studio3.0 包含了一个新的可选择dex编译器,叫做d8,不久它将替换掉旧的dx编译器,现在可以选择使用新的编译器,dex编译直接影响到app的构建时间,dex文件大小,和运行时的性能,当使用新的d8编译器,d8编译更快和输出更小的.dex文件,并且相同或者更好的app运行时性能。要想使用d8编译器,把以下代码添加到工程的gradle.properties 文件即可

android.enabled8=true

使用新的依赖方式

也就是指dependencies代码块的引用

dependencies{
  compile project('xxx')
  compile 'com.github.bumptech.glide:glide:3.7.0'
}

android gradle 3.0 插件有4种引入方式
* implementation 相当于原来的compile
* api 相当于原来的compile
* compileonly 相当于原来的provided
* runtimeonly 相当于原来的apk

一般来说实际中主要用到的是compile
为了提高构建速度
替换成

implementation project('xxx')
implementation 'com.github.bumptech.glide:glide:3.7.0'
api project('xxx')
api 'com.github.bumptech.glide:glide:3.7.0'

那这两者有什么区别呢

此时需要注意的一个地方,例如一个叫a的lib里面用implementation引用一个b库,又有一个c的module(不管是lib还是app)引用了a,这个c的module是引用了不了b的,也就是不能使用b库里面的类和方法。这也是为什么使用implemention会加快构建速度的原因,可以减少重复编译。要想引用b到的库,可以使用api。在3.0中,api用法可以完全可以替换之前的compile,不用担心编译问题。

简单总结下:

implementation:c引用a,即使a库implementation方式引用b,c也不会引用b

api :c引用a,并且a库用api方式引用b,c会引用b

compileonly 只依赖库用来编译,不会把库打包进apk,在一些特定的场景很有用

runtimeonly 不用来编译,但是会打包到apk,这个方式是deprecated(不推荐使用)的

参考

配置构建

migrate to android plugin for gradle 3.0.0