Foreword: do not know everybody is not like I did not do modularization, componentization before same, feel this architecture is a very advanced, very complex thing, do rise should be very difficult, in fact after done you can discover modularization, componentization is changed however so. In this article, I will share with you some knowledge of modularization and componentization. I believe that when you read this article, you will feel that modularization and componentization is nothing more than this.
The basic structure of this paper
The structure of this article is shown in the figure below. The article will explain the knowledge of modularization and componentization in detail around the points listed in the figure below.
Modularization, componentization concept
Modularization and componentization is an architectural idea and a means of decoupling that is platform independent. Why do we always put modularity and componentization together? Because the relationship between them is me in you, me in you. For example, if we split an APP into several functional modules, these modules will definitely rely on some common components, such as network components, picture components, audio and video components, etc., and these components may be subdivided into some modules, such as picture components, download modules, cache modules, etc. If I had to distinguish the two, it might be the following definition:
- Modularity: That is, it can represent the upper level of the business, or it can represent modules in the underlying or common components
- Componentization: Typically underlying or common components
Why modularization and componentization
The project is well done, why change the project to a modular, componentized architecture? Here’s why:
- As the version of the project continues to iterate, the functionality of the project increases, the code becomes more complex, the coupling becomes higher, and many functions can be affected by a small change.
- As the functionality of the project increases, the developer in charge of the project may change from one person to several people to work together on the project. In this case, everyone may change a certain piece of code or add some of the same code.
- As we add more code, it takes longer and longer to compile the entire project, severely affecting development efficiency.
The project was changed to a modular, componentized architecture to solve the above problems.
Not every project should have a modular, componentized architecture. For example, we are working on a small project that has few features and no new features will be added in the future. It is perfectly ok to develop the project by one person. In this case, using modular and component-based architecture would be a waste of life and money.
Principle of modular partition
When we modularize the project, we will face the problem of how to split the module, so when splitting the module, we need to follow some principles, the principle to follow is
- Modules at the same layer cannot depend on each other.
- Only upper-layer modules can depend on lower-layer modules, but lower-layer modules cannot depend on upper-layer modules.
Why these two principles? Because modularity can be a problem when you don’t know which module to put a piece of code in, you can use the above principles to determine whether to put the code in the upper, lower, or which module to put it in.
To explain the above two principles, see the diagram below
Can see from the picture, here will be modular is divided into four layers, cannot depend on each other between “namely” the principle, that is in the same layer can’t rely on relationship between various modules, such as “business function module” there may be several function modules, this layer between the several functional modules are not dependent. The principle of “only the upper module can depend on the lower module, and the lower module cannot depend on the upper module” means that the module below the level cannot depend on the upper module. If there is a dependency relationship, the dependent module should be placed at the same or lower level of the dependent module.
How to split modules
There is no clear answer to this question. The general approach is to put some common and invariable or infrequently changed functions in the base library, such as network requests, image loading, and some utility classes. The base component is a layer that houses some third-party SDKS such as payments, statistics, bug collection, etc. Business function module function of this layer is placed our project related code, after the break up of this layer is related to the development of the coupling, so be careful, of course, the most reasonable is a function into a module, but it would be a split granularity is too small, so on this layer separation is the best team in the discussion and decision. The top layer is the shell of the app. This layer usually has no function, but is used to initialize the project. Android projects usually place the application class in this layer.
How should split modules communicate
From the above principle of module division, we can know that modules at the same level cannot depend on each other, which will lead to “can not depend on, how to communicate between modules?” For example, if an ActivityA wants to jump between two modules and transfer values to ActivityB, how do you transfer values? If there is no modularization, you can use stratActivity or startActivityForResult to explicitly jump to the interface to complete the value transfer. However, during modularization development, ActivityA may be in module A and ActivityB may be in module B because module A and module B are in the same layer. Without dependencies, you can’t pass values directly. How can you solve this problem? The answer is to use routing. In Android, ARoute open source library is generally used. After using this library, you only need to define the jump path and find the corresponding interface according to the defined path after packaging the APP.
conclusion
The main content of this article is to explain the idea of modularization, the purpose of this article is to let everyone no longer think that modularization is a difficult architecture, no longer because modularization is a relatively advanced thing and dare not try. If you don’t think about modularity at the beginning of a project, you’ll eventually adopt the architecture as the project grows, and it won’t be easy to change the architecture as the project grows. I hope you don’t incur technical debt while working on your project. If technical debt is unavoidable, it should be paid as soon as possible.
conclusion
The article did not explain the specific implementation of modularization, about the specific implementation details online has a lot of articles, you can understand according to their own needs. This article is mainly to let everyone understand the idea of modularization, after understanding the idea, the rest is to practice, I believe that after reading this article, you start modularization will get twice the result with half the effort.
This article has been published by the public id AndroidShared
