Github github.com/beyondxia/m…

1. What is componentization

Before we talk about componentization, we need to understand what a business module is. What is a business module? From the perspective of research and development, to put it bluntly, it is a collection of codes with independent business forms maintained by one or a group of people with relatively independent functions in the APP. Add a picture and feel ^_^, shopping module, membership module, movie module, hotel module, etc. can be generally understood as a business module.

In fact, our componentization is for business modules, each business can become an independent component, can be independently developed, independently compiled (and even independently run and tested). Services communicate with each other through a series of interfaces or protocols. After that, no one cares about each other and the services are completely isolated.

2. Why componentization

Since the developers of each business module tend to be different, imagine if all module code was in a code bin, all module code was coupled together, and there was no concept of a component:

  1. Development efficiency is bound to be relatively low, and it is difficult to locate problems
  2. The risk of code modification is high. Code modification in one module may lead to the application of other modules.
  3. The compile time is long, even if only one module changes, must compile the entire application.
  4. The code structure is not clear, the architecture is not stable, and it is not easy to expand and reuse components
  5. , etc.

3. Componentized development steps

To achieve component-based development, there are two main things to do: 1. First, you need code decoupling between businesses. 2. Communication between components

4. Implementation scheme

4.1, decoupling

According to the development steps of componentization, the first thing to realize componentization is decoupling between codes. The purpose of decoupling is to make businesses without any code dependence or code cross call, but also to achieve normal communication and data transmission after decoupling. For decoupling, the current traditional approach is interface exposure: business modules expose the methods and functions of the module in the form of interfaces or protocols, and register the methods and functions of each business exposure when the main APP starts (or when appropriate). We also adopt a similar approach, and the architecture diagram is as follows:

Each business module of themselves in the form of the service function and interface to the intermediate service layer () is located in the business layer, service layer of ways to gather various business exposure and interfaces, the application startup (or proper timing) registration, other business module to obtain various modules exposed services to the service layer, as shown in figure in red part. The service layer maintains a HashMap to hold all the existing services as follows:


It is recommended that each business module register one service, of course, depending on the business, a module can register multiple services:


At this point, we can decouple the code by adding an intermediate service layer. This is a common approach to decoupling in the industry today.

4.2 Communication mode

After services are isolated, a set of communication modes are required to enable convenient and efficient communication between services. In fact, there are three communication modes:

  • Call (inter-module function call) : Each independent business module exposes the Service interface for external calls, such as:

  • Notify /publish: each service module registers a global event of interest, notifies the event after it is generated, using rxbus, notification, routing, etc. This article will not discuss this:

  • Router (page jump between modules) : UI jump, unified use of routing, three-terminal unified route can use Arouter, ActivityRouter and other open source frameworks, this article will not discuss.

At this point, the introduction of communication scheme is completed.

Several considerations for the componentization of a less invasive componentization scheme