The author
Hello everyone, my name is Xiangzi 😊;
I graduated from Guangdong Pharmaceutical University in 2015 and joined the 37 Mobile Game Android team in August 2018. I once worked as an Android development engineer in netease.
Currently, I am the leader of 37 mobile Game Android team. In addition to daily team management, I like to study Android related technologies in my spare time, because I always believe that “technology management” must continue to pay attention to technology and maintain enthusiasm for technology, so that it will not be a castle in the air…
background
Before we understand the hot repair related theory: Android hot repair -Shadow thought – plug plug-in
At the same time, I also made a practical Demo to consolidate the relevant knowledge: Android hot repair – plug – type plug-in scheme -Demo
Now we combine the previous knowledge, how to apply the thermal repair technology in SDK, put into production;
SDK iteration mode before hot repair (business side)
(1) Business requirements, modify SDK to support business functions
(2) Receiving technical requirements, developing/testing/releasing versions, etc
(3) Launch the business, put the Android package with the new SDK on the shelf, and users can download and use it
As can be seen from the above flow, the current model has several shortcomings:
-
Under normal circumstances, the new function is not experienced by existing users
-
If for the old user experience, forced update, then the user damage is greater
-
It takes a long time from internal development to online user coverage, which affects the revenue rate of services
-
It is not convenient to do A/B test
What was SDK engineering like before hotfix?
Here is a virtual demo project, and the actual project similar, does not affect the idea of explaining
Suppose our SDK project works as follows:
The corresponding dependencies are as follows:
App module: simulation of customer application engineering, using SDK test, etc
SDK:
- SQSDK module: the interaction layer between the SDK and the customer
- Features1 module: SDK internal feature 1 module
- Features2 module: A module for SDK internal feature 2
Features2 + SQSDK + Features1 + Features2 + SQSDK + Features1 + Features2 + SQSDK + Features1 + Features2 + SQSDK + Features1 + Features2
Code stamp this >>
Thermal repair implementation, how should the original engineering architecture be adjusted?
What are the conditions for modification?
- Internally, it is compatible with the iteration process of the SDK before modification (because in the actual project, there are many people working together, and the daily production is constantly iterating. It is impossible to stop the daily iteration because of the hotfix version, and then iterate the daily content after the hotfix version is ready).
- Externally, in terms of the customer interaction layer, the old interface is not modified (because many customers are using it), and in the end, only one SDK is connected to the customer instead of two
Let’s take a look at the changes to the engineering architecture
SQSDK + Features1 + Features2
- The original SDK content is treated as a plug-in;
- The reason for doing this is that the content of daily business iteration is generally changed in these places, and the architecture of this part is not changed as far as possible, so as to further realize the above “internal, compatible with the iteration process of SDK before modification”;
- So to implement the above, there is a problem to deal with: how to package as a plug-in? (It will be said below, here to leave a concept first)
Pluhost module (host)
This is a host module that does the following:
- On the internal side, load the plug-in and call the concrete implementation of the plug-in when the customer surveys the interface; Export the AAR or/JAR to the customer at the same time
- External aspect, provide external interface to customers
Commonpluhostandsqsdk module
This module is the common module of the plugin and host. It is mainly about interface compatibility and so on.
Other modules (plugin and so on do not expand, specific can see the project source code below)
Modules are classified roughly as follows, so let’s look at module dependencies:
Red box
-
Summary: This is a plug-in module
-
Engineering: used to be a lib module, export aar/ JAR mode for customers to use directly; Now is an APP module, export a plug-in APK way, to the host for use;
-
Interface: Used to expose SqWanCore to customers; Instead of calling directly to the host (client), the external class inside will be changed (SqWanCore to SqWanCoreImpl as implementer).
-
The gradle plugin will be used to modify the class in order to be compatible with the previous model. See buildSrc for the source module below
Blue box
- Summary: This is a host module
- Engineering: this is a new module that will reference the plug-in APK and load the plug-in
- Interface: The old interface to the customer, SqWanCore, will remain, and the customer can be directly compatible with it without much modification; Inside the host is the specific implementation of the tuning plug-in
The green box
- Introduction: This is a simulation of customer APP project
- Engineering: Rely on the jar/ AAR exported by the host for use
Code stamp here >>
conclusion
Students who have problems or need to communicate in the process can scan the TWO-DIMENSIONAL code to add friends, and then enter the group for problems and technical exchanges, etc.
