Shulou(Shulou.com)06/02 Report--

This article will explain in detail how to achieve multi-processes on Mini Program. The content of the article is of high quality, so the editor shares it for you as a reference. I hope you will have some understanding of the relevant knowledge after reading this article.

Preface

I believe the term Mini Program is no stranger to you. After Wechat, Alibaba, Baidu, Toutiao and other big companies have realized their Mini Program one after another. Mini Program is a new open capability, developers can quickly develop Mini Program and integrate it into the host, to achieve promotion and other purposes.

From the point of view of use, Mini Program is lightweight and easy to use.

From a technical point of view, taking the Android side as an example, Mini Program has some components, isolation of UI and logical threads, process isolation between Mini Program, and so on.

The following is mainly from the mini program process isolation point of view, analysis of BAT's Mini Program multi-process implementation scheme, and their own implementation of a Mini Program multi-process.

The meaning of multiple processes

Multi-process, as the name implies, that is, each Mini Program is a separate process. This effect is unique to the Android side. So why do we want process isolation between Mini Program? There are three general reasons:

Because it is a separate process, no matter what reason the internal collapse of Mini Program has no impact on the main process and enhance the user experience.

Because each process has a separate memory area, Mini Program will not occupy the memory of the main process, reducing the risk of memory overflow.

Because the memory between different processes is isolated, when multiple Mini Program is opened at the same time, memory variables, parameters and other data do not affect each other, and a decoupling can be achieved.

An Analysis of WeChat Mini Programs

Since we are analyzing multi-processes, which is not a strong user-perceived technical point, we need to use some tools or commands.

Process analysis

First, we completely kill and reboot Wechat, and then use the adb shell ps | grep com.tencent.mm command to check the name and number of running processes, where grep com.tencent.mm is to filter Wechat-related processes, because Wechat's package name is com.tencent.mm. The running status of the process is as follows:

At this time, we can only see that Wechat has started six processes from complete shutdown to startup, but we still can't see whether these are related to Mini Program. Therefore, we open a Mini Program and execute the adb shell ps | grep com.tencent.mm command again, and the process is running as shown below:

After the comparison, we can do some analysis. Among them, com.tencent.mm is the main process, com.tencent.mm:push should be the process related to push, com.tencent.mm.tools and com.tencent.mm:toolsmp should both be related processes similar to Helper, so I think com.tencent.mm:appbrand2 is the most likely, because this name is special, there are two processes appbrand0 and appbrand1 before. So why the first Mini Program, but the extra process when appbrand2? I personally guess that this has something to do with WeChat Mini Programs's preloading. It is very likely that this process is empty, but fork comes out first, and does not do too much. It is very likely that the process of Mini Program that we started is not this appbrand2. So how to verify it? Proceed to the second step, Activity analysis.

Activity analysis

First, open a Mini Program, and then through the adb shell dumpsys activity activities command, you can see the Activity information in all the stacks. Slide to the top to view the Activity information that is interacting with the user, as shown below:

I've circled the key information in red, processName=com.tencent.mm:appbrand0,realActivity=com.tencent.mm/.plugin.appbrand.ui.AppBrandUI, which roughly validates what we just guessed:

The com.tencent.mm:appbrand series is a process related to Mini Program.

Wechat preloads 2 empty processes as preloads to avoid fork processes when used, which takes too long to affect the user experience.

To further verify whether the conjecture is correct, I downloaded the latest version of Wechat's apk and did the reverse operation, which is the third step, to analyze apk.

Apk Analysis of Wechat

The method of decompilation is searched by everyone, so I won't repeat it here. We open the decompiled AndroidManifest.xml file and search for the previous Activity name. The results are as follows:

The information we got is the same as just now. However, we found another problem, that is, AppBrandUI has four other brothers, namely AppBrandUI1,AppBrandUI2,AppBrandUI3,AppBrandUI4, and the names of these four Activity and the binding process can correspond to the initial appbrand. Through experiments, I found that Wechat can only start a maximum of five Mini Program, and the carrier of these Mini Program is the five Activity. Keep polling, when more than five, will be the first to end. In this way, we can basically be sure that Wechat is through the apk built-in 5 Activity, to achieve Mini Program multi-access and process isolation.

Therefore, in theory, the internal logic of the five Activity should all be the same except for different processes, so we continue to verify and decompile the code to find the Activity of AppBrandUI1. The result is as follows:

AppBrandUI2,AppBrandUI3,AppBrandUI4 is exactly the same, inheriting AppBrandUI and doing very little. Because Wechat code has been confused, we can't see exactly what those lines of code do, but it can basically be understood as complete reuse. As for why to write separately instead of reusing the same, I guess there may be two reasons:

Due to syntax limitations, opening up a process for Activity requires pre-configuration in AndroidManifest.xml

two。 Wechat isolates not only the Mini Program process, but also the stack. When we open multiple Mini Program at the same time, we can find multiple Mini Program task cards by long pressing the home button. This effect also requires configuring the taskAffinity attribute in AndroidManifext.xml, which is also reflected in the figure above.

In addition, I noticed that Wechat configured Receiver like this in AndroidManifest.xml:

There are five such Receiver, one for each Mini Program process, and the other four just inherit the AppBrandTaskPreloadReceiver. Due to confusion, it is impossible to see what has been done, but judging by the name, it is achieved that the Mini Program process is preloaded. If you start this broadcast when you are idle, you can at least start the process in advance to avoid taking too long to reload and affect the user experience.

Similarly, I analyzed the apk of Baidu and Alipay, through command and decompilation and other methods, found that their scheme is almost the same, but the number of preloaded and other small details are different, interested students can reverse their own comparison.

Analysis and summary

1. Wechat does process isolation and stack isolation to each Mini Program, which does not affect each other.

two。 The carrier Activity that implements this function is pre-configured in AndroidManifest.xml.

3. In some way, Wechat limits the maximum number of Mini Program operations to 5.

4. Wechat has made some optimizations for multiple processes. What is known is that 2 empty processes are preloaded.

5. The Mini Program multi-process plans of big manufacturers such as BAT are more or less the same.

The key points of realizing Mini Program multi-process

one。 Application initialization

When the app of Android starts multiple processes, each time a process is started, the Application will be recreated, that is, the onCreate function will be called. If no process judgment is made, everything will be initialized multiple times, resulting in stutters or unexpected bug.

two。 Distribution and control

As the memory between processes can not be shared, the life cycle of Mini Program needs to be maintained in a process, otherwise it is impossible to dynamically allocate processes and stacks, and it is most appropriate for this process to choose the main process. So you need to create a manager that is responsible for the following things:

1. Receive the operation of Mini Program, such as opening, closing, etc.

two。 Reasonably allocate idle processes to received requests

3. Receive the lifecycle callback of remote Mini Program and maintain it through a uuid

4. Preload the process when idle

5. Create and destroy processes according to the maximum number of Mini Program that can be opened.

6. All these management and maintenance operations should be transparent to Mini Program access, do not need to care about the specific implementation process, just open Mini Program when needed.

three。 Process life cycle problem

The Android system has its own control mechanism for memory. When memory is tight, it will kill the less active process without any notice. As for the process activity, it is related to the Android process. You can set the foreground process, wake up and other ways to keep alive as far as possible. However, no matter what the application side does, it cannot exceed the authority of the operating system, and the system will still kill the process in some cases to ensure the normal operation of the whole system. Therefore, fault-tolerant processing is required during development, and the onDestroy callback of Activity cannot only prevail, because once system-level recycling occurs, it is likely to lead to confusion of the entire allocation manager.

four。 communication

Communication is divided into two aspects: first, the Mini Program process is isolated from the app main process and requires inter-process IPC communication; second, the essence of Mini Program is a web container, which requires js and native communication, which requires jsbridge. Let's talk about these two aspects respectively. Process communication:

The implementation of IPC is no longer a problem, here are just a few points to note:

1. Communication must be two-way, no matter which process, it is best to bind the same service to facilitate data maintenance.

two。 As the communication is more frequent, it is recommended to use the communication mechanism based on Binder, which can improve the operation efficiency.

Js communicates with native:

Js must communicate with the native through jsbridge. The best practice is to write the implementation of the native method in the main process. Mini Program in different processes requests the implementation result of a certain bridge from the main process. The main process executes the result according to the corresponding parameters and returns the result, similar to a set of CS architecture. That is, the Mini Program client does not need to care about the specific operation, only cares about the result and responds to the web end.

On how Mini Program to achieve multi-process sharing here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.