這篇文章主要講解了“Gradle的實(shí)用技巧有哪些”,文中的講解內(nèi)容簡(jiǎn)單清晰,易于學(xué)習(xí)與理解,下面請(qǐng)大家跟著小編的思路慢慢深入,一起來研究和學(xué)習(xí)“Gradle的實(shí)用技巧有哪些”吧!
10年的阜新網(wǎng)站建設(shè)經(jīng)驗(yàn),針對(duì)設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對(duì)一服務(wù),響應(yīng)快,48小時(shí)及時(shí)工作處理。成都全網(wǎng)營(yíng)銷推廣的優(yōu)勢(shì)是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同,自動(dòng)調(diào)整阜新建站的顯示方式,使網(wǎng)站能夠適用不同顯示終端,在瀏覽器中調(diào)整網(wǎng)站的寬度,無(wú)論在任何一種瀏覽器上瀏覽網(wǎng)站,都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì),從而大程度地提升瀏覽體驗(yàn)。創(chuàng)新互聯(lián)從事“阜新網(wǎng)站設(shè)計(jì)”,“阜新網(wǎng)站推廣”以來,每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。
有時(shí)我們?cè)诜治鲆蕾嚊_突時(shí),需要查看依賴樹,我們常用的查看依賴樹的命令為
gradlew app:dependencies
不過這種命令行方式查看依賴樹出來的信息太多,看的有些費(fèi)勁
所以官方又推出了Scan工具來幫助我們更加方便地查看依賴樹
在項(xiàng)目根目錄位置下運(yùn)行g(shù)radle build \--scan即可,然后會(huì)生成 HTML 格式的分析文件的分析文件
分析文件會(huì)直接上傳到Scan官網(wǎng),命令行最后會(huì)給出遠(yuǎn)程地址
第一次跑會(huì)讓你在 Scan 官網(wǎng)注冊(cè)一下,郵件確認(rèn)后就能看了
scan 工具是按照依賴變體挨個(gè)分類的,debugCompileClassPath 就是 dedug 打包中的依賴包了
如上,使用這種方式分析依賴樹更加方便簡(jiǎn)潔
如下所示,我們常常使用ext來管理依賴
dependencies { implementation fileTree(include: ['*.jar'], dir: 'libs') implementation rootProject.ext.dependencies["appcompat-v7"] implementation rootProject.ext.dependencies["cardview-v7"] implementation rootProject.ext.dependencies["design"] implementation rootProject.ext.dependencies["constraint-layout"] annotationProcessor rootProject.ext.dependencies["glide_compiler"] ... }
這樣雖然實(shí)現(xiàn)了依賴的統(tǒng)一管理,但是隨著項(xiàng)目越來越大,依賴也會(huì)越來越多,常常會(huì)有幾十甚至上百行,導(dǎo)致build.gradle越來越長(zhǎng)
有沒有一種好的方式不在 build.gradle 中寫這么多的依賴配置?
有,就是使用循環(huán)遍歷依賴。
示例如下,首先添加config.gradle
ext{ dependencies = [ // base "appcompat-v7" : "com.android.support:appcompat-v7:${version["supportLibraryVersion"]}", ... ] annotationProcessor = [ "glide_compiler" : "com.github.bumptech.glide:compiler:${version["glideVersion"]}", ... ] apiFileDependencies = [ "launchstarter" :"libs/launchstarter-release-1.0.0.aar" ] debugImplementationDependencies = [ "MethodTraceMan" : "com.github.zhengcx:MethodTraceMan:1.0.7" ] ... implementationExcludes = [ "com.android.support.test.espresso:espresso-idling-resource:3.0.2" : [ 'com.android.support' : 'support-annotations' ] ] ... }
然后在build.gradle中配置如下:
apply from config.gradle ... def implementationDependencies = project.ext.dependencies def processors = project.ext.annotationProcesso def implementationExcludes = project.ext.implementationExcludes dependencies{ // 處理所有的 xxximplementation 依賴 implementationDependencies.each { k, v -> implementation v } // 處理 annotationProcessor 依賴 processors.each { k, v -> annotationProcessor v } // 處理所有包含 exclude 的依賴 implementationExcludes.each { entry -> implementation(entry.key) { entry.value.each { childEntry -> exclude(group: childEntry) } } } ... }
這樣做的優(yōu)點(diǎn)在于
1.后續(xù)添加依賴不需要改動(dòng)build.gradle,直接在config.gradle中添加即可
2.精簡(jiǎn)了build.gradle的長(zhǎng)度
上面介紹了通過config.gradle管理依賴的方法
在我們添加Gradle依賴時(shí),還有一些痛點(diǎn)
1.不支持代碼提示
2.不支持單擊跳轉(zhuǎn)
3.多模塊開發(fā)時(shí),不同模塊相同的依賴需要復(fù)制粘貼
使用buildSrc+kotlin可以解決這個(gè)問題
效果如下:
由于buildSrc是對(duì)全局的所有module的配置,所以可以在所有module中直接使用
這里就不多介紹了,詳細(xì)開發(fā)及引入buildSrc的過程可見:
[譯]Kotlin + buildSrc:更好的管理Gadle依賴
buildSrc vs includeBuild
上面介紹的方法使用的是buildSrc,使用起來比較方便
不過它的缺點(diǎn)在于構(gòu)建速度上會(huì)慢一些,使用includeBuild可以實(shí)現(xiàn)同樣的效果
兩者實(shí)現(xiàn)的最終效果是差不多的
詳細(xì)實(shí)現(xiàn)可見:【奇技淫巧】除了 buildSrc 還能這樣統(tǒng)一配置依賴版本?巧用 includeBuild
我們?cè)陂_發(fā)中,引入一些插件時(shí),有時(shí)需要在build.gradle中引入一些配置,比如greendao,推送,tinker等
這些其實(shí)是可以封裝在相應(yīng)gradle文件中,然后通過apply from引入
舉個(gè)例子,例如在我們使用greendao數(shù)據(jù)庫(kù)時(shí),需要在build.gradle中指定版本
這種時(shí)候應(yīng)該新建一個(gè)greendao-config.gradle
apply plugin: 'org.greenrobot.greendao' //greenDao指定版本和路勁等 greendao { //數(shù)據(jù)庫(kù)的schema版本,也可以理解為數(shù)據(jù)庫(kù)版本號(hào) schemaVersion 1 //設(shè)置DaoMaster、DaoSession、Dao包名,也就是要放置這些類的包的全路徑。 daoPackage 'com.example.ausu.big_progect.dao' //設(shè)置DaoMaster、DaoSession、Dao目錄 targetGenDir 'src/main/java' }
然后再在build.gradle中引入
apply from 'greendao-config.gradle'
這樣做主要有2個(gè)優(yōu)點(diǎn)
1.單一職責(zé)原則,將greendao的相關(guān)配置封裝在一個(gè)文件里,不與其他文件混淆
2.精簡(jiǎn)了build.gradle的代碼,同時(shí)后續(xù)修改數(shù)據(jù)庫(kù)相關(guān)時(shí)不需要修改build.gradle的代碼
隨著我們項(xiàng)目的越來越大,Library Module也越建越多,每個(gè)Module都有自己的build.gradle
但其實(shí)每個(gè)build.gradle的內(nèi)容都差不多,我們能不能將重復(fù)的部分封裝起來復(fù)用?
我們可以做一個(gè) basic 抽取,同樣將共有參數(shù)/信息提取到 basic.gradle 中,每個(gè) module apply,這樣就是減少了不少代碼量
apply plugin: 'com.android.library' apply plugin: 'kotlin-android' apply plugin: 'kotlin-android-extensions' apply plugin: 'kotlin-kapt' android { // 指定用于編譯項(xiàng)目的 API 級(jí)別 compileSdkVersion Versions.compileSDK // 指定在生成項(xiàng)目時(shí)要使用的 SDK 工具的版本,Android Studio 3.0 后不需要手動(dòng)配置。 buildToolsVersion Versions.buildTools // 指定 Android 插件適用于所有構(gòu)建版本的版本屬性的默認(rèn)值 defaultConfig { minSdkVersion Versions.minSDK targetSdkVersion Versions.targetSDK versionCode 1 versionName "1.0" } // 配置 Java 編譯(編碼格式、編譯級(jí)別、生成字節(jié)碼版本) compileOptions { encoding = 'utf-8' sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8 } kotlinOptions { jvmTarget = JavaVersion.VERSION_1_8.toString() } lintOptions { // lint 異常后繼續(xù)執(zhí)行 abortOnError false } } dependencies { implementation fileTree(dir: 'libs', include: ['*.jar']) ... }
然后在相應(yīng)的模塊的build.gradle中引入即可
apply from:"../basic.gradle" dependencies { api Deps.constraintLayout api Deps.retrofit }
這樣是不是簡(jiǎn)潔很多?讀者可根據(jù)項(xiàng)目實(shí)際情況判斷是否適合抽取basic.gradle使用
隨著項(xiàng)目越來越大,項(xiàng)目中的資源文件也越來越大,比如layout與drawable文件夾下的文件數(shù)量常??蛇_(dá)幾百甚至上千個(gè)
我們能不能像代碼一樣,對(duì)資源文件進(jìn)行分包呢?
答案是可以的,主要是利用gradle的sourceSets屬性
我們可以將資源文件像代碼一樣按業(yè)務(wù)分包,具體操作如下
1.新建res_xxx目錄
在 main 目錄下新建 res_core, res_feed(根據(jù)業(yè)務(wù)模塊命名)等目錄,在res_core中新建res目錄中相同的文件夾如:layout、drawable-xxhdpi、values等。
2.在gradle中配置res_xx目錄
android { //... sourceSets { main { res.srcDirs( 'src/main/res', 'src/main/res_core', 'src/main/res_feed', ) } } }
以上就完成了資源文件分包,這樣做主要有幾點(diǎn)好處
1.按業(yè)務(wù)分包查找方便,結(jié)構(gòu)清晰
2.strings.xml等key-value型文件多人修改可以減少?zèng)_突
3.當(dāng)刪除模塊或做組件化改造時(shí)資源文件刪除或遷移方便,不必像以前一樣一個(gè)個(gè)去找
當(dāng)我們的項(xiàng)目中Module越來越多,為了加快編譯速度,常常把Module發(fā)布成AAR,然后在項(xiàng)目中直接依賴AAR
但是我們有時(shí)候又需要修改AAR,就需要依賴于源碼
所以我們需要一個(gè)可以快速地切換依賴AAR與依賴源碼的方式
我們下面舉個(gè)例子,以retrofit為例
假如我們要修改retrofit的源碼,修改步驟如下:
1.首先下載retrofit,可以放到和項(xiàng)目同級(jí)的目錄,并修改目錄名為retrofit-source,以便區(qū)分
2.在settings.gradle文件中添加需要修改的aar庫(kù)的源碼project
include ':retrofit-source' project(':retrofit-source').projectDir = new File("../retrofit-source")
3.替換aar為源碼
build.gradle(android) 腳本中添加替換策略
allprojects { repositories { ... } configurations.all { resolutionStrategy { dependencySubstitution { substitute module( "com.squareup.retrofit2:retrofit") with project(':retofit-source') } } } }
如上幾步,就可以比較方便地實(shí)現(xiàn)aar依賴與源碼依賴間的互換了
這樣做的主要優(yōu)點(diǎn)在于
1.不需要修改原有的依賴配置,而是通過全局的配置,利用本地的源碼替換掉aar,侵入性低
2.如果有多個(gè)Module依賴于同一個(gè)aar,不需要重復(fù)修改,只需在根目錄build.gradle中修改一處
感謝各位的閱讀,以上就是“Gradle的實(shí)用技巧有哪些”的內(nèi)容了,經(jīng)過本文的學(xué)習(xí)后,相信大家對(duì)Gradle的實(shí)用技巧有哪些這一問題有了更深刻的體會(huì),具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián),小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章,歡迎關(guān)注!
網(wǎng)頁(yè)題目:Gradle的實(shí)用技巧有哪些
新聞來源:http://aaarwkj.com/article34/goocse.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供品牌網(wǎng)站設(shè)計(jì)、域名注冊(cè)、、Google、服務(wù)器托管、網(wǎng)站營(yíng)銷
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)