When we say fluency, what are we talking about? Different people have different definitions of fluency and different perceptions of the lag threshold, so it is important to clarify what is involved before starting this series of articles, in case there are any differences in understanding, and in case you look at these questions with questions in mind. Here are some basic instructions

  1. For mobile phone users, lag includes many scenarios, such as dropping frames when sliding the list, excessively long white screen for application startup, slow light screen when clicking the power button, no response to interface operation and then flash back, no response when clicking the icon, incoherent window animation, no follow-up when sliding, restarting the phone and entering the desktop lag, etc. These scenarios are a little different from what we developers think of as a problem, and developers tend to analyze these problems in a more nuanced way. This is a cognitive difference between developers and users, especially when dealing with user (or tester) problem feedback
  2. For developers, the above scenario includes fluency (sliding list when dropped frames, window animation incoherent, reboot into desktop phone card), the response speed (application startup hang is too long, slow light screen click the power button and sliding also), stability (interface without reaction and then flash back, click the icon no response) of the three big categories. The reason for this classification is that each classification has different analysis methods and steps, and it is important to quickly identify which category the problem belongs to
  3. Technically speaking, fluency, response speed and stability (ANR) the reason why these three users perception are caton, because the principle of these three problems are consistent, is because the main thread of the Message in a mission timeouts, according to the different timeout threshold division, so to understand these problems, You need to understand some basic operating mechanisms of the system, and this article will introduce some basic operating mechanisms
  4. This series focuses on analyzing problems related to fluency, and there will be a special article on response speed and stability. After understanding the content related to fluency, it will get twice the result with half the effort to analyze response speed and stability
  5. Fluency this series is mainly about how to use Systrace (Perfetto) tool to analyze. The reason why Systrace is the starting point is that there are many factors affecting fluency, including the reasons of App itself and system. The (Perfetto) tool can show the process of the problem from the perspective of the whole machine operation, which is convenient for us to locate the problem initially

Systrace Fluency exercises currently include the following three chapters

  1. Systrace Fluency Practice 1: Understand the Caton Principle
  2. Systrace Fluency Combat 2: Case study: MIUI desktop slide stuck analysis
  3. Systrace Fluency Practice 3: Some questions during Caton analysis

If you are not familiar with the basic use of the Systrace (Perfetto) tool, you should first complete the Systrace basics series

What does the Frame color of Systrace mean?

The Frame flag here refers to the circle above the main thread of the application and has three colors. The color of the Frame flag varies depending on the duration of each Frame

Click the small circle to see the main thread + render thread for this frame (highlighted, others grayed out).

The green frame

The green frame is the most common frame, indicating that the frame is completed in a Vsync cycle

Yellow frame

Yellow frame indicates that this frame takes more than one Vsync period but less than two Vsync periods. The appearance of a yellow frame indicates that the frame may have a performance problem, which may lead to stalling

The red frame

Red frame indicates that the frame takes more than 2 Vsync cycles. The appearance of red frame indicates that there may be performance problem in this frame, which may lead to stuttering

No red frame, no drop frame, right?

Not necessarily, determine whether to drop the frame to see SurfaceFlinger, rather than watch App, this part of the need to have www.androidperformance.com/2019/12/15/… The basis of this article

Yellow frames appear but do not drop frames

As mentioned above, both red and yellow frames indicate that the frame has a performance problem, and yellow frames indicate that the frame takes more than one Vsync cycle, but thanks to Android Triple Buffer (which is now configured with more buffers on high-framerate phones), Even if the main App frame is longer than one Vsync cycle, it will not drop frames due to the Buffer of more buffers

Yellow frames appear and frames drop

The Systrace of this analysis (see the attachment) is that there are no red frames but only yellow frames. Two yellow frames appear in succession. The first yellow frame causes the lag, while the second yellow frame does not

Why does the main thread wait for the render thread?

There are two yellow frames in the first suspect. It can be seen that the main thread of the second yellow frame takes a long time. At this time, it cannot be simply considered as a problem of the main thread (because it is in Sleep state).

As shown in the figure below, because the renderer thread of the previous frame timed out, the renderer thread task of this frame is queued, such as (www.androidperformance.com/2019/11/06/…The main thread in this article is the unblockMainThread that waits for the render thread to complete syncFrameState before continuing.

Why keep sliding don’t let go, won’t jam?

Or this scene (desktop slide left and right), the lag is after the release of the hand, if you do not release the hand, then there will not be the lag, why?

As you can see in the figure below, if the CPU does not let go, there will be a continuous Boost, and the RenderThread will run on the three large cores from 4 to 6. The RenderThread will not run on the small core, so there will be no lag

The Timeout of Boost in this section is 120 ms. The specific configuration is different for each model. Those who are familiar with PerfLock should know that, but I won’t go into details here

If not, how to measure performance?

If this scenario doesn’t stick, then how can we measure the performance of two different machines in this scenario?

You can use adb shell Dumpsys gfxinfo as follows

  1. First determine the package name to be tested, ready to operate to the App interface
  2. Perform 2-3 timesadb shell dumpsys gfxinfo com.miui.home framestats reset, the purpose of this step is to clear the calendar data
  3. Start operations (such as swiping left and right on the command line, or swiping yourself with a finger)
  4. After the operation is complete, run the commandadb shell dumpsys gfxinfo com.miui.home framestatsThere’s a bunch of data coming out, and we only need to focus on a few of them
  5. Focus on the
    1. Janky frames: Frames that exceed Vsync cycles do not necessarily get stuck
    2. 95th Percentile: 95% value
    3. HISTOGRAM: Raw values
    4. PROFILEDATA: Detailed raw data for each frame

Let’s compare this scenario with Oppo Reno 5, taking only part of the data that we’re looking at

Mi – 90 FPS

Oppo – 90 fps

Here are some comparisons. It can be seen that xiaomi’s performance is weaker than Oppo’s when it slides on the desktop

  1. Janky frames
    1. Millet: 27 (35.53%)
    2. Oppo: 1 (1.11%)
  2. 95th percentile
    1. Millet: 18 ms
    2. Oppo: 5 ms

In addition, the GPU data is also interesting. The GPU of Xiaomi Qualcomm 865 is much better than that of Reno 5 Pro, so the GPU data of Xiaomi is better than that of Reno 5 Pro. It can also be inferred that the bottleneck of this scene lies in CPU rather than GPU

Why can’t I see the lag on the screen?

There are several possible scenarios

  1. If the phone used is greater than 60 FPS, such as Xiaomi’s 90 FPS, and 60 FPS is selected for recording, the recording file will not show lag (this problem will also occur when recording on other phones).
  2. If the screen is recorded at a high frame rate (90fps) but played on a device with a low frame rate (60fps) (xiaomi is the case), there will be no lag. For example, when a video is recorded at 90fps but played on a phone, The system will automatically switch to 60 FPS, resulting in no sign of stutter

series

  1. Systrace Fluency Practice 1: Understand the Caton Principle
  2. Systrace Fluency Combat 2: Case study: MIUI desktop slide stuck analysis
  3. Systrace Fluency Practice 3: Some questions during Caton analysis

The attachment

The attachment has been uploaded to Github and can be downloaded by yourself: github.com/Gracker/Sys…

  1. Xiaomi_launcher. Zip: Systrace file of desktop slide card, this case is mainly to analyze the Systrace file
  2. Xiaomi_launcher_scroll_all_the_time. zip: Systrace file that has been sliding on the desktop
  3. Oppo_launcher_scroll. zip: comparison file

About my && blog

  1. About me, I really hope to communicate with you and make progress together.
  2. Blog Content navigation
  3. Excellent Blog Post record – Android performance optimization is a must

A person can go faster, a group can go farther