There are two ways to use TraceView

The two methods can be selected according to the scene. The end result is the same

  • By manually burying points
  • Profile


1.1. Through manual embedding.

Step 1: For example, we know that when we click a button, there will be a lag, so we can use it

// You can test your code with the following code.
// At the beginning, "app" is the last generated performance analysis file
Debug.startMethodTracing("App");

// The code between start and stop is the range of code you want to test
Debug.stopMethodTracing();
Copy the code


Step 2: After running the test code, we click on the Device Explorer in the lower right corner of Studio. After opening it, we need to find the trace file generated by us. The path is in sdcard/Android/data/ project package name /files, as shown in the figure:


Step 3: Double-click the left key directly to open our file as shown in the picture:

Part 1: is the time selection range, the whole section we just specified with the code burying point. The time stamp on it is a time stamp. Part 2: Code representing the current buried point has five threads. You can click on any thread to view part 3: there are four buttons

  • Call Chart
  • Flame Chart
  • Top Down
  • Bottom Up

Let’s look at these four buttons in detail

1.1.1, Top Down

Click on our Top Down as follows:

Red box 1: represents some situations in Main.

  • Total: indicates the Total time required for the execution of the main function
  • Self: represents the execution time of the code in the main function in addition to calling other functions
  • Children: indicates the execution time of calling other functions in the mian function

Red box 2: There are two options that can be switched to Wall Clock Time or Thread Time

  • Wall Clock Time: indicates the actual execution Time of the thread, such as 100ms
  • Thread Time: CPU execution Time, less than Wall Clock Time.

Why are these two times different? To use an inappropriate analogy, such as running a method where threads wait because of a lock. At this Time, the waiting Time is also included in the Wall Clock Time. However, Thread Time is the execution Time of the CPU. The idle Thread does not consume CPU, so it does not count as Thread Time.


Red box 3: method calls in sequence. And the time consumed by each submethod call. This can also be seen as “codification” of the Call Chart table.


1.1.2, Call Chart

Click the Call Chart as follows:

  • So this icon here represents, for example, 2 methods A and B. Method A calls method B, so method A is above method B.
  • Orange: system API method calls
  • Green: indicates its own method call
  • Blue: third-party call


1.1.3, Flame Chart

Click on Flame Chart and see the following:

A->B->C will collect all methods in that order together, or A->B->D will also be collected on the horizontal axis, showing the relative time.


1.1.4, Bottom Up

Click “Bottom Up” below

This opens initX5web() -> to show main(); Which means who called me. InitX5web () is called in main();


1.2. Profile through Andorid Studio

Click Profile to run the project

After running, the picture is as follows:

After moving the mouse pointer to the CPU, double click the CPU, as shown in the picture:

As you can see, this is pretty much the same interface as we did with the code up here, where we have a button, Record, and when we click on it, it changes to Stop; We can do it in the APP and get to the features that we think are stuck or have problems with. Click Stop to form the same file as we trace. It’s all the same inside


Let’s take a small example to solve a problem

For example, in a previous project, I hid my mobile phone number in order not to be harassed. Take a look at the following GIF. Here, AFTER entering the password, I click login. After the network request ends, the dialog has disappeared and has not jumped to our home page, as shown in the picture







In our logcat filter, the keyword: Displayed will show the start time of each Activity in our application. At this point, my start time is 996, close to 1s:







At this time, we try to solve the delay in the second way. According to our Top Down analysis and the Total elapsed time, we go Down to the following point first (assuming that we do not know it is the jump Activity delay) :





There are two methods, dispatchMessage() and next(); Let’s click dispatchMessage to the end and see loadDrawable() in setContentView(). You can see this is the culprit





The problem with setContentView() is loadDrawable(). The layout of MainActivity, whether SRC or background, has a time-consuming bitmap. Here, I did find the large background image in the background of the root layout. After CANCELING this image, I run the program as follows, and it is no longer stuck, and the jump speed is greatly improved:

Print the time and the boot time is changed from 996 to 447:







Here I just give a small example, I hope to learn performance optimization friends help. If you think it works, just like it!!