團隊使用kotlin挺長時間了,一直以來都不太滿意kotlin的編譯速度,但是也能忍受。最近開了一個新項目,有不少同事從java過來的,他們就實在是受不了,優(yōu)化編譯速度就變得很重要了。
優(yōu)化之前和之后的對比
在優(yōu)化之前我們的一次完整編譯時間是2分21秒

image.png
具體的耗時任務(wù)在Run Tasks中:

image.png
可以看到具體的耗時任務(wù)如上,主要是kapt相關(guān)的編譯和編譯kotlin代碼,以及最后的transformClassedWithXXX。
優(yōu)化之后的完整編譯時間31s

image.png
優(yōu)化之后的增量編譯時間15s

image.png

image.png
優(yōu)化步驟:
1.優(yōu)化gradle配置:
在項目根目錄創(chuàng)建一個gradle.properties文件
//開啟gradle并行編譯,開啟daemon,調(diào)整jvm內(nèi)存大小
org.gradle.daemon=true
org.gradle.configureondemand=true
org.gradle.parallel=true
org.gradle.jvmargs=-Xmx4096m -XX:MaxPermSize=1024m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
//開啟gradle緩存
org.gradle.caching=true
android.enableBuildCache=true
//開啟kotlin的增量和并行編譯
kotlin.incremental=true
kotlin.incremental.java=true
kotlin.incremental.js=true
kotlin.caching.enabled=true
kotlin.parallel.tasks.in.project=true //開啟kotlin并行編譯
//優(yōu)化kapt
kapt.use.worker.api=true //并行運行kapt1.2.60版本以上支持
kapt.incremental.apt=true //增量編譯 kapt1.3.30版本以上支持
kapt.include.compile.classpath=false //kapt avoiding 如果用kapt依賴的內(nèi)容沒有變化,會完全重用編譯內(nèi)容,省掉最上圖中的:app:kaptGenerateStubsDebugKotlin的時間
在上面的配置中,我們首先調(diào)整了gradle的配置,然后開啟了緩存和kotlin和kapt的增量編譯。
如果項目中使用了kapt請使用最新版本的kapt,當(dāng)前寫該文章時kapt的最新版本為1.3.31
優(yōu)化app的build.gradle
1.在項目的app目錄中的build.gradle文件中修改:
//如果有用到kapt添加如下配置
kapt {
useBuildCache = true
javacOptions {
option("-Xmaxerrs", 500)
}
}
//在Android代碼塊中添加如下配置:(可優(yōu)化最上圖中transformClassDexBuilderForDebug的時間)
android {
dexOptions {
preDexLibraries true
maxProcessCount 8
}
}
2.其他不太重要的優(yōu)化,好像對時間影響不算特別大
優(yōu)化版本號的配置,如果是debug版本不要使用動態(tài)版本號
//原配置
defaultConfig {
...
minSdkVersion 19
targetSdkVersion 28
versionCode gitVersionCode()
versionName currentName()
...
}
//修改為
defaultConfig {
...
minSdkVersion 19
targetSdkVersion 28
versionCode 1
versionName "1.0.0"
...
}
applicationVariants.all { variant ->
...
if (variant.buildType.name == "release") {
versionName = currentName()
versionCode = gitVersionCode()
}
...
}
以前我們的配置上versionCode是使用的git的提交次數(shù)作為版本號的,在本地debug狀態(tài)的時候其實最好是寫死版本號,如果版本號變化會導(dǎo)致需要重新生成Manifest文件以及完整的編譯應(yīng)用,導(dǎo)致InstantRun無法使用(PS其實我們一直沒用InstantRun)。所以修改為寫死版本號,然后在applicationVariants中判斷如果是release才使用正常的版本號。然后還有一個就是使用依賴版本的時候,盡量不要使用+號的版本依賴,使用固定版本號速度會更快。
喜歡點擊+關(guān)注哦
