When talking about the Android performance problems, caton, response speed, ANR the three performance in terms of the relevant knowledge often together, because the cause of caton, slow response, ANR are similar, but according to important degree, artificially divided into caton, slow response, ANR three, so we can define the broad sense of card, There are three types: lag, slow response and ANR. Therefore, if users report that their mobile phones or apps are stuck, most of them are stuck in a broad sense, and it is necessary to figure out which kind of problem has occurred

If it is animation playback lag, list sliding lag, we generally defined as the narrow sense of the lag, the corresponding English description I think should be Jank; Slow response is generally defined as Slow application startup, Slow on-off screen, and Slow scene switching. I think the corresponding English description should be Slow. If ANR occurs, it is an application non-response problem. The analysis methods and solutions corresponding to the three cases are not quite the same, so we need to separate them

In addition, there are separate standards for performance indicators such as lag, response speed and ANR within App or manufacturer, such as frame drop rate, startup speed and ANR rate. Therefore, it is very important for developers to analyze and optimize these performance problems

This article is the second in the series of response speed. It mainly takes the cold start of Android App as an example to explain how to use Systrace to analyze the cold start of App

If you are not familiar with the basic use of the Systrace(Perfetto) tool, then it is a priority to complete the Systrace basics series. This article assumes that you are already familiar with the use of Systrace(Perfetto)

1. Preparation

This case and the corresponding Systrace are a little more engineering, leaving out a lot of details, because the application startup process involves a lot of knowledge, if every detail, it would be a lot of space. I recommend you to read this article, very detailed: Android app startup process analysis

So here is Systrace as the main line, explain the application startup of each key module about the working process. After understanding the general process, you can go into the parts you are interested in or responsible for by sections. Here is a picture of Systrace and the screenshot of the phone. You can look at this picture first and then go down (Perfetto and Systrace are used in combination in the blog).

To facilitate the analysis of cold start applications, we need to do the following preparations

  1. Enable Binder debugging to display Binder information in Trace (that is, functions called by Binder can be seen in Systrace) – need Root

    1. Enable IPC debug:adb shell am trace-ipc start
    2. After the capture is complete, you can run the following command to close itadb shell am trace-ipc stop --dump-file /data/local/tmp/ipc-trace.txt

  2. Add irq tag to the Trace command. The default command does not contain IRq, so you need to add irq tag by yourself. In this way, after opening Trace, you can see irQ related content. python /mnt/d/Android/platform-tools/systrace/systrace.py gfx input view webview wm am sm rs bionic power pm ss Database network ADB idle PDX sched irq freq Idle Disk workq binder_driver binder_lock -a com.xxx.xxx, pay attention to com.xxx.xxx Replace it with your own package name. If you are not debugging a specific package name, you can remove -a com.xxx.xxx

  3. Recommended: If the Debug App can be compiled using Gradle, you can use the TraceFix library to analyze the response speed problem (see github.com/Gracker/Tra… After access, code staking will be carried out during compilation, and Trace points will be inserted in every function of App code, so that more detailed App information can be seen during analysis

    1. Before using the plug-in, you can only see Trace points in the Framework
    2. After using the plugin, you can see much more information displayed in the Trace (App code logic, Framework code can not peg).

2. Analysis of cold startup process of Android App

This paper takes the cold start of an Android App on the desktop as an example. The whole process of cold start of the application includes the whole process from the user’s touch screen to the complete display of the application, which involves

  1. Touch screen interrupt processing stage
  2. InputReader and InputDispatcher handle the input event stage
  3. The Launcher handles the input event stage
  4. SystemServer handles startup events
  5. Start the animation
  6. Application startup and logic phases

In the last article, we talked about response speed. We need to be clear about the starting point and the end point. For a cold startup, the starting point is the input event, and the end point is the application fully exposed to the user (user actionable).

The following will introduce the whole process from the above key processes through Systrace

2.1 Touch screen interruption processing stage

Since our case is to start an App on the desktop, the touch screen will trigger an interrupt when fingers touch the mobile phone screen. The earliest place we can see this interrupt in Systrace is as follows:

The corresponding CPU SS area and interrupt area (can only be seen by adding irQ tag)

In general, tapping the screen triggers several interrupts, and after these signals are processed, the touch screen driver updates these points to EventHub for further processing by InputReader and InputDIspatcher. This step is usually no problem, the manufacturer of touch screen tuning may focus on here

2.2 InputReader and InputDispatcher handle the Input event stage

InputReader and InputDispatcher are two threads that run in SystemServer and are responsible for handling Input events

Here, since we click an App icon on the desktop, we can see that the events reported at the bottom level include an Input_Down event, several Input Move events and one Input Up event, which constitute a complete click event

Since the Input listener is registered at process creation, and the Launcher is visible in the foreground, the process can receive these Input events and process them according to their type. Input events in SystemServer and App flow in Systrace concrete performance can refer to Android Systrace basic knowledge – input interpretation, here are the core two figures

2.2.1 Input events are circulated in SystemServer

If you want to see more details, you can check out Android Systrace basics – Input

2.2.2 Input events in the Launcher process flow

If you want to see more details, you can check out Android Systrace basics – Input

2.3 The process Launcher handles the Input event stage

The handling of Input events by the Launcher is also an important phase of response time, with two main response speed metrics

  1. Click the desktop to the first frame of the desktop response (generally, when receiving a Down event, the App icon will be gray to indicate that the event has been received; Some custom desktop App ICONS have a zoomed out animation to indicate being pressed.)
  2. The desktop responds to the first frame to start App (this period refers to the time when the desktop processes the App icon after receiving Down and determines the need to start App after receiving Up event)

By the way, the response time from sliding the desktop to the first frame of the desktop (this refers to the scene of sliding the desktop, when sliding the desktop left and right, with a high-speed camera, from the beginning of the finger movement to the first frame of the desktop) is also a very important indicator of response speed, and some manufacturers will also optimize in this aspect. If you are interested, try out the desktop slide scenario from a major vendor (compare Systrace with native machines).

In the scenario of cold start, the Launcher will make a logical judgment after receiving the UP event, and then start the corresponding App (here it is mainly handed over to AMS and back to the SystemServer process).

At this stage, those who do system optimization pay more attention, but those who do App do not need to pay attention to this stage (except for App Launcher). In addition, in the latest version, the application Launcher animation is completed by the SystemServer and the purpose is to make some complex animations without fragmentation. You can use slow motion to take the animation of the application startup and exit. You can see that some application ICONS are layered and even move. This was previously impossible to animate purely on the SystemServer side

2.4 SystemServer Processes the StartActivity Phase

The SystemServer process has two main parts

  1. Process start command
  2. Notification Launcher enters the Pause state
  3. Fork a new process

Process start command

The Binder in the process of the SystemServer call is the Launcher by ActivityTaskManager. GetService () call startActivity

Fork a new process. If the App process is not started, start the process first and then start the Activity. This is different from other starts. Zygote64 (part of App is fork Zygote32)

The Zygote 64-bit process forks

The corresponding App process is displayed

The corresponding code is as follows, and now the App has officially entered its own process logic

After the application is started, SystemServer records the time from the time startActivity is called until the first frame of the application is displayed, as shown in Systrace (note that the end is the first frame of the application, If the application starts with SplashActivity -> MainActivity, then the end of the application is just SplashActivity, and the MainActivity should be fully started by yourself.)

2.5 Application Process Startup

For large applications, the cold startup of the App usually includes the following three parts, and the time of each part will slow down the overall startup speed of the App. Therefore, when optimizing the startup speed, it is necessary to clearly know the end point of the startup of the App (it is necessary to communicate clearly with the test, which is generally the point where the interface remains stable).

  1. Display the first frame of SplashActivity when the application process starts (some apps don’t have SplashActivity, so you can omit this step and directly display the first frame when the process starts to the main Activit)
  2. SplashActivity Displays the first frame to the main Activity
  3. The first frame of the main Activity is fully displayed on the screen

If your App is simple, you may not have a SplashActivity and enter the main Activity directly, so skip the second step.

The application process starts in the first frame of SplashActivity

Since it is a cold start, App processes need to execute bindApplication first after Fork, which is also an important point to distinguish between cold and hot starts. Once the Application environment is created, the components start (in this case, the Activity component; processes started with the Service, Broadcast, and ContentProvider components start these components first after the bindApplication).

The Activity lifecycle functions are executed when the Activity component is created, including onStart, onCreate, onResume, and so on. After that, there will be a Choreographer#doFrame execution (including measure, Layout, draw), initialization of RenderThread and drawing of the first frame task. Combined with SurfaceFlinger’s composition of a Vsync cycle, the first frame of the application is actually displayed (where the finishDrawing is shown below). For details of the process, see Android Systrace Basics – MainThread and RenderThread interpretation

SplashActivity Displays the first frame to the main Activity

Most apps have SplashActivity to play ads. After that, the actual main Activity starts, including the creation of the Activity component. This includes onStart, onCreate, onResume, execution of its own startup logic, WebView initialization, and so on until the first frame of the main Activity is displayed

The first frame of the main Activity is displayed on the screen and is fully loaded and displayed

In general, the main Activity requires multiple frames to display fully, because many resources (most commonly images) are loaded asynchronously, and the first frame may only load a display frame, and the content will not be displayed until it is ready. As you can also see, it’s not very easy to use Systrace to determine the end of an app’s cold launch (unless you’ve agreed with your test that you’re done launching a View after it’s displayed, and then you Tag the View with Systrace, By tracking this Tag, you can roughly determine which frame in a particular Systrace is the point of completion.)

I made a Systrace + screenshots to demonstrate, so that you can know where Systrace corresponds to each stage of App startup (using an open source WanAndroid client).

End

This paper focuses on how to display the complete cold startup process of App in Systrace, which is convenient for people to quickly locate the startup bottleneck through Systrace when optimizing the startup of App, and also for comparison and analysis of competing products.

  1. For how to analyze, you can see Systrace Response speed Practice 1: Understand the response speed principle of the analysis of the routine section
  2. As for how to optimize, you can check out this article about the full record of Android App startup optimization, which will not be repeated here. However, with the development of technology, some optimization methods will disappear, and there will be new optimization methods, I will also maintain this article, if you find a new optimization technology, please leave a message on the blog or add wechat (553000664) to inform me, I will conduct research and update

series

  1. Systrace Response speed Combat 1: Understand the principle of response speed
  2. Systrace Response Speed Combat 2: Response speed Combat analysis – Take start speed as an example
  3. Systrace Response speed Combat 3: Response speed extension knowledge
  4. Systrace Basics – put a link here so you can click on it directly

Refer to the article

  1. Android application startup process analysis
  2. To explore the | App Startup can really reduce Startup time consuming
  3. New member of Jetpack, App Startup
  4. App Startup
  5. Android App startup optimization full record
  6. Android application profiling