Correct use of the Android profiling tool--traceview

Front nagging

Some of the recent listings in the company app are stuck when they slip, and I've started to address them, and before I fix the problem, I'm going to first analyze where the performance bottlenecks of the list slide are. Because TraceView is not used correctly before, the main thing is to not understand the value of the data indicator below the TraceView interface. I used to use the stopwatch class to analyze performance, now feel weak explosion ... But some places stopwatch tool class is very simple and easy to use ~

Online can find a lot of blog to introduce the use of this tool, a lot of it is to explain some of the methods, say a probably, including StackOverflow I also did not find a good explanation traceview each data indicator code what the meaning of the answer

Because I want to solve the slip problem of the list, we have to find the cause of the lag phenomenon, I found the stackoverflow on the other people's scattered answers slowly pondering the use of this tool. Now I have learned, at least can understand each indicator what meaning, finally found this tool is too powerful!!!

TraceView interface

Now take a look at the entire interface diagram, the entire interface consists of two parts, the above is the process you test the execution of each thread, each line Chengjian line; The following is the value of each indicator executed by each method

The above section is the timeline where each thread in your test process runs, and you can see that there is only one main thread executing, because I slipped the list and the main thread (the UI thread) was drawing the View ~

Then I clicked on a method with a sequence number of 133 io.bxbxbai.android.examples.activity.ExpandableLayoutMainActivity$SimpleAdapter.getItemView , and there were two pieces of data:

• Parents
• Children

Parents represents the parent method that calls the 133 method, and you can see that the ordinal is 130. Children represents the other methods that method 133 calls, and you can see that there are several methods.

How to use TraceView

Because this time I'm mainly analyzing the list slippage problem, I'll tell you how I use the tool and how I analyze it.

There are two main ways of using TraceView:

1. The simplest way is to open DDMS directly, select a process, and then press the "Start Method Profiling" button above, and so on when the red dots turn black, it means that TraceView has started to work. Then I can slide one of the following tables (now the operation on the phone will definitely be stuck, because the Android system is checking the calls of each Java method in the Dalvik virtual machine, which I guess). It is best not to exceed 5s because it is best to perform a small range of performance tests . Then click on the button you just pressed, wait a moment will appear above this picture, then can begin to analyze.
2. The 2nd way is the use android.os.Debug.startMethodTracing(); and android.os.Debug.stopMethodTracing(); method, when the code is run, there will be a trace file in the /sdcard directory generated, you can also call startMethodTracing(String traceName) set trace file name, and finally you can use adb pull /sdcard/test.trace /tmp command to copy the trace file to your computer and then open it with the Ddms tool the first picture will appear.

The first approach is relatively simple, but the scope of the test is broad and the second is relatively accurate, but I prefer to use the first one, because it is simple, and it is a measure of your operation . Because the second is more suitable to detect the performance of a particular method, there is no such good, look at the use of scenes and preferences ...

Read the indicators in TraceView

In fact, I started using the TraceView tool in July this year, but I didn't know the meaning of each of these indicators, and I didn't notice its strong place. If you don't understand the metrics in the table below the interface, the data doesn't really matter.

There is no detailed documentation of the use of the TraceView tool on the Internet, including the Android website, which is really more painful.

longitudinal axis

TraceView interface below the table in the vertical axis is each method, including the JDK, the Android SDK, there are native methods, of course, the most important thing is the app you write your own method, some of the Android system's method execution time is very long, Then there's a big chance that your app will call too many of these methods.

There is a number in front of each method, and it is possible that all methods are sorted by the incl CPU time (described later)

The point of a method can be seen in two parts, one is parents, the other is children.

• The parent represents a method that calls this method, which can be called a father method
• Children represents other methods called in this method, which can be called sub-methods

Horizontal

The horizontal axis is a lot of indicators, these indicators mean what really bothers me for a long time ...

Is it possible to measure the performance of a method with only a few minutes? One way must be the shorter the execution time.

1. Incl Cpu time

Define inclusive : All inclusive

The incl Cpu time that can be seen in the 0（toplevel） 100%, this is not to say that 100% of the time is it in the execution, see the following code:

1

2

3

4

5

6

publicvoidtop() {

a();

b();

c();

d();

}

Incl Cpu time represents the total duration of the method top execution, if the execution time of the method top is 10ms, method a executes 1ms, method B executes 2ms, method C executes 3ms, method D executes 4ms (here is to raise a chestnut, in fact, the method A, B, C, The total execution time of D must be smaller than the total execution time of the method top).

And the execution time of the method top method is 100ms, then:

Incl Cpu time

Top
10%

A
10%

B
20%

C
30%

D
40%

As you can see from the image above:
toplevelThe Incl CPU time is 1110.943, and the io.bxbxbai.android.examples.activity.ExpandableLayoutMainActivity$SimpleAdapter.getItemView method's incl CPU time is 12.859, indicating the latter's incl CPU time% is about 1.2%

This indicator represents the total execution time of this method and the method's sub-methods (such as the A, B, C, D methods in the top method)

2. Excl Cpu Time

Understand the Incl CPU time will be able to understand the excl CPU time, or the top method of the above chestnut:

Method top incl CPU time minus the incl of the method A, B, C, D is the excl CPU times of method top

3. Incl Real time

This feeling is similar to incl Cpu time, and the 7th article will talk about it.

4. Excl Real Time

Ditto

5. Calls + recur Calls/total

This indicator is very important!

it represents the number of times this method is executed , the indicator has two values, a call represents the number of times the method is called, recur call represents the number of recursive calls, see:

I have chosen a method to see that the value of this method Calls + Recur Calls is 14 + 0, indicating that the method was called 14 times, but no recursive call

From the children this piece, many method calls are multiples of 13, indicating that there is a judgement in the parent method, but this is not the focus, some of the child method calls calls 26, which shows that these methods are called two times, is it possible to have a duplicate call situation? These are places where performance can be optimized.

6. Cpu Time/call

That's the point,!!!!!!!!!!.

This indicator should be said to be the most important, from the point of view, 133 this method is called 20 times, and its incl Cpu time is 12.859ms, then the 133 method of each execution is 0.643ms (133 This method is SimpleAdapter the method getItemView )

For a adapter getView method 0.643ms is very fast (because adapter there is only one TextView , I used for testing)

If the getView method executes for a long time, it inevitably causes a lag in the list slippage, and can be found in the method getView 's Children method list for the longest time, analyzing the cause of the problem:

• Is it because there are too many calculations?
• Or is it because there is an operation to read the SD card?
• Or is it because it adapter View 's too complicated?
• Or because of the need to have a lot of judgment, set View the display or hide
• Or because of other reasons ...

7. Real Time/call

Real and Cpu time I'm not quite sure what the difference is, and my understanding should be:

• CPU time should be a method that consumes the CPU
• Real time should be the actual runtime of this method

Why do they make a difference? This could be because the CPU's context switch, blocking, GC, and so on, are actually executing a bit longer than the CPU time.

Summarize

TraceView is a very powerful performance analysis tool, because the Android official website on the use of this tool is very few documents, and some Chinese blog is also written to copy, did not say how to use.

Recently I was doing this aspect of performance analysis, slowly pondering the use of such tools, found very powerful, write down to summarize.

There are many performance analysis tools for Android, such as:

• Eclipse Memory Analyzer Tool to analyze the ram usage of Android apps
• Dump UI Hierarchy for UI Atomator, analyzing UI hierarchy
• Systrace
• Other

There are many profiling tools in this toolbar ~ ~ ~

29

Correct use of the Android profiling tool--traceview