The business component of Android project architecture

Objective:

From personal experience, engaged in the development of the app for so many years, the volume of the app has become more and more large, the business has become more and more complex, always to say only one sentence: This is an app bloated era! So in order to say goodbye to the app bloated era, let us enter a U disk ERA, each business module is a separate running disk, plug in where can be perfectly run, this is to promote business components of the original intention is also a good vision.

Requirements background:

With the rapid development of the company, the iteration of the version, the business becomes more and more complex, the number of business modules is likely to continue to increase, and the code of each module will be more and more, so that the impact of development efficiency, increase project maintenance costs, each engineer should be familiar with so many code, And every time you compile so much code, the computer is stuck with wood? Slow as Mr. Snail has wood there? So the engineer has gone insane! Then jump off the go die! Therefore, it is urgent to push forward the business component of the company, which is also the background of realizing the business component.

Current situation Analysis:

Only know where your problem is. To find a solution to the problem, let's look at a single project structure prototype for most apps today. Roughly as shown:

Look at this structure is not very clear? Each business is placed in a separate package name, the network library, image loading library and other third-party libraries and the upper business are perfectly stripped, and then we look at their direct dependency diagram:

Although the above dependencies are a bit too extreme, there are real-world scenarios. The code of each business is referenced to each other, so this structure is also the fundamental motive for the rectification of the architecture, and it is a priority to consider. In order to better meet the various business iterations and not affected each other, to better solve the above such a headache of dependency, began to start the application architecture rectification.

From the above analysis we can draw a few scenarios suitable for business component:

(1) More business, and complex
(2) The need for decoupling between business dependencies
(3) More team members, need to develop their own relatively independent business

Business Component Orientation:

The direction of the application business component-oriented architecture rectification is to leave the era of bloated structure and make each business relatively independent. The module engineering and the Class Library project follow a downward dependency relationship, and each module follows a peer dependency relationship. Take a look at the downward dependency diagram between the various independent business modules and the class Library project after the rectification:

The direction of rectification is divided into several module projects by a project project, which provides a unified portal by the app Shell project, and each business independent module modules share the dependent library of the project. The business modules that need to be introduced by the Shell Engineering integration, as regards the invocation dependencies between the individual business modules, we use a middle tier as the routing function, which we put in the layer of dependent libraries referenced by the various business modules together. By routing the dependencies between them uniformly, routing scheduling solves the problem of peer dependencies:

By using the routing functionality provided by the app Shell project, calls between modules are no longer used for traditional display calls, but are implicitly invoked. Thus, there is no longer a dependency between the various modules.
App Business Component Architecture rectification Technology Solution:

There are a number of issues that need to be addressed in the business component.
1.) Life cycle of business components

In an ideal state of mind, there is no dependency between the various business components, so we can think of each individual business component as a running app, so the lifecycle of the business components should be aligned with the standalone app.
2.) Communication between business components

In the individual business components, basically maintain the original method of invocation, communication between components using the URL schema to implement page jumps, in the form of schema://host/action?param1=value1?m2=value2. About schema mapping table maintenance is maintained by such a role as the router (route) mentioned above

Schema parsing is maintained by the system framework. Where the schema mapping table can be made into a background configuration file form. Code maintenance is also possible, but the component needs to be pre-registered. The above-mentioned is not a problem for passing basic parameters. If you want to pass the object, you can turn it into a JSON string.

About the schema can refer to my blog: The Android business component of the URL schema use

Benefits of the APP Business component architecture overhaul:

What would be the benefits of a revamped architecture that would require higher costs and potential risks in such a large-scale restructuring?

(1) Accelerate the iteration speed, the various business module components more independent, no longer because of the business coupling situation, in the release, due to each other waiting for the release version.

(2) The stable public module adopts the dependent library method, which is provided to each line of business and reduces the repetitive development and maintenance work.

(3) The Iterative business module adopts the component way, the development of each line of business can not interfere with each other, improve the efficiency of collaboration, and control the product quality.

(4) provides the foundation for the new business to be integrated at any time, all the business can be up and down, flexible and changeable.

(5) Reduce team members ' familiarity with project costs and reduce the difficulty of project maintenance.

(6) Speed up compilation and improve development efficiency

Summarize:

This article mainly to analyze why to realize the business component, the direction of the component, the component of the technical solution simple discussion, the benefits of the component, because at present is still in the early stages of implementation, many ideas may be wrong, many technical pits have not been covered, follow-up will follow up more relevant implementation plans.

The business component of Android project architecture