Preface
This article mainly introduces the use of
mainly include the following
- 1.GradleDependency tree query
- 2. Use loop optimizationGradleDependency management
- 3. Support code hintsGradleDependency management
- 4.GradleModular
- 5.LibraryModuleGradleCode reuse
- 6. Resource file subcontracting
- 7.AARQuick switch between dependency and source code dependency
1.GradleDependency tree query
Sometimes when we analyze dependency conflicts, we need to view the dependency tree. The command we commonly use to view the dependency tree is
gradlew App: the Dependencies
copy the code
However, there is too much information to view the dependency tree in this command line method, and it is a bit difficult to read,
so the official release
Run under the project root directory location
The analysis file will be uploaded directly to
. The first run will let you
as above, it is more convenient and concise to analyze the dependency tree in this way
2. Use loop optimizationGradleDependency management
As shown below, we often use
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" ]
...
}
Copy code
Although this achieves unified management of dependencies, as the project becomes larger and larger, there will be more and more dependencies, often with dozens or even hundreds of lines, resulting
Is there a good way to be absent
Yes, it uses a loop to traverse the dependencies.
The example is as follows, first add
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'
]
]
...
}
Copy code
Then in
apply from config.gradle
...
def implementationDependencies = project.ext.dependencies
def processors = project.ext.annotationProcesso
def implementationExcludes = project.ext.implementationExcludes
dependencies{
//Handle all xxximplementation dependencies
implementationDependencies.each {k, v -> implementation v}
//Handle annotationProcessor dependencies
processors.each {k, v -> annotationProcessor v}
//Process all dependencies that include exclude
implementationExcludes.each {entry ->
implementation(entry.key) {
entry.value.each {childEntry ->
exclude( group: childEntry)
}
}
}
...
}
Copy code
The advantages of this are
1. Subsequent addition of dependencies does not require changes
2. It's streamlined
3. Support code hintsGradleDependency management
Introduced above
added in us
1. Code prompt is
not supported 2. Click to jump is not supported
3. When multi-module development, the same dependencies of different modules need to be copied and pasted
use
effect is as follows:
As the
Not much introduction here, detailed development and introduction
[Translation] Kotlin + buildSrc: better management of Gadle dependencies
buildSrc vs includeBuild
The method described above uses
It s more convenient to use, but its disadvantage is that the build speed will be slower. Use
The final results achieved by the two are similar. The
detailed implementation can be seen: [Wonderful skill] In addition to buildSrc, can you also configure the dependent version in this way? Clever use of includeBuild
4.GradleModular
In our development, when we introduce some plug-ins, sometimes we need to
These can actually be encapsulated in the corresponding
, for example, when we use
In this case, you should create a new one
apply plugin: 'org.greenrobot.greendao'
//greenDao specifies the version and road King, etc.
greendao {
//The schema version of the database can also be understood as the database version number
schemaVersion 1
//Set the DaoMaster, DaoSession, and Dao package names, that is, the full path of the packages where these classes are to be placed.
daoPackage'com.example.ausu.big_progect.dao '
//Set DaoMaster, DaoSession, Dao directory
targetGenDir'src /main/java'
}
Copy code
And then again
from Apply 'greendao-config.gradle'
duplicated code
This has two main advantages:
1. The single responsibility principle will
2. Simplified
5.LibraryModuleGradleCode reuse
As our project gets bigger and bigger,
But actually each
We can make a
apply plugin: 'com.android.library'
apply plugin: 'kotlin-android'
apply plugin: 'kotlin-android-extensions'
apply plugin: 'kotlin-kapt'
android {
//Specify the API level used to compile the project
compileSdkVersion Versions.compileSDK
//Specify the SDK tool version to be used when generating the project. Manual configuration is not required after Android Studio 3.0.
buildToolsVersion Versions.buildTools
//Specify the default value of the version attribute of the Android plug-in applicable to all build versions
defaultConfig {
minSdkVersion Versions.minSDK
targetSdkVersion Versions.targetSDK
versionCode 1
versionName "1.0"
}
//Configure Java compilation (coding format, compilation level, generated bytecode version)
compileOptions {
encoding = 'utf-8'
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
kotlinOptions {
jvmTarget = JavaVersion.VERSION_1_8.toString()
}
lintOptions {
//Continue to execute
abortOnError after lint exception false
}
}
dependencies {
implementation fileTree( dir: 'libs' , include: [ '*.jar' ])
...
}
Copy code
Then in the corresponding module
apply from: "../basic.gradle"
dependencies {
api Deps.constraintLayout
api Deps.retrofit
}
Copy code
Isn't this much more concise? Readers can judge whether it is suitable for extraction according to the actual situation of the project
6. Resource file subcontracting
As the project gets bigger and bigger, the resource files in the project also get bigger and bigger, such as
Can we subcontract resource files like code?
The answer is yes, mainly by using
We can subcontract resource files by business like code, the specific operations are as follows
1. Create a new directory res_xxx
in
2. In
android {
//...
sourceSets {
main {
res.srcDirs(
'src/main/res' ,
'src/main/res_core' ,
'src/main/res_feed' ,
)
}
}
}
Copy code
The above completes the subcontracting of resource files. There are several advantages to doing this
. 1. It is convenient to find by business subcontracting, and the structure is clear
2.
. 3. It is convenient to delete or migrate resource files when deleting modules or doing component transformation, so you don t have to look for them one by one as before.
7.AARQuick switch between dependency and source code dependency
When our project
But we sometimes need to modify
so we need a system that can quickly switch dependencies
Let s take an example below to
if we want to modify
1. First download
2.
the include ': Retrofit-Source'
Project ( ': Retrofit-Source' ) = .projectDir new new File ( "../retrofit-source" )
copy the code
3. Replace
allprojects {
repositories {
...
}
configurations.all {
resolutionStrategy {
dependencySubstitution {
substitute module( "com.squareup.retrofit2:retrofit" ) with project( ':retofit-source' )
}
}
}
}
Copy code
The above steps can be implemented more conveniently
. The main advantages of this are
1. No need to modify the original dependency configuration, but replace it with the local source code through the global configuration
2. If there are multiple
summary
This article mainly introduces several practical
If you find any shortcomings in this article, please point it out in the comment area~
Reference
Gradle Scan use introduction,
use cycle to optimize
Android refactoring | Continuous optimization and unified management of Gradle
Android res resource subcontracting