For reprinting, please specify the source: drawthin's brief book: http://www.jianshu.com/u/70318c7e4b5f

_has been busy, only recently has time to write out the pits encountered by component technology in the past actual project development. After all, there are some pits, others have traveled, we do not need to go ahead and die.
  

It is believed that many Android development apes will encounter such a project structure in project development:

When we develop a project, we usually subcontract the APP according to its function, such as putting a package on all pages, putting a package on the network, etc. When the project business scenario is single and the team is simple, this development mode is not a problem.

But when our APP business scenarios are more and more, business logic is more and more complex, and the coupling degree between classes and functional modules is more and more big, then the problem arises. Often Xiao Zhang changed the BUG at A, resulting in a new BUG at B and C. In case of meeting the boss's request again: Who and who will show me a module on my mobile phone alone tomorrow? At this time, the whole development team is undoubtedly in ruin.

Owing to the above reasons, we have to reconsider that when we design APP, we should design an architecture that meets the following requirements: reducing module coupling, high reuse, and facilitating team development. Consider component development at this time.

In fact, in the previous project development, in order to solve the above problems, the project has been divided into several modules to develop. But I don't know this is called component development. Take the project as an example, a taxi software similar to drip-drip was made a few days ago, because at the beginning of the project, it is impossible to make two APPs on the driver side and the user side. The cost is too high, so it is combined into one to make an APP.

The project is divided into four modules:

• Common:: Unified basic information configuration of the project, common class library, etc.
• Driver: driver module, depending on common.
• customer: Client, depending on common.
• main: project entrance, relying on driver, customer, responsible for the driver,costomer module request forwarding.

II. Specific Module Configuration

2.1 Project Unified Basic Information Configuration

• Configure the build tool version in the project root build.gradle, compile the sdk version, of course, you can also configure the version information of some tripartite libraries, and then refer to the OK in other modules to achieve the unified configuration switch of the project library version.

   ext {
    compileSdkVersion = 25
    buildToolsVersion = "25.0.2"
    minSdkVersion = 14
    targetSdkVersion = 23
    }

2.2 Global Debugging Switch Configuration (Used in the following 2.3 chapters)

• Add a debug switch to the project root gradle.properties

isLibrary=true

2.3 Specific Module Configuration ()

common module: build.gradle

apply plugin: 'com.android.library'
android {
//Reference to the configuration of the project root build.gradle
    compileSdkVersion rootProject.ext.compileSdkVersion
    buildToolsVersion rootProject.ext.buildToolsVersion

    defaultConfig {
        minSdkVersion rootProject.ext.minSdkVersion
        targetSdkVersion rootProject.ext.targetSdkVersion
    }
}
//Tripartite libraries used by driver and customer modules
dependencies {
    compile 'com.squareup.retrofit2:retrofit:2.3.0'//Packages required for Retrofit2
    compile 'com.squareup.retrofit2:converter-gson:2.3.0'//Gson dependency package of ConverterFactory
    compile 'com.squareup.retrofit2:converter-scalars:2.3.0'//Converter Factory's String dependency package
    compile 'com.android.support:appcompat-v7:25.0.0'
    //Golden Map
    compile 'com.amap.api:navi-3dmap:latest.integration'
    compile 'com.amap.api:search:latest.integration'
    compile 'com.amap.api:location:latest.integration'

    compile 'com.jakewharton:butterknife:8.4.0'
    compile 'com.android.support:design:25.0.0'
    compile 'com.android.support.constraint:constraint-layout:1.0.2'
}

Driver module build.gradle configuration: When we want to debug the driver module separately, we need to

apply plugin: 'com.android.application'

It is necessary to be dependent on by main module.

apply plugin: 'com.android.library'

At this time, we can use the debugging switch in 2.2. We can configure it in this way.

if (! isLibrary.toBoolean()) {
    apply plugin: 'com.android.application'
} else {
    apply plugin: 'com.android.library'
}

** Note 1:
When we use driver as lirbary, we can't use category as android.intent.category.LAUNCHER in Android Manifest. xml, because APP will merge Android Manifest. XML of all modules after packaging. At this time, if there are two categories in the merged Android Manifest. XML as android.intent.category.LAUNCHER's activity, two apk s will be installed simultaneously on the mobile phone. . * *
So we need to write Android Manifest. XML separately for Module as library and application, and then remove the configuration of application from Android Manifest. XML in the library directory.
Similar:

_Then add it under android node in build.gradle:

 sourceSets {
        main {
            if (isLibrary.toBoolean()) {
                manifest.srcFile 'src/main/library/AndroidManifest.xml'
            } else {
                manifest.srcFile 'src/main/release/AndroidManifest.xml'
                java {
                    //When themoduleAct aslibraryAt that time,libraryCatalogueAndroidManifest.xmlDocuments do not need to be merged into the main project
                    exclude 'library/**'
                }
            }
        }
    }

Note 2: When the module is a library, application Id cannot exist in build.gradle.

if (!isLibrary.toBoolean()){
            applicationId "com.XXX"
        }

• See driver for the configuration of customer module.

Configuration is basically at this point, when the project module can be debugged individually or as a whole by switching isLirbary.