Android modularization exploration and practice

Preface

Tim Berners-Lee, the inventor of the World Wide Web, once said when talking about design principles: "Simplicity and modularity are the cornerstones of software engineering; distribution and fault tolerance are the life of the Internet." This shows the importance of modularity in the field of software engineering.

Since 2016, modularization has been mentioned more and more in the Android community. With the continuous development of mobile platforms, the software on mobile platforms has gradually become more complex and bulky. In order to reduce the complexity and coupling of large software, and to adapt to the needs of module reuse, multi-team parallel development and testing, modularization has become imperative on the Android platform. The Alibaba Android team open-sourced their containerization framework Atlas at the beginning of the year, which largely illustrates the problems faced by the current Android platform in developing large-scale commercial projects.

What is modularity

So what is modularity? The book "Java Application Architecture Design: Modular Patterns and OSGi" defines it as: Modularity is a way of decomposing complex systems into better manageable modules.

The above description is too difficult to understand and not intuitive enough. The following analogy may be easier to understand.

We can think of software as a car. The process of developing a software is the process of producing a car. A car is composed of a series of modules such as the frame, engine, gearbox, wheels, etc. Similarly, a large commercial software is also composed of various modules.

These modules of a car are produced by different factories. A BMW engine may be produced by a factory in Germany, its automatic transmission may be produced by Jatco (one of the world's three largest transmission manufacturers) in Japan, and the wheels may be produced in a factory in China. Finally, they are sent to the BMW Brilliance factory to be assembled into a complete car. This is similar to what we call multi-team parallel development in the field of software engineering, and finally the modules developed by each team are packaged into an app that we can use.

An engine or a variable gearbox cannot be used in only one model. For example, the same Jatco 6AT automatic transmission can be installed in both BMW and Mazda models. This is just like module reuse in software development.

In winter, especially in the north, we may need to drive on snowy roads. For safety reasons, we often upgrade our road tires to snow tires. Tires can be easily replaced, which is what we call low coupling in software development. The upgrade and replacement of a module will not affect other modules, nor will it be restricted by other modules. This is also similar to the pluggable feature we mentioned in software development.

Modular layered design

The above analogy clearly illustrates the benefits of modularization:

• Multiple teams develop and test in parallel;
• Decoupling and reuse between modules;
• A module can be compiled and packaged separately to improve development efficiency.

In the article "Anjuke Android Project Architecture Evolution", I introduced the modular design of Anjuke Android. Here I will use it as an example. But first, we need to make a distinction between components and modules in this article.

• Component: refers to a single functional component, such as map component (MapSDK), payment component (AnjukePay), routing component (Router), etc.
• Module: refers to an independent business module, such as New House Module, Second House Module, Instant Messaging Module, etc.; modules have a larger granularity than components.

The specific design scheme is as follows:

The entire project is divided into three layers, from bottom to top:

• Basic Component Layer: As the name implies, the basic component layer is composed of some basic components, including various open source libraries and various self-developed tool libraries that are not related to the business;
• Business Component Layer: All components in this layer are business-related, such as the payment component AnjukePay and the data simulation component DataSimulator in the figure above;
• Business Module Layer: In Android Studio, each business corresponds to a separate module. For example, the Anjuke user app can be split into new house module, second-hand house module, IM module, etc. Each separate Business Module must comply with our own MVP architecture.

When we talk about modularization, we are actually splitting the various functional businesses at the business module layer into independent business modules. Therefore, the first step of modularization is to divide the business modules, but there is no universal standard for module division in the industry. Therefore, the granularity of division needs to be reasonably controlled according to the project situation, which requires a thorough understanding of the business and project. Take Anjuke as an example. We will divide the project into new house module, second-hand house module, IM module, etc.

Each business module in Android Studio is a Module, so we require each business module to be suffixed with Module in terms of naming. As shown in the following figure:

For modular projects, each individual Business Module can be compiled into an APK separately. It needs to be packaged and compiled separately during the development phase, and it needs to be compiled and packaged as a module of the project when the project is released. Simply put, it is an Application during development and a Library during release. Therefore, the following code needs to be added to the build.gradle of the Business Module:

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

isBuildModule is defined in gradle.properties in the project root directory:

 > isBuildModule = false  
 >

Similarly, there need to be two sets of Manifest.xml:

 sourceSets {
 main {
       if (isBuildModule.toBoolean()) {
           manifest.srcFile 'src/main/debug/AndroidManifest.xml'  
 } else {
           manifest.srcFile 'src/main/release/AndroidManifest.xml'  
 }
 }
 }

As shown in the figure:

AndroidManifest.xml in debug mode:

 <application
 ...
 >
 <activity
       android: name = "com.baronzhang.android.newhouse.NewHouseMainActivity"  
       android:label= "@string/new_house_label_home_page" >
 <intent-filter>
           < action android: name = "android.intent.action.MAIN" />
           <category android: name = "android.intent.category.LAUNCHER" />
 </intent-filter>
 </activity>
 </application>

AndroidManifest.xml in realease mode:

 <application
 ...
 >
 <activity
       android: name = "com.baronzhang.android.newhouse.NewHouseMainActivity"  
       android:label= "@string/new_house_label_home_page" >
 <intent-filter>
           <category android: name = "android.intent.category.DEFAULT" />
           <category android: name = "android.intent.category.BROWSABLE" />
           < action android: name = "android.intent.action.VIEW" />
           <data android:host= "com.baronzhang.android.newhouse"  
               android:scheme= "router" />
 </intent-filter>
 </activity>
 </application>

At the same time, we also defined some of our own game rules for modularization:

• For the Business Module Layer, no dependencies are allowed between business modules. The jump communication between them is implemented using the Router framework (the implementation of the Router framework will be introduced later);
• For the Business Component Layer, a single business component can only correspond to a specific business, and personalized needs provide external interfaces for callers to customize;
• Reasonably control the granularity of splitting each component and each business module. If the public module is too small to constitute a separate component or module, we will first put it into a component similar to CommonBusiness, and further split it according to the situation in the subsequent continuous reconstruction and iteration;
• The public services or functional modules of the upper layer can be gradually transferred to the lower layer, and the degree of transfer should be properly controlled;
• Reverse dependencies between layers are strictly prohibited, and horizontal dependencies are decided by business leaders and technical teams through discussion.

Inter-module jump communication (Router)

After the business is modularized and split, in order to decouple the business modules, each Bussiness Module is an independent module with no dependencies between them. So how to achieve jump communication between modules?

For example, if the business requires jumping from the new house list page to the second-hand house list page, then since NewHouseModule and SecondHouseModule are not dependent on each other, it is obviously impossible to implement Activity jump by thinking of the following explicit jump method.

 Intent intent = new Intent(NewHouseListActivity.this, SecondHouseListActivity.class);
 startActivity(intent);

Some students may think of using implicit redirection, which can be achieved through Intent matching rules:

 Intent intent = new Intent(Intent.ACTION_VIEW, "://:/" );  
 startActivity(intent);

However, this kind of code is cumbersome to write and prone to errors, and it is not easy to locate the problem when errors occur. Therefore, a simple, easy-to-use, and development-liberating routing framework is necessary.

The routing framework I implemented myself is divided into two parts: Router and Injector:

Router provides the function of passing parameters to Activity jumps; Injector provides the function of parameter injection, which obtains the passed parameters in Activity by generating code at compile time, simplifying development.

Router

The routing part is implemented through Java annotations combined with dynamic proxies, which is the same as the implementation principle of Retrofit.

First we need to define our own annotations (due to limited space, only a small part of the source code is listed here).

Annotation FullUri used to define the jump URI:

 @Target(ElementType.METHOD)
 @Retention(RetentionPolicy.RUNTIME)
 public @interface FullUri {
 String value();
 }

UriParam used to define the jump parameter (the parameters annotated with UriParam are used to be spliced ​​after the URI):

 @Target(ElementType.PARAMETER)
 @Retention(RetentionPolicy.RUNTIME)
 public @interface UriParam {
 String value();
 }

IntentExtrasParam used to define jump parameters (the parameters annotated with IntentExtrasParam are ultimately passed through Intent):

 @Target(ElementType.PARAMETER)
 @Retention(RetentionPolicy.RUNTIME)
 public @interface IntentExtrasParam {
 String value();
 }

Then implement Router, and use dynamic proxy to redirect Activity internally:

 public final class Router {
 ...
 public <T> T create (final Class<T> service) {
 return (T) Proxy.newProxyInstance(service.getClassLoader(), new Class[]{service}, new InvocationHandler() {
 @Override
 public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
                FullUri fullUri = method.getAnnotation(FullUri.class);
                StringBuilder urlBuilder = new StringBuilder();
                urlBuilder.append(fullUri.value());
 //Get annotation parameters
                Annotation[][] parameterAnnotations = method.getParameterAnnotations();
                HashMap<String, Object> serializedParams = new HashMap<>();
 //Splice jump URI
 int position = 0;
 for ( int i = 0; i < parameterAnnotations.length; i++) {
                    Annotation[] annotations = parameterAnnotations[i];
                    if (annotations == null || annotations.length == 0)
                        break;
                    Annotation annotation = annotations[0];
                    if (annotation instanceof UriParam) {
 // Concatenate the parameters after URI
 ...
                    } else if (annotation instanceof IntentExtrasParam) {
 //Intent parameter processing
 ...
 }
 }
 //Execute Activity jump operation
                performJump(urlBuilder.toString(), serializedParams);
 return   null ;
 }
 });
 }
 ...
 }

The above is part of the code implemented by Router. When using Router to jump, you first need to define an Interface (similar to the way Retrofit is used):

 public interface RouterService {  
 @FullUri( "router://com.baronzhang.android.router.FourthActivity" )  
 void startUserActivity(@UriParam( "cityName" )  
 String cityName, @IntentExtrasParam( "user" ) User   user );  
 }

Next, we can implement the Activity jump parameter passing in the following way:

 RouterService routerService = new Router(this). create (RouterService.class);
 User   user = new User ( "张三" , 17, 165, 88);
 routerService.startUserActivity( "Shanghai" , user );

Injector

After jumping to the target Activity through the Router, we need to obtain the parameters passed through the Intent in the target Activity:

 getIntent().getIntExtra( "intParam" , 0);
 getIntent().getData().getQueryParameter( "preActivity" );

To simplify this part of the work, the Router framework provides an Injector module to generate the above code at compile time. The parameter injector (Injector) part is implemented through Java compile-time annotations, and the implementation idea is similar to compile-time annotation frameworks such as ButterKnife.

First, define our parameter annotation InjectUriParam:

 @Target(ElementType.FIELD)
 @Retention(RetentionPolicy.CLASS)
 public @interface InjectUriParam {
 String value() default   "" ;
 }

Then implement an annotation processor InjectProcessor to generate code for obtaining parameters during the compilation phase:

 @AutoService(Processor.class)
 public class InjectProcessor extends AbstractProcessor {
 ...
 @Override
 public boolean process( Set <? extends TypeElement> set , RoundEnvironment roundEnvironment) {
 //Analysis annotation
        Map<TypeElement, TargetClass> targetClassMap = findAndParseTargets(roundEnvironment);
 //After parsing, the structure of the generated code is already there, and they are stored in InjectingClass
 for (Map.Entry<TypeElement, TargetClass> entry : targetClassMap.entrySet()) {
 ...
 }
 return   false ;
 }
 ...
 }

The usage is similar to ButterKnife. In Activity, we use Inject to annotate a global variable:

 @Inject User   user ;

Then in the onCreate method, you need to call the inject(Activity activity) method to implement the injection:

 RouterInjector.inject(this);

In this way, we can get the parameters passed through the Router jump.

• Due to space limitations and for ease of understanding, only a small portion of the Router framework source code is posted here. If you want to learn more about the implementation principle of Router, you can go to GiuHub to read the source code. The implementation of Router is still relatively simple, and the functions and documentation will be further improved later. There will also be a separate article to introduce it in detail. Source code address: https://github.com/BaronZ88/Router

Questions and suggestions

Resource name conflicts

The resource name conflict problem in multiple Bussines Modules can be solved by defining a prefix in build.gradle:

 defaultConfig {
 ...
   resourcePrefix "new_house_"  
 ...
 }

If some resources in the module are not to be accessed externally, we can create res/values/public.xml. Resources added to public.xml can be accessed externally, and those not added are considered private:

 <resources>
 < public   name = "new_house_settings" type= "string" />
 </resources>

Duplicate Dependencies

In the process of modularization, we often encounter the problem of duplicate dependencies. If it is through aar dependency, gradle will automatically help us find the new version and discard the duplicate dependency of the old version. If it is a project dependency, duplicate classes will appear when packaging. For this situation, we can change compile to provided in build.gradle, and only compile the corresponding library in the final project;

In fact, as can be seen from the previous modular design of Anjuke, our design can avoid the problem of duplicate dependencies to a certain extent. For example, all our third-party library dependencies will be placed in OpenSoureLibraries, and other projects that need to use related libraries only need to rely on OpenSoureLibraries.

Recommendations during the modularization process

For large commercial projects, during the reconstruction process, you may encounter serious business coupling and difficulty in splitting. We need to sort out the business first, and then split the business modules. For example, you can first subcontract according to the business in the original project, decouple each business to a certain extent, and split it into different packages. For example, because new houses and second-hand houses belonged to the same app module, they were previously redirected through implicit intents. Now they can be changed to jump through Router. For example, the common modules in new and second-hand houses can be first placed in the Business Component Layer or Basic Component Layer. After this series of work is completed, each business will be split into multiple modules.

Modular refactoring needs to be carried out gradually and cannot be done all at once. Don't think about overthrowing and rewriting the entire project. Online mature and stable business codes have been tested by time and a large number of users; overthrowing and rewriting them all is often time-consuming and laborious, and the actual effect is usually not ideal. Various problems emerge in an endless stream and the gains do not outweigh the losses. For the modular refactoring of this kind of project, we need to improve and refactor little by little, which can be dispersed into each business iteration to gradually eliminate the outdated code.

There will definitely be common parts between business modules. According to my previous design, we will push the common parts to the business component layer (Business Component Layer) or the basic component layer (Common Component Layer) according to business relevance. For public modules that are too small to constitute a separate component or module, we will first put them into a component similar to CommonBusiness, and further split them according to the situation in the subsequent continuous reconstruction and iteration. You can be maximalist in the process, but remember not to be excessive.

The above are some of my experiences in modular exploration and practice. I hope you can point out any shortcomings.