What processes does an APP go through from startup to main page display?

This article briefly introduces the process of an APP from startup to the main page display, as well as the implementation principle in the form of pictures and text. It does not introduce the specific source code, but only builds a general framework.

***Process Overview

Startup process:

① Click the desktop App icon, and the Launcher process uses Binder IPC to initiate a startActivity request to the system_server process;

②After receiving the request, the system_server process sends a request to create a process to the zygote process;

③The Zygote process forks a new child process, namely the App process;

④App process initiates an attachApplication request to the sytem_server process through Binder IPC;

⑤After receiving the request, the system_server process performs a series of preparations and then sends a scheduleLaunchActivity request to the App process through the binder IPC;

⑥After receiving the request, the binder thread (ApplicationThread) of the App process sends a LAUNCH_ACTIVITY message to the main thread through the handler;

⑦After receiving the Message, the main thread creates the target Activity through the launch mechanism and calls back methods such as Activity.onCreate().

⑧At this point, the App is officially started and enters the Activity life cycle. After executing the onCreate/onStart/onResume methods, you can see the main interface of the App after the UI rendering is completed.

The above series of steps briefly introduce the process of an APP starting to display on the main page. Some of the terms in these processes may be a bit confusing, such as what is Launcher, what is zygote, what is applicationThread...

Let us introduce them one by one below.

2. Theoretical basis

1.zygote

Zygote means "fertilized egg". Android is based on the Linux system, and in Linux, all processes are directly or indirectly forked from the init process, and the zygote process is no exception.

In the Android system, zygote is the name of a process. Android is based on the Linux system. When your phone is turned on, a process called "init" will be started after the Linux kernel is loaded. In the Linux system, all processes are forked from the init process, and our zygote process is no exception.

We all know that every App is actually

• A separate Dalvik virtual machine
• A separate process

So when the first zygote process in the system is running, opening the App after that is equivalent to opening a new process. In order to achieve resource sharing and faster startup speed, the Android system opens a new process by forking the first zygote process. So, except for the first zygote process, the processes where other applications are located are all child processes of zygote. Now you understand why this process is called "fertilized egg"? Because just like a fertilized egg, it can divide quickly and produce cells with the same genetic material!

2.system_server

SystemServer is also a process, and it is forked from the zygote process.

Knowing the nature of SystemServer, we are not too unfamiliar with it. This process is one of the two very important processes in the Android Framework - the other process is the zygote process mentioned above.

Why is SystemServer so important? Because all important services in the system are started in this process, such as

ActivityManagerService, PackageManagerService, WindowManagerService and so on.

3.ActivityManagerService

ActivityManagerService, referred to as AMS, is a server-side object responsible for the life cycle of all Activities in the system.

The timing for ActivityManagerService to be initialized is very clear, that is, when the SystemServer process is started, ActivityManagerService will be initialized.

The following introduces the concepts of server and client in the Android system.

In fact, the concept of server-client does not only exist in Web development, but also in the Android framework design. The server-side refers to the system services shared by all apps, such as the ActivityManagerService mentioned here, and the PackageManagerService, WindowManagerService, etc. mentioned earlier. These basic system services are shared by all apps. When an app wants to perform a certain operation, it needs to tell these system services. For example, if you want to open an app, then we can open it after we know the package name and MainActivity class name.

 Intent intent = new Intent(Intent.ACTION_MAIN); 
 
 intent.addCategory(Intent.CATEGORY_LAUNCHER); 
 
 ComponentName cn = new ComponentName(packageName, className); 
 
 intent.setComponent(cn); 
 
 startActivity(intent);

However, our App cannot directly open another App by calling startActivity(). This method will go through a series of calls, and the client will still tell AMS: "I want to open this App. I know its address and name. Please help me open it!" So it is AMS that notifies the zygote process to fork a new process to open our target App. This is just like when a browser wants to open a hyperlink, the browser sends the web address to the server, and then the server sends the required resource files to the client.

After knowing the client-server architecture of Android Framework, we need to understand one more thing, that is, our App, AMS (SystemServer process) and zygote process belong to three independent processes. How do they communicate with each other?

App and AMS communicate via IPC through Binder, and AMS (SystemServer process) and zygote communicate via IPC through Socket. This will be described in detail later.

So what is the use of AMS? As we know before, if we want to open an App, we need AMS to notify the zygote process. In addition, in fact, all the opening, pausing and closing of Activities need to be controlled by AMS, so we say that AMS is responsible for the life cycle of all Activities in the system.

In the Android system, the startup of any Activity is completed by the cooperation of AMS and application process (mainly ActivityThread). The AMS service uniformly schedules the startup of Activities of all processes in the system, while the startup process of each Activity is specifically completed by the process to which it belongs.

4.Launcher

When we click on the icon on the mobile phone desktop, the App will be started by the Launcher. But have you ever thought about what exactly is a Launcher?

Launcher is essentially an application, just like our App, it also inherits from Activity.

packages/apps/Launcher2/src/com/android/launcher2/Launcher.java

 public final class Launcher extends Activity 
 
        implements View .OnClickListener, OnLongClickListener, LauncherModel.Callbacks, 
 
 View .OnTouchListener { 
 
 }

Launcher implements callback interfaces such as click and long press to receive user input. Since it is a normal App, our development experience is still applicable here. For example, when we click the icon, how do we open the application? Capture the icon click event, and then startActivity() to send the corresponding Intent request! Yes, Launcher does the same, it's that easy!

5.Instrumentation and ActivityThread

Each Activity holds a reference to the Instrumentation object, but there is only one Instrumentation object in the entire process.

Most of the methods in the Instrumentation class are related to Application and Activity. This class is a tool class that completes the initialization and life cycle of Application and Activity. The Instrumentation class is very important. The call to the Activity life cycle method is basically inseparable from it. It can be said to be a big housekeeper.

ActivityThread is the UI thread. App and AMS transmit information through Binder, so ActivityThread is dedicated to diplomatic work with AMS.

6.ApplicationThread

We have already known that the startup of App and the display of Activity require the control of AMS, so we need to communicate with the server, and this communication is two-way.

Client-->Server

And because it inherits the same public interface class, ActivityManagerProxy provides the same function prototype as ActivityManagerService, so that users cannot tell whether the server is running locally or remotely, making it easier to call these important system services.

Server-->Client

It still communicates through Binder, but uses another pair, ApplicationThread and ApplicationThreadProxy.

They also implement the same interface IApplicationThread

 private class ApplicationThread extends ApplicationThreadNative {} 
 
 public abstract class ApplicationThreadNative extends Binder implements IApplicationThread{} class ApplicationThreadProxy implements IApplicationThread {}

Okay, I have talked a lot in the previous part and introduced a bunch of terms, which may not be clear to you. It doesn’t matter. Let me introduce them with the flowchart below.

3. Startup Process

1. Create a process

①First, from the startActivity() method of Launcher, call the startActivity method of ActivityManagerService through Binder communication.

②After a series of troubles, ***call the startProcessLocked() method to create a new process.

③This method will pass parameters to the Zygote process through the socket channel mentioned above. Zygote incubates itself. Call the ZygoteInit.main() method to instantiate the ActivityThread object and finally return the pid of the new process.

④Call ActivityThread.main() method, ActivityThread then calls Looper.prepareLoop() and Looper.loop() in sequence to start the message loop.

The method call flow chart is as follows:

A more straightforward explanation of the process:

① App launches the process: When launching an application from the desktop, the launching process is the process where the Launcher is located; when launching a remote process from an App, the sending process is the process where the App is located. The launching process first sends a message to the system_server process through the binder;

②system_server process: calls the Process.start() method and sends a request to create a new process to the zygote process through the socket;

③zygote process: After executing ZygoteInit.main(), it enters the runSelectLoop() loop body. When a client connects, it executes the ZygoteConnection.runOnce() method, and then forks a new application process after layers of calls;

④New process: execute the handleChildProc method and finally call the ActivityThread.main() method.

2. Bind Application

After creating the process above, execute the ActivityThread.main() method, and then call the attach() method.

Bind the process to the specified Application. This is done by calling the bindApplication() method in the ActivityThread object in the previous section. This method sends a BIND_APPLICATION message to the message queue, which is eventually processed by the handleBindApplication() method. Then the makeApplication() method is called to load the App classes into memory.

The method call flow chart is as follows:

A more straightforward explanation of the process:

(If you don’t understand the terms AMS, ATP, etc., there are explanations later)

3. Display the Activity interface

After the first two steps, the system already has the process of the application. The subsequent calling sequence is just like starting an activity in a new process from an existing process.

The actual calling method is realStartActivity(), which calls scheduleLaunchActivity() in the application thread object to send a LAUNCH_ACTIVITY message to the message queue, and handles the message through handleLaunchActivity(). In handleLaunchActivity(), the onCreate() and onStart() methods of the Activity are called back through the performLaunchActivity() method, and then the onResume() method of the Activity is called back through the handleResumeActivity() method, and finally the Activity interface is displayed.

A more straightforward explanation of the process:

4. Binder Communication

Short name:

ATP: ApplicationThreadProxy

AT: ApplicationThread

AMP: ActivityManagerProxy

AMS: ActivityManagerService

Diagram:

①The startProcessLocked method is called in the system_server process. This method eventually informs the Zygote process of the need to create a new process through the socket, and blocks and waits for the Socket to return the pid of the newly created process;

②When the Zygote process receives the message sent by system_server, it copies the zygote process to generate a new process through the fork method, and loads the resources related to ActivityThread into the new process app process. This process may be used to carry components such as activity;

③ In the new process app process, query the service manager for the binder server AMS in the system_server process to obtain the corresponding client, that is, AMP. With this pair of binder c/s pairs, the app process can send a request to the cross-process system_server through the binder, that is, attachApplication()

④After the system_server process receives the corresponding binder operation, it uses ATP to send a binder request to the app process after multiple calls, namely bindApplication.

system_server has ATP/AMS, and each newly created process will have a corresponding AT/AMP, so that cross-process communication can be carried out. This is the complete ecological chain of the process creation process.

The above roughly introduces the process of an APP from startup to the main page display. It mainly introduces the process from a macro perspective, and the specific understanding can be combined with the source code.