There are many articles on componentization on the Internet, and the process of learning componentization on the Internet also draws on the articles of predecessors on the Internet. But most of the articles start from the low-level details, and the bottom-up gives people a feeling that this technology is “broad and profound” and daunting. And my original intention for writing this article is from top to bottom, hoping that others can feel that "componentization is just these things" in the process of reading.
First, let's take a look at the difference between componentized projects and traditional projects:
In traditional projects
We usually have a Libary module of commonLib and an application module of app. The logic of the business is written in each functional module of the app and placed in different packages. This has the following main disadvantages:
1. No matter how well the subcontracting is done, as the project grows, the project will gradually lose its sense of hierarchy, and it will be very difficult for others to take over.
2. When we debug a small function, we need to rebuild the entire project every time we modify the code, which is very unreasonable (I don't know if the hot deployment of AS solves this problem)
3. Multi-person joint development is prone to conflicts and code coverage issues in version management
In componentized projects
In addition to the commonLib and app modules, we divide the business component modules according to their functions (eg: WeChat can be divided into four major modules: chat, contract, find, and mine). The previous package becomes the current module, which adds a sense of hierarchy; Each functional module can be compiled separately, which speeds up the compilation speed, and also provides support for providing unit module testing; multi-person development is only responsible for their own modules, which directly avoids conflicts in version management.
After understanding the main problem that componentization solves for us, let's see what we need to do
In fact, the initial realization of organization is actually only two problems we have to solve:
1. Set up the dependencies between modules, and make the business modules can be compiled separately-can be solved by configuring gradle
2. Page jump and communication between business modules-use Ali open source ARouter to solve
Next, let’s take a look at how to operate
First look at the problem of inter-module dependencies
We can refer to the four modules of WeChat (chat, contract, find, mine) to configure
First of all, the basic structure of our project is as follows:
We need to build a total of 6 modules, in addition to 4 functional modules, there is a basic common library and an application as a startup.
After the project is built, we need to configure a switch for whether to compile separately for the 4 modules:
Regarding the configuration position of the switch, this is a problem. We add it to the gradle.properties file so that every time we modify the value, we can trigger the rebuild of gradle, so that we can compile the module separately.
The switches we compiled separately are configured, and now we configure the dependencies between the 6 modules:
First of all, in order to facilitate the interaction between various modules, we borrowed Ali’s full ARouter library, so I strongly recommend adding dependencies on ARouter and commonlib in every non-common library (including the main Application).
Secondly, we need to install the switch of whether to compile separately for the 4 functional module libraries. We need to modify the following 2 places:
It can be seen that what we want to modify is the place where I am framed by the red box. When our switch is turned on, we compile it as a separate application and give it a unique applicationId so that we can pass The switch configured in gradle.properties controls whether it is compiled separately as an application.
For our entry module-app module, we need to do the following configuration:
Figure 1-5 Gradle configuration of the main module
In addition to configuring the basic ARouter and commonlib dependencies, we also need to select whether we need to rely on our functional modules according to the switch in the gradle file of the app module. This corresponds to the configuration in each functional module.
For other component modules, repeat the above steps to complete the construction of the component framework:
After completing the construction of the componentized framework, let's briefly take a look at some of the distinctive usage methods in the framework.
Let's first look at how the pages of each module jump.
We have already relied on ARouter before (refer to https://github.com/alibaba/ARouter for detailed usage), we need to use it to help us realize the jump requires the following steps:
The jump method is as shown in Figure 2-1. We need to mark the target page, attach the parameters to be transmitted, and then call navigation() to jump. However, someone asked how the target page looks like a path. How is it defined?
- First, annotate the page with @Route annotation, and define a path to the page in the path variable
- For the transmitted variable, we directly define a field with the same name and mark it with the @Autowired variable, and Arouter will automatically assign a value to the field
- Finally, we also need to inject the page into ARouter (the principle is similar to ButterKnife), let him help us complete the work we need
In this way, we have completed the jump between pages, is it simpler and more reasonable than our traditional method?
Finally, let's take a look at how the components provide services to each other.
- Here I want to call the sayHello method of the home component in the main module to Toast a person’s name
- How can the methods in the home be called by other modules (including the main module and other component modules)
First, create an interface that exposes methods in the commonlib module, define the interface signature, and inherit the Iprovider interface
Then inherit the interface defined in commonlib in the home module and implement the signature method.
Here we also use Arouter's @Router annotation to provide routing for this service.
Finally, we can use the @Autowired annotation in other modules to call the method
It can be seen that we also used the @Autowired annotation to initialize the baseService service, and inject the page into the Arouter to call the method in the service, and the dependency on the service is based on the interface, which greatly improves its flexibility!
The construction of the basic component framework is completed, and I hope that those who have read it carefully can gain something! Please correct me if there is any irregularity!
The code cloud of the above project (welcome to participate in the improvement): gitee.com/zsq519/ARou...
At last
Android hot fix framework, plug-in framework, component framework, image loading framework, network access framework, RxJava responsive programming framework, IOC dependency injection framework, recent architecture component Jetpack and other Android third-party open source frameworks. The system tutorial knowledge notes have been sorted into PDF e-books and uploaded on [GitHub]
1042 page full version PD quick start channel: (click here) free download! Full of sincerity! ! !
The article is not easy, if you like this article, or it is helpful to you, you may wish to like it and forward it. The article will continue to be updated. Absolutely dry goods! ! !