Performance optimization tool knowledge combing (3) Debug GPU overdrawing & GPU rendering mode analysis

Performance optimization tool knowledge combing (3) Debug GPU overdrawing & GPU rendering mode analysis

I. Overview

Today, introduce two relatively simple performance optimization tools:

  • Debug GPUoverdraw
  • GPUPresentation mode analysis

In fact, these two tools solve different problems. The reason why they are put together is that they are all Androidanalysis tools that come with the mobile phone. As long as we set the corresponding switch in the settings, we can get the analysis results in real time. Below, let's take a look at how to use them.

2. debugging GPUover drawing

2.1 Application scenarios

This tool is mainly used to check whether the layout is too deep in the layout . First of all, let me explain what overdrawing is. Overdrawing refers to the same pixel on the screen being drawn multiple times . For example, we have a red color ViewB, which is drawn once first, that is, every area where it is located. All pixels are drawn in red. At this time, there is a blue ViewA, which covers ViewBit, so we need to draw each pixel in blue again. This is actually unnecessary. This is the case. At that time, we can use this tool to avoid this from happening.

2.2 How to use

The usage method is very simple. Enter ///, click the Debug GPUoverdraw option, and select the second item in the pop-up box:

After turning on the switch, you can see that there will be rectangles of various colors in the interface, which corresponds to the level of over-drawing. The darker the color, the more serious the over-drawing, which means that the same pixel has been repeatedly drawn too many times , Below, we use a simple example to look at the level of over-drawing. First look at our layout:

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context="browser.android.com.repoperformance.OverDrawActivity">
    <FrameLayout
        android:id="@+id/fl_1"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:layout_marginBottom="100dp"
        android:background="@android:color/white">
        <FrameLayout
            android:id="@+id/fl_2"
            android:layout_width="match_parent"
            android:layout_height="match_parent"
            android:layout_marginBottom="100dp"
            android:background="@android:color/white">
            <FrameLayout
                android:id="@+id/fl_3"
                android:layout_width="match_parent"
                android:layout_height="match_parent"
                android:layout_marginBottom="100dp"
                android:background="@android:color/white">
                <FrameLayout
                    android:id="@+id/fl_4"
                    android:layout_width="match_parent"
                    android:layout_height="match_parent"
                    android:layout_marginBottom="100dp"
                    android:background="@android:color/white">
                    <FrameLayout
                        android:id="@+id/fl_5"
                        android:layout_width="match_parent"
                        android:layout_height="match_parent"
                        android:layout_marginBottom="100dp"
                        android:background="@android:color/white"/>
                </FrameLayout>
            </FrameLayout>
        </FrameLayout>
    </FrameLayout>
</RelativeLayout>
 

Our layout is presented as a hierarchical nesting level, and fl_1has a white background from the beginning, then let's take a look at GPUthe result after turning on the debug overdraw switch:

Can be seen from the above figures, fl_1white drawing is normal, and fl_2and fl_1in due 100dpoverlap region, this region is thus detected it became blue, fl_3and fl_1/fl_2both overlap, so this part of the detected region become a Green, fl_4and so fl_5are the same. Through the above example, you can see that the detection results are divided into four levels, from low to high:

  • blue
  • green
  • Light red
  • Crimson

During development, after we have designed the interface, we should use this tool to check to see if we can avoid over-drawing while ensuring the realization of the function.

3. GPUpresentation mode analysis

3.1 Application scenarios

When this tool is turned on, the drawing of the current interface will be displayed at the bottom of the screen. The GPUpresentation mode analysis has the following functions:

  • Check whether the rendering of each frame meets 16msthe requirements
  • Analyze the time-consuming of each stage of the rendering process of one frame
  • Because it is displayed in real time, we can quickly find the cause of the problem

The use of this tool is similar to the above, the same is to enter the developer options, then click on the GPUpresentation mode analysis, select "display as a bar graph on the screen".

3.2 Detailed usage

In the Android 6.0before and after, GPUshowing the pattern will be different, except that 6.0after it will draw the entire stage more segments, allowing developers to more easily locate the problem.

  • Whether the foundation is 6.0before or after, the principle of this tool is the same. Because the system 16mswill send out a VSYNCsignal every time to notify the refresh UI, if 16msthe drawing is not completed within it, then you must wait until the next time, which will cause the same screen to be seen for a long period of time, that is What we call "carton", the display of the interface is based on this principle:

  • Histogram: The height of each bar of the histogram indicates the time it takes to render this frame. The longer the rendering time, the higher the height of the histogram.

  • Baseline: We can't see the time corresponding to the histogram on the interface, but judge whether the standard time is exceeded by the baseline above the histogram. The baseline corresponds to 16msif the height of the histogram is on the baseline Below, then it means that the drawing time of this frame is less than 16ms.

  • Android 6.0Before this 6.0version, we divided the histogram into the following parts:

  • The blue Update part represents the time of Viewcreation and update DisplayList. If this part is very high, it means that we have a lot of customizations Viewor have onDrawperformed overly complex operations in it.

  • Purple XFer This part Android 4.0is only available later, indicating the time it takes to pass the resource to the rendering thread.

  • The red Execute part represents the time taken by the Android 2Drenderer to OpenGLsend commands to draw and redraw. These commands come from the previous generation Display List. If this part is high, it means Display Liststhat the command in execution takes a lot of time.

  • The yellow Process part represents the time spent CPUwaiting for the GPUoperation to complete. If this part is high, it means that it is GPUcurrently busy.

From the above explanation, we can find that although the name of this tool is called GPU rendering mode analysis , all the information we get comes from CPU, that is to say, we CPUindirectly analyze the current rendering needs from the perspective of Processed information.

The entire rendering process is CPUto GPUissue a command GPUto the screen , and then to render the screen asynchronously. In some cases, because GPUthere is too much work to do, it will cause the CPUneed to wait all the time to issue a new command, and when this happens, we will see that the orange and red parts are particularly long.

6.0The explanation of the previous colors comes from the official document:

http://android.xsoftlab.net/tools/performance/profile-gpu-rendering/index.html

  • Android 6.0After Android 6.0that, it becomes the current eight parts:
    Among them, if the graphic height of the newly added part is higher, it means:
    • Misc/Vsync Delay We performed too many operations in the main thread, which caused us to be unable to keep up with the VSYNCsignal.
    • InputHandling We have done too many operations in the place where user input is processed.
    • Animation We performed a time-consuming operation during the execution of the animation.
    • Measure & Layout: Our layout is too complicated, so that too much time was spent in the process of measurement and layout.
    • Sync & Upload: It takes too long to prepare the picture to be drawn in the current interface.

6.0The corresponding relationship retained before is:

About 6.0After the explanation of each color comes from:

http://hukai.me/android-performance-patterns-season-5/

4. summary

This article mainly focuses on how to use these two tools. Therefore, the principle of the entire rendering is only a brief summary, and will be specifically analyzed in detail later.


For more articles, welcome to visit my Android knowledge combing series: