In traditional project development, we build the architecture of the project in an integrated way. What is called integration? In my understanding, it means that the whole project has a module, and different library libraries are created according to the needs of functions, and dependencies are realized through gradle.

What is called componentization? In my understanding, there will be multiple modules in a project, and this module can change its identity to library when necessary, and become the dependency of the main module, which is our shell project.

Why would you want to try componentization? There are two visions:

1. During development, you don’t need to package the entire app. Realize the separation of the test package of the test students and the self-test package of the developers

2. Reduce packaging time during development self-test.

So that’s my understanding of componentization so far, and the routing part, we’ll talk about it in sections. To solve the two problems in the above vision, we can do the following configuration.

Start step 1,2,3…

1. Create a Boolean variable in your project’s build.gradle that determines whether to compile the project in integrated or componentized mode. Configure buildConfig as well. Easy to judge in the code.

Gradle’s introduction mechanism is not based on documentation, but subjective inference. Gradle reads from the build.gradle file, defines variables for the entire project by Ext, and applies from other Gradle configuration files. Functions and variables configured in a project are available throughout the project.

2. The configuration in the library to be made componentalized is mainly to switch whether plugin is library or Module, and whether to display the application Id in default. There may be too many dependent libraries, so mutidex needs to be configured to solve the problem of 65535. Def is used to define variables inside child modules.

3. Configure where you depend on the Library, the main Module. If the configuration is integrated, that is, isRelease is true, the dependency can be relied on. Otherwise, the dependency will be repeatedly introduced during compilation, and the compilation will fail. At the same time, configure the buildConfig variable in defaultConfig to facilitate the use of code, function switch

// If it is an integrated mode, do the release. Implementation Project (':YoungWear')} 4 Configure two AndroidManifest, as module there is Application, at the same time according to mutidex configuration plan configure module, the next is some core code configuration // configure resource path, convenient test environment. Packaging is not integrated into the formal environment sourceSets {main {if (! IsRelease) {/ / if is componentized mode, requires a separate runtime manifest the srcFile 'SRC/main/debug/AndroidManifest. XML'} else {/ / integration mode, The whole package apk manifest. SrcFile 'SRC/main/AndroidManifest. XML' Java {/ / release the debug directory file does not need to merge into the main project exclude '/ debug / * * * *' }}}}Copy the code

In Windows, run gradlew compileDebugSource — stacktrace-info to check whether the compileDebugSource can be successfully compiled. In Terminal, run gradlew compileDebugSource — stacktrace-info to run gradlew compileDebugSource. When it is used AS module, you can see the icon in the following picture in AS and it proves that the configuration is successful. You can directly install APK to the mobile phone.