您好,登錄后才能下訂單哦!
Android Studio項目中Gradle依賴的作用是什么?針對這個問題,這篇文章詳細介紹了相對應的分析和解答,希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
一、不同類型的library引入方案:
1、本地Module library依賴:
通過這種方式依賴的弊端是每次都需要構建module,當module比較多時構建非常耗時,建議控制module的依賴數量,避免構建耗時
//module需要在項目根目錄下的settings.gradle中通過include引入 implementation project(':librarydict')
2、本地二進制library依賴:jar和aar:
本地的jar和aar需要放在module的libs文件夾下,通過這種方式依賴的弊端是不知道jar和aar的版本號,如果要按照這種方式依賴,建議將jar/aar的名字加上版本信息,方便確認版本
依賴jar:
// 可以一條依賴引入libs下所有的jar implementation fileTree(dir: 'libs', include: ['*.jar']) // 也可以指定依賴某一個或幾個jar implementation files('libs/dict-v120.jar', 'libs/download-v151.jar')
依賴aar:
// 在module的build.gradle中增加如下語句: repositories { flatDir { dirs 'libs' } } // 可以一條依賴引入libs下所有的aar implementation fileTree(dir: 'libs', include: ['*.aar']) // 也可以指定依賴某一個aar implementation (name: 'library-download', ext: 'aar')
3、遠程二進制library依賴:
為了安全起見,建議搭建公司內部的私有maven倉庫,統一管理依賴的library,公司內部的公共library不要使用公共的maven倉庫。通過這種方式依賴相比于前兩種方案都要更優,且配置靈活,可以根據實際需求調整
// 依賴明確的版本,標明group、name和version implementation group: 'com.android.demo', name: 'library-dict', version: '1.2.0' // 通常按照如下方式簡寫即可 implementation 'com.android.demo:library-dict:1.2.0' // 也可以不指定版本,將version改為"+",當遠程倉庫有更新的版本后,構建時會拉取最新的版本。 // 好處是可以始終依賴最新的library;弊端是有可能library的改動導致編譯不過或者功能變更不 // 穩定,因為每次都需要檢查是否有最新版本,所以構建效率會低一些 implementation 'com.android.demo:library-dict:+'
// 對于有多個APP,依賴內部統一SDK的情況時,可以將gradle文件放在服務器,遠程控制統一依 // 賴版本,避免因為各個APP依賴的SDK版本不統一導致很難管理和維護 // 遠程http://172.28.2.93/remote/library-config.gradle: ext.libraryBuildConfig = [ deps: [ "dict-library" : 'com.android.demo:library-dict:1.2.0', "download-library" : 'com.android.demo:library-download:1.5.1', ] ] // 項目根目錄下的build.gradle全局引入: apply "http://172.28.2.93/remote/library-config.gradle" ext { dependencies = [ "dict-library" : libraryBuildConfig.deps.'dict-library', "download-library" : libraryBuildConfig.deps.'download-library', ] } // 在module的build.gradle中依賴: implementation rootProject.ext.dependencies["dict-library"] implementation rootProject.ext.dependencies["download-library"]
總結如下:
二、不同依賴配置方式的區別:compile、implementation、api
從Android Gradle plugin 3.0開始,對于依賴包的配置方式,引入了implementation和api,使用Android Studio新建項目時,原來用compile的地方全部默認被替換成了implementation 比如:
dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) compile 'com.android.support:appcompat-v7:27.1.1' compile 'com.android.support.constraint:constraint-layout:1.1.3' }
變成下面的樣子:
dependencies { implementation fileTree(dir: 'libs', include: ['*.jar']) implementation 'com.android.support:appcompat-v7:27.1.1' implementation 'com.android.support.constraint:constraint-layout:1.1.3' }
網上查資料時,依賴配置方式還有:provided、api、apk、compileOnly、runtimeOnly、渠道名+Compile,差異主要在于構建內容和參與構建的時機,多樣的配置方式滿足了開發者的花樣需求,具體區別如下:
1、implementation:
依賴包中依賴的library只能在依賴包內部使用,主工程無法訪問依賴包依賴的library中的類和方法。使用場景:SDK開發中對第三方library有依賴,希望控制SDK的大小、不想因為和宿主工程引用的同一個依賴包版本不同導致編譯沖突時特別適合。
因為當依賴包依賴的library有改動時,只會重新編譯library和依賴包,不需要重新編譯宿主,所以構建速度會快一些。
對于各個渠道還可以單獨依賴屬于渠道特有的包,通過渠道名+implementation指定,比如debugImplementation、releaseImplementation、testImplementation。
2、api(原compile):
會將依賴包中依賴的其它library一同編譯和打包到apk中,宿主工程可以使用依賴包中依賴的其它library的類和方法
對于各個渠道還可以單獨依賴屬于渠道特有的包,通過渠道名+api/compile指定,比如debugApi、releaseApi、testApi
3、compileOnly(provided):
主要是為了方便程序編譯通過的,不會打包到apk中,使用場景:android系統有這個API,但編譯時需要引入才能構建通過,比如系統的APK依賴framework.jar、gson庫等
4、runtimeOnly(原apk):
只是打包到apk中,不參與編譯,不能在代碼中直接調用依賴包的代碼,否則會在編譯時出錯。
關于Android Studio項目中Gradle依賴的作用是什么問題的解答就分享到這里了,希望以上內容可以對大家有一定的幫助,如果你還有很多疑惑沒有解開,可以關注億速云行業資訊頻道了解更多相關知識。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。