Recently, I was working on a project in a refactoring company. I was going to modularize the project. By the way, I would like to record some thoughts during the refactoring process.

Android modular Design

There have been numerous articles about modular development on Android so far, but I’d like to record some of my thoughts on modular development as a summary and affirmation of my own learning process.

There are many online descriptions of the benefits of modular development, but I won’t go into them here.

Above is one of my ideas about modular design. Here’s what each module means:

Solid arrow: Dependencies

Dotted arrow: Derived relationship

App ① and App ② : These two modules at the top are shell projects when we package App, and the modules do not contain specific business logic.

ModuleA, ModuleB… : the project main body function of split into modules can be operated independently, such as shopping city functions, user information management, etc., correlation between these modules is not so close together, in the process of collaborative development, also is not the same person in charge, split into different modules can be in the process of collaborative development, to minimize interference among each other, improve the efficiency of collaborative development.

Router: A routing component, needless to say.

ApiA, ApiB… : Interfaces, entity classes, and routing tables exposed in the corresponding ModuleA and ModuleB. In our development process, although we try our best to avoid the coupling between modules, the call of modules is always unavoidable. In order to solve the problem that interfaces and entity classes that need to be called across modules sink into Common and cause Common overbulk, we derive corresponding API modules from module through API of classes. Provides dependencies for other modules.

Business Common: Project-related basic dependency library, mainly used to store resources shared between modules, such as TitleBar, NavigateBar, etc. These widgets or resource files are closely related to our Business and need to be used in multiple modules, so they are managed by a separate module.

ThridLibs: third-party libraries we inevitably in the process of development to use third-party libraries, such as sharing, maps, decoding module, such as the core functions of these modules with the business, so we after encapsulation of tripartite library into separate modules, and expose to the method of abstract into interface, call for the upper module.

ThridLibs Proxy: the Proxy module of the third party class library. In order to avoid using the third party class library directly, it performs dynamic/static Proxy for the interface abstracting from the above module, which is convenient for us to change the third party class library quickly in the future.

Base Common: the Base module that has nothing to do with business, such as the BaseActivity and BaseFragment that we encapsulate. We can use this class library in other projects, which is also the foundation of our development.

Utils: This module is simple. It is just some utility classes used in everyday life, such as FileUtil, AppUtil, etc.

These modules can exist in the project as Git submodules (Git submodules for those who do not know about them), or for modules that are not frequently maintained, they can be packaged as AArs and uploaded to a Maven repository.

A brief introduction to submodules: Git supports references to other independent repositories in the main repository, which are referred to as submodules. The sub-module, like a normal GIt repository, can be maintained independently, while the main repository only needs to index the MD5 value of the sub-module commit without maintaining the files of the sub-module, which is a very good means to reduce the coupling degree of the project.

There are always pros and cons. Modular development, while it can decouple projects into different modules, has some obvious drawbacks:

First, the maintenance cost of the project increases. What can be solved by one warehouse is now subdivided into multiple warehouses. The more fine and granular the modularization, the higher the maintenance cost. In small teams or even individual development, the adoption of modular development solutions is a matter of careful consideration.

Second, cross-module dependencies become complex. Because sibling modules do not depend directly on each other, cross-module calls are much more complex than a single module.

That’s all for this blog post, go ahead and try it

If this article can help you, please like, comment and follow us