Android Startup Process Analysis

Original: https://www.jianshu.com/p/a5532ecc8377

The author has worked on Qualcomm's Android performance group, and the main work is to optimize the startup time of Android application.

1. App Basics

   To optimize app startup time, the first step is to understand how the app startup process works. There are several basic theories:

   Android application has two major differences with other mobile platforms:

   1. Each Android app is in a separate space, meaning it runs in a separate process with its own VMS,

      Assigned a unique user ID by the system

   2. Android apps are made up of many different components that can also launch components from other apps, so the Android app

      Does not have a program entry like the main () method

   Android application components include:

   Activity: Front-facing interface, direct to user, provide UI and operation

   Service: Background tasks

   Broadcast receivers: Broadcast recipient

   Context Providers: Data providers

Android process and Linux process, by default, each APK runs in its own Linux process, in addition, the default one process inside only one thread = main threads.

There is a looper instance in the main thread that takes a message from the message queue by calling Looper.loop () to do the corresponding processing

So, when does this process start to start properly?

Simply put, the process is started when it is needed, and at any time, when the user or other component calls any of the components in your apk, if your apk is not running at this time,

The system creates a confident process for it and starts it. Typically, this process continues to run until it is killed by the system. The key is that the process is created when it is needed.

For example, if you click on a hyperlink in an email, a Web page will open in your browser. The Email app and browser app are two different apps that run in different processes.

This click event prompted the Android system to create a new process to instantiate the browser's components.

First, let's take a quick look at the Android startup process. Similar to many Linux kernel-based systems, Bootloader starts the kernel and init process when the system is booted. The init process splits more of the underlying Linux processes called daemons (daemon), such as Android Debug Deamon, USB Deamon, and so on. These daemons process the underlying hardware-related interfaces. The init process then launches a very interesting process---"Zygote". As the name implies, this is a very basic process for an Android platform. This process initializes the first VM and pre-loads the common resources required by the framework and many apps. It then opens a socket interface to listen for requests, hatching new VMS on request to manage new app processes. Once a new request is received, Zygote will hatch a new VM based on its pre-loaded VM to create a new process. After you start zygote, the init process starts the runtime process. Zygote will hatch a super management process---System Server. Systemserver will start all system core services, such as activity Manager Service, hardware-related service, and so on. Here, the system is ready to start its first app process---the home process.

1. start the app process

   Users click on an app icon on the home to launch an app:

   The Click event calls StartActivity (Intent), which is eventually called to Activitymanagerservice through the binder IPC mechanism. The service performs the following actions:

   1. The first step is to collect the pointer information for this intent object through Packagemanager's Resolveintent (). Point information is stored in a intent object
   2. The following important step is to verify that you have sufficient rights to invoke the intent object by using the Granturipermissionlocked () method to point to the activity.
   3. If you have permissions, Activitymanagerservice checks and starts the target activity in a new task
   4. Now it's time to check whether the Processrecord of this process exists. If Processrecord is Null,activitymanagerservice creates a new process to instantiate the target activity

   2.1 Creating a Process

   Activitymanagerservice calls the Startprocesslocked () method to create a new process that passes parameters to the zygote process through the socket channel mentioned earlier. Zygote hatching itself,

   and call the Zygoteinit.main () method to instantiate the Activitythread object and eventually return the PID of the new process.

   Activitythread then calls Looper.prepareloop () and Looper.loop () in turn to turn on the message loop.

   The flowchart is as follows:

   2. Binding Application

      The next thing to do is to bind the process to the specified application. This is done by calling the Bindapplication () method from the Activitythread object in the previous section.

      The method sends a BIND_APPLICATION message to the message queue and finally processes the message through the Handlebindapplication () method. Then call the Makeapplication () method

      To load the app's classes into memory.

      The flowchart is as follows:

   4. Start activity

      After the first two steps, the system already has the application process. The subsequent call order is the normal activity to start a new process from an already existing process.

      The actual calling method is Realstartactivity (), which invokes the shedulelaunchactivity () in the application thread object to send a launch_activity message to the

      In Message Queuing, the message is processed by Handlelaunchactivity ().

      Let's say that you clicked on a video-browsing app with the following process:

Android Startup Process Analysis