Project development to a certain extent, it is necessary to carry out module split. Modularity is a guiding concept, and its core idea is to divide and conquer and reduce coupling. In Android engineering practice, there are two ways, one is componentization, one is plug-in.
Componentized development
Speaking of componentization, the concept of AS modularization is always mentioned. In fact, the essence of the two approaches is the same, both for code reuse and business decoupling.
modular
Module, a concept proposed by Android Studio, is to extract the shared part or business from the original project to form an independent Module according to different concerns, which is similar to the SDK of the third-party library we integrate. Module contains two formats: Application and Library. An Application module can be packaged as an APK, and a Library can be packaged as an AAR (similar to a Jar in Java). In our actual development, we usually extract third-party libraries, use encapsulated network libraries, image libraries, video libraries, Utils utility classes, custom Views, and so on in a common module. Other modules can call these apis after configuring Gradle dependencies. Compared with packages, modules are more flexible, have lower coupling, and can be inserted and removed at will. According to different concerns, the shared parts of a project are extracted to form independent modules, which is modularity.
componentization
Componentization is based on modularization. Componentization is an evolution and variation of modularization thought. Componentization is the concept of modularity, but the core of componentization is the transformability of the role of a module, which can be set as Library when packaging and application when debugging.
In popular terms, componentization is to divide a large software system into independent components in the form of separation of concerns for the purpose of reuse. Components appear to solve the problem of a lot of repeated code in the global project, is for reuse, and the partition force is relatively small module. Another purpose of componentization is to decouple the system into multiple components, separating component boundaries and responsibilities for independent upgrades and maintenance.
The structure of componentized development
In the figure, the application layer, component layer and function base layer are respectively from top to bottom
- Base layer: Base layer contains some basic libraries and encapsulation of basic library, such as commonly used pictures of loading, the network request, data storage operation, etc., it is often some functional, other modules or components can refer to the same set of basic library, such not only only need to develop a set of code, decoupling the basis functions and also business function coupling, Easier to operate when the base library changes.
- Component layer: Above the basic layer is the component layer, which contains the business components that are divided according to our application, such as login module, message module, etc.
- Application layer: The project adds its own business components as needed.
Advantages of componentized development:
- The business modules are separated, which decouples and reduces the complexity of the project. The structure is very clear.
- There is no need to compile the whole project during development and debugging. Each module can be compiled independently, which improves the compilation speed.
- When multiple people cooperate, they can only focus on their own business modules and develop a certain business as a single project, which can improve the efficiency of development and testing.
- You can flexibly assemble and split service modules.
- Avoid repeated wheel construction, save development and maintenance costs;
Multiple teams share the same component, which ensures the uniformity of technical solutions at a certain level.
Conclusion: In fact, componentization is more suitable for some projects with large projects but relatively centralized functions. For example, a financial App only contains financial functions, which include lending, financial management and offline transactions. These modules are separated into separate components.
Plug-in development
Plug-in is to divide an APK into different sub-APKs (that is, different plug-ins) according to business functions. Each sub-APK can be compiled and packaged independently, and the integrated APK will be released online finally. In APK use, each plug-in is dynamically loaded, and plug-ins can also be hot fixed and hot updated. It also belongs to a kind of modularity embodiment. But its unit is APK, a complete project. Flexibility lies in loading APK, downloading on demand, and updating dynamically.
If an application is the function of all very much, such as drops, Meituan, pay treasure, they in addition to some basic business functions, and other business functions, if all into an apk, file will be very big, with plug-in, after the way of development apk contains only basic business functions, users can on-demand loaded in use process need to function module.
Plug-in development does not have an official plug-in program, it is a domestic proposed technology implementation, the use of virtual machine class loading mechanism to achieve a technical means, often need to hook some system API, and Google from Android9.0 began to limit the use of system private API, Also caused the compatibility of plug-ins, now several popular plug-in technology framework, are based on their own needs, open source, such as Didi VirtualAPK, 360 RePlugin and so on.
Conclusion: Plug-in development is suitable for large projects with relatively uncentralized functions. For example, an Alipay App contains both shared bikes and movie tickets. This is completely different from the business can be made into the form of plug-ins.
The difference between plug-in and componentization
| technology | unit | content | flexibility | features | Static and dynamic |
|---|---|---|---|---|---|
| componentization | Component (Module) | Decouple and speed up compilation, isolating parts that don’t need attention | Toggle as lib or APK according to load time; All the componentalization can do is, I already have a friend circle, and I want to debug, maintain, decouple from other people. But it’s relevant to the whole project. | Group: each component can be compiled and developed independently; But it is not completely independent in nature, such as a login module, it is associated with the whole project, is part of the project | Add and modify dynamically at compile time, not at run time |
| pluggable | Apk (a complete application) | Decouple and speed up compilation while implementing hot plug, or hot update | Load is APK, dynamic download, dynamic update, more flexible than componentization; Plug-in is a circle of friends is an app, I need to integrate it into wechat this big APP | Plug: is a separate APK, each plug-in can be run as a completely separate APK, or can be integrated with other plug-ins into a large APK. | Both compile time and run time can be added and modified dynamically, so it is more flexible than componentization |
Plug-in and componentization options
The ideal code organization would be a plug-in approach, which would be fully dynamic at run time, more flexible, and more independent of each plug-in.
But there is no perfectly compatible plug-in solution yet.
There are two aspects to consider when choosing plug-in:
- Compatibility. First, pluginization inevitably unhooks some system apis, which inevitably leads to compatibility problems, so each plug-in solution needs a special team to be responsible for maintenance;
- Develop a rhythm. Second, it may take a huge amount of time to split the plug-in from a project with complex business logic. At the same time, integrating the original project into a platform requires the use of plug-in related technology to modify, which is a challenge to the compatibility of the four components of Android and the adaptation of the original implementation method.
- Supportive. App market support: At present, Google Play does not allow plug-in dynamic loading and incremental update of apps to be launched, because this will bypass the review and prevent some bad apps from “selling dog”, and other bad features will be hot updated after users download and install the app. At present, the domestic market has not been expressly stipulated. Technical support: To some extent, Google discourages this kind of development, and the restrictions on proprietary apis will become more and more stringent in the future. Frameworks on the market are three years old.
In most cases, componentalization is a good or even the best option because it has no compatibility, can be broken down more easily, and has few technical hurdles and can be implemented more smoothly. Especially for products that need to be split, componentization is a fallback solution that can be executed more quickly and will be a necessary step in the future if the migration to plug-in is made.
The last
For the specific knowledge of componentization, I recommend you to read the two articles by Yu Gang and Yang Chong, which are very comprehensive and easy to understand.
Best practices for Android componentization
Android componentization development practice and case sharing