:ant::ant: 一种全新的android组件化方案,无需下沉公用代码,无需采用路由等硬编码方式分发sdk,独立维护组件暴露的SDK/IMPL,打破官方模块循环且支持组件间互相调用SDK,支持集成组件调试/组件独立运行。A brand new android componentization solution, no need to sink public code, no need to use hard coding to distribute sdk, independent maintenance component exposed SDK / IMPL, break the official module loop and support the call between components The SDK supports integrated component debugging/components to run independently.
With the advent of android 9.0 and new versions, the system has become more stable and closed, and the road to plug-in has become more difficult. Development has gradually shifted towards modular development. The reason for regression componentization is because any module function is stably split or combined into components. The concept of components in android engineering is not obvious. I have tried many solutions in the industry, and each has its own merits, but there is no plug-in that supports code isolation, supports independent debugging, and does not change any existing code.
From the very beginning, I learned that "WeChat's Modular Architecture Reconstruction Practice" began to focus on componentization, and benefited from contact with the US-based take-out/51 credit card/cat eye. I understand the same componentization, the project must meet the "module independence of different functional granularity", the business must meet the "functional independence", and the development must meet the "dependency isolation, interface-oriented programming". This is why my solution abandoned the use of routing schemes to forward apis. The wheel is more inclined to solve the "convenient debugging / full code isolation", and it is also convenient to support the binding and unbinding of the module api.
tip: The word module below refers to the native module created by android Studio. The term component means the module module processed by the plugin.
Complete code isolation (marking)
Using "interface-oriented" programming, abolishing hard-coded programming exposes apis (such as routing), relies on the SDK in the build/sync process, and injects IMPL into the assemable process.
Support circular dependencies(marking)
This is very important! For modules, because of the inability to circular dependencies, the respective exposed content needs to sink to the next module, and the component solves this problem by separating the SDK/IMPL.
Convenient integrated debugging
Debug based on module dependencies, without modifying the native plugin for dynamically modifying the library. (For example, the debug module relies on component A for component A functional testing), and supports multiple directory debugging for multiple components/android libraries/custom configurations.
Very low access costs
In the root project to declare the plugin and add configuration scripts, the plugin will be automatically injected into each subproject according to the configuration and complete sdk packaging.
Library layer
The basic class library, which stores the streamlined code, is highly reusable, and can be directly referenced by other modules, such as Utils, BaseActivity, etc.
Service layer
Independent modules that support a certain type of basic business functions, such as login services, skinning services, between the library layer and the component layer, can also be directly called by the app layer
Component layer
Complex business modules that aggregate multiple basic business functions, such as friends, nearby people, may use multiple service services, or you can use library directly.
App layer Application portal to aggregate multiple business modules, such as the main terminal or debugger
A good architecture needs to be highly available and easy to debug. The plugin supports debugging of any layer, and the Module of the service/component layer is turned into a component to break the limitations of traditional componentization.
The plugin divides the source code into SDK and IMPL by intervening in the module's build process, where the SDK is compiled into a jar and IMPL is all resources except the SDK.
Therefore, the dependencies of the module or component are converted to
In fact, dependent scenarios will change dynamically based on different build processes.
buildscript {
repositories {
maven { url 'https://jitpack.io' }
}
dependencies {
classpath "com.github.DSAppTeam:ComponentCornerstone:1.0.13
}
}
allprojects {
repositories {
maven { url 'https://jitpack.io' }
}
}
apply from: "./gradleScript/component.gradle"
+ library/src/sdk/<packagePath>/xxx.java or xxx.kt
link:AndroidModularArchiteture
As early as 17 years, WeChat has been published 微信Android模块化架构重构实践 In the article, it is related to the function of separating the module through the interface protection form (.apiization) and generating the corresponding 'SDK' project. Other projects rely on the compilation of this generated project. I used to separate the interface provided by the module into a project and package it into sdk, but this will cause sdk and impl to be divided into two modules, which is not easy to maintain and unsightly.The industry's excellent open source project Mis provides a code isolation idea, roughly:
By studying the ideas written by the source code reference authors, it is indeed a good method, the details of the logic see the source code. It is worth mentioning that sdk is a jar, not only can contain business APIs, but also data interface beans. In the process of plugin development,Thanks to the Mis author [EastWoodYang] (https://github.com/EastWoodYang) for giving me a lot of help and guidance!