前言
近期導入了一個項目,因為種種原因始終是失敗昔汉,各種引入錯誤,不是這個就是那個,歸根到底還是對gradle相關知識不夠了解靶病,今天來整理一下会通。
升級3.x.x變化
Gradle近期變化
android studio版本升級到3.0.0已經(jīng)有一段時間了,現(xiàn)在使用的是studio 3.1.2.那么(當然默認你的build:gradle:3.1.2娄周,二者要保持一致)涕侈。升級到3.x.x之后版本,有啥變化呢煤辨?
- 支持java8裳涛。
- 支持kotlin,默認安裝相關插件。
- gradle編譯速度有所加速众辨。
依賴變化
3.0.0之前 | 3.0.0之后 | 說明 |
---|---|---|
compile | implementation | 將該依賴隱藏在內(nèi)部端三,而不對外部公開。比如:app依賴于moudle1鹃彻,而moudle1 implementation Glide庫,那么app如果直接引用moudle1郊闯,可以使用moudle1中采用implementation依賴的Glide庫嗎?答案是:不可以蛛株!(之前是可以的)团赁,app需要自己依賴Glide才可以使用.這么做的好處是雖然使用起來復雜了但是做到降低偶合興提高安全性。 |
api | 完全等同于compile指令沒區(qū)別 | |
provided | compileOnly | 只在編譯時有效谨履,不會參與打包 ,可以避免包沖突 |
apk | runtimeOnly | 只在生成apk的時候參與打包欢摄,編譯時不會參與 |
testCompile | testImplementation | testCompile 只在單元測試代碼的編譯以及最終打包測試apk時有效 |
debugCompile | debugImplementation | debugCompile 只在debug模式的編譯和最終的debug apk打包時有效 |
releaseCompile | releaseImplementation | Release compile 僅僅針對Release 模式的編譯和最終的Release apk打包 |
Project build.gradle
咱們一個一個解釋其含義:
- buildscript:用來加載gradle腳本自身需要使用的資源,可以聲明的資源包括依賴項、第三方插件笋粟、maven倉庫地址等
- repositories表示代碼倉庫的下載來源
- jcente 是一個新的中央遠程倉庫怀挠,兼容maven中心倉庫,而且性能更優(yōu).
- google 是google的代碼托管倉庫
- dependencies一般是執(zhí)行Gradle需要的gradle工具矗钟。
- classpath 執(zhí)行gradle需要的工具地址唆香,一般版本號同studio版本保持一致
- allproject 是整個項目的配置曙痘,比如allproject 中的repositories和上面buildscript的區(qū)別就是:前者allproject是整個項目本身需要的依賴媳禁,后者是gradle腳本執(zhí)行所需依賴(Gradle插件)嘉蕾,分別是對應的maven倉庫和插件依賴等
- task clear 運行gradle clean時,執(zhí)行此處定義的task. 該任務繼承自Delete东涡,刪除根目錄中的build目錄。
常見的遠程依賴方式
方式一
implementation 'com.android.support.constraint:constraint-layout:1.1.2'
方式二
implementation group: 'com.android.support.constraint', name: 'constraint-layout', version: '1.1.2'
方式三
implementation('com.android.support.constraint:constraint-layout:1.1.2') {
//不同版本同時被依賴時倘待,那么強制依賴這個版本的疮跑,默認false
force = true
//exclude可以設置不編譯指定的模塊,有三種寫法:
exclude module: 'abc'
exclude group: 'bcd'
exclude group: 'abc', module: 'bcd'
//禁止依賴的傳遞凸舵,gradle自動添加子依賴項,默認為true.
transitive = true
}
當然我們這里的exclude 的‘a(chǎn)bc’等內(nèi)容是不存在的祖娘,只是給大家演示,由此也引出了exclude的一個作用啊奄,避免依賴包沖突渐苏。那么除了采用exclude這種方式掀潮,我們還有沒有別的方法呢,答案當然是有了琼富,那就是統(tǒng)一為所有依賴指定依賴包的版本仪吧,如下:
configurations.all {
resolutionStrategy.eachDependency { DependencyResolveDetails details ->
def requested = details.requested
if (requested.group == 'com.android.support') {
if (!requested.name.startsWith("multidex")) {
details.useVersion '28.0.0-rc01'
}
}
}
}
在 project 的 build.gradle 中添加如下的代碼,該代碼的意思是:在項目構建時鞠眉,遍歷所有依賴薯鼠,然后 com.android.support 包下的依賴替換同一個版本。但此方法也有弊端:就是每次構建的時候械蹋,多了一個遍歷過程出皇,會加長構建時間。因此哗戈,推薦使用 exclude 關鍵字排除恶迈。
那我們?nèi)绾闻袛嗍悄菐讉€library的文件沖突了呢?
首先studio會先報出該錯誤,在log日志中會有某個moudle的信息谱醇。然后我們需要一個命令:
./gradlew -q <模塊名>:dependencies
如:gradlew -q app:dependencies 查看app這個module的依賴其他庫的信息暇仲,看看有沒有沖突。
該命令能打印出該模塊所有的依賴樹信息,然后我們根據(jù)具體log信息副渴,采用exclud方式解決問題奈附。
本地依賴
Jar包依賴
arr文件的依賴
- 首先先聲明aar包存放的路徑聲明
repositories {
flatDir {
dirs 'libs' //此處聲明存放路徑為lib文件夾下
}
}
-
其次依賴引入
implementation(name: 'LibReplayDecode-release', ext: 'aar')
so文件的依賴
聲明下so文件的存放路徑即可
sourceSets {
main {
//配置so加載目錄
jniLibs.srcDirs = ['libs']
}
}
當然也可以在main目錄下新建jniLibs目錄,這是so文件默認的放置目錄煮剧,不過本人一般不習慣這樣斥滤,還有需要注意:并不是將so文件直接放入lib文件夾下,而是需要建立對應的ABI目錄下(Android 設備的CPU類型通常稱為”ABIs”),也就是說不同的armeabi文件是為了專門針對不同Android手機下CPU架構的兼容勉盅,存放so庫佑颇。如圖:
其他
用過butterknife的同志一定對annotationProcessor不陌生吧,它是一個編譯期注解的依賴。這種方式是只在編譯的時候執(zhí)行依賴的庫草娜,但是庫最終不打包到apk中挑胸。結(jié)合編譯期注解的作用,他是用來生成代碼的宰闰,本身在運行時是不需要的茬贵,那么它與我們上面說的與compileOnly的區(qū)別是什么呢?
annotationProcessor作用是編譯時生成代碼移袍,編譯完真的就不需要了解藻,compileOnly是有重復的庫,為的是剃除只保留一個庫葡盗,最終還是需要的螟左。