Gradle series 1: Groovy Gradle Series 2: AndroidStudio Gradle Series 3: Project Practice

preface

As far as I am concerned, Gradle has several applications: unified version number management, debug/release compilation mode differentiation, differentiated compilation, AAR automatic management, etc. After reading my explanation below, it can be directly applied to your project to improve production efficiency.

Unified version management

There will certainly be a number of open source libraries in the project, so we should make sure that every Moduler version number (minSdkVersion, compileSdkversion, etc.) is the same, so it is necessary to unify management: add it in the root directory build.gradle

ext {  

    // SDK And Tools  
    minSdkVersion = 14  
    targetSdkVersion = 23  
    compileSdkVersion = 23  
    buildToolsVersion = '24.0.2'  

    //Dependencies  
    supportLibraryVersion = '23.2.1'  

}  
Copy the code

Referenced in the build.gradle project:

apply plugin: 'com.android.application'  

android {                       
    compileSdkVersion rootProject.ext.compileSdkVersion  
    buildToolsVersion rootProject.ext.buildToolsVersion  

    defaultConfig {  
        applicationId 'com.mainiway.demo'  
        minSdkVersion rootProject.ext.minSdkVersion  
        targetSdkVersion rootProject.ext.targetSdkVersion  
        versionCode 1  
        versionName "1.0.0"}}Copy the code
Compile mode differentiation

In this scenario, logs in a project need to be distinguished by compile mode. Debug mode prints all logs and release version prints only Error level. How to distinguish compile mode in code? How to do this: There is a BuildConfig file in the project, located at: (Note: if you built release, then the release folder also contains this file, with the same content)

public final class BuildConfig {
  public static final boolean DEBUG = Boolean.parseBoolean("true");
  public static final String APPLICATION_ID = "com.lubansoft.bimview4phone";
  public static final String BUILD_TYPE = "debug";
  public static final String FLAVOR = "";
  public static final int VERSION_CODE = 9;
  public static final String VERSION_NAME = "4.0.0";
  // Fields from default config.
  public static final boolean PUBLISH_MODE = false;
}
Copy the code

The last field is customized by me. The previous fields are all included in this configuration file, including whether it is DEBUG, appID, versionCode, etc. A custom PUBLISH_MODE is used to distinguish whether the project is currently in publish mode:

    defaultConfig {
        ...
        buildConfigField "boolean"."PUBLISH_MODE"."true" // Publish mode (set to true for production, false for others). } this will write the value to BuildConfig at compile time, which will be set to BuildConfig on release daytrueThen the project changes the Log print rule based on this value: Java// Set the Log debuggingLogUtil.setDebugState(! BuildConfig.PUBLISH_MODE);Copy the code

Note: BuildConfig has a DEBUG field, which is true in DEBUG mode and false in release mode, and does not need to be set manually, but release mode does not have to be a release mode (it can also be a signature pack test).

Differential compilation

Requirement scenario: Some Jar packages are referenced in the project, which are only used in debug mode, but not at all used in release mode. However, compiling into the project will increase the size of the APP. Can we compile only in release mode? Create a directory like debugLibs in parallel with libs, and then differentiate the PUBLISH_MODE from build.gradle in your project:

dependencies {
    compile fileTree(include: ['*.jar'], dir: 'libs')
   if (! publishMode) {
        compile fileTree(include: ['*.jar'], dir: 'debuglibs')}... }Copy the code
Unified management AAR

This is not something that every project will use, but I highly recommend doing it. In actual projects, some basic controls and functions will be extracted and used as a separate project base library to be managed by a separate SVN branch. In development projects, a script will be written and packaged into AAR files to be used locally, which can be reused to different projects and shorten compilation time. For example, the base library generates three AArs according to UI, common logic, and business common modules:

repositories{
    flatDir{
        dirs '.. /libs'
    }
}

dependencies {
    ...
    compile(name: 'base_1. 2.0', ext: 'aar')
    compile(name: 'commombase_1. 0.0', ext: 'aar')
    compile(name: 'uibase_1. 2.0', ext: 'aar'If a new module is added to the base library, a new AAR will be generated, or if the product is iterated, the aar version number will also be iterated. Should we manually change the AAR version number in build.gradle each time? Method: You can see that I put these AArs in the libs folder of the root directory (folder optional), then get all the file names under this folder, dynamically reference. ```java def path = rootProject.getRootDir().getAbsolutePath() +"/libs"
    def configFile = new File(path)
// Get all files in the folder
    def files = configFile.listFiles(new FilenameFilter() {
        @Override
        boolean accept(File dir, String name) {
// File name filtering to prevent errors
            if (name.contains("base")) {
                return true;
            } else {
                return false
            }
        }
    })
    def aar1 = files[0].getName()
    def aar2 = files[1].getName()
    def aar3 = files[2].getName()
// Dynamically reference these AArs
    compile(name: '$aar1', ext: 'aar')
    compile(name: '$aar2', ext: 'aar')
    compile(name: '$aar3', ext: 'aar')
Copy the code

Is that good enough? Build. Gradle dependencies: < span style = “max-width: 100%; clear: both; Gradle fully supports this. Build an utils.gradle in the root directory

/ / gradle tools
// Get the base library version number
def getAARNames(a) {...// Return a String array
    return ["$lbName"."$aar1"."$aar2"."$aar3"]
}
ext {
// Take care of this line
    getAARNames = this.&getAARNames
}
Copy the code

In build.gradle use:

dependencies {
   ...
    // Get the aar filename, which is an array
    def aarList = getAARNames()
    compile(name: aarList[0], ext: 'aar')
    compile(name: aarList[1], ext: 'aar')
    compile(name: aarList[1], ext: 'aar')}Copy the code

And you’re done! The code is much cleaner.

Simplify the open source project directory structure

In practice, we will definitely use a lot of open source libraries in source code form, especially for UI-related codes, which can only be in source code form, so some of them are put into a directory as moduler and our app side by side. When the number of open source libraries reaches more than ten, the project structure seems to be divided between primary and secondary, and it is necessary to simplify it. Method: Create a folder like thirdPart directly in the root directory, put all the open source libraries in it, and configure the project structure in settings.gradle:

include ':bvcommon'.':app'.// This is the main project, the following are open source libraries
        ':thirdpart:PullToRefreshLibrary'.':thirdpart:datetimepicker-library'.':thirdpart:MultilevelTreeLibrary'.':thirdpart:FFmpegAndroid'.':thirdpart:autolinklibrary'.Copy the code