Correct use of the Android profiling tool--traceview

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, two pieces of data will appear:

• 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 to use android.os.Debug.startMethodTracing (), and android.os.Debug.stopMethodTracing (); method, when this code is run, There will be a trace file generated in the/sdcard directory, or you can call Startmethodtracing (String tracename) to set the file name of the trace file, and finally you can use ADB pull/sdcard/ The test.trace/tmp command copies the trace file to your computer and then opens it with the Ddms tool and the first image appears.

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
You can see that the 0 (toplevel) Incl Cpu time takes up 100% of the times, this is not to say that 100% of the time is it in the execution, see the following code:

 Public void Top () {    a ();    b ();    C ();    D ();}  

NCL 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:

As you can see from the image above:
The TopLevel incl Cpu time is 1110.943, and io.bxbxbai.android.examples.activity.expandablelayoutmainactivity$ The Incl CPU time of the Simpleadapter.getitemview method is 12.859, indicating the latter's incl CPU time% is approximately 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)

1. 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

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

3. EXCL Real Time
   Ditto

4. 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 Calls + recur Calls value of this method 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.

1. Cpu Time/call The emphasis came to!!!!!!!!!!

This indicator should be said to be the most important, from what can be seen, 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 the Getitemview method of Simpleadapter)
0.643MS is very fast for a adapter GetView method (because there is only one textview in this adapter that I use 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 Children method List of the GetView method to analyze 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 the view in adapter is too complicated?
• Or because you need to have a lot of judgment, set the view's display or hide
• Or because of other reasons ...
  

1. Real Time/callreal and Cpu time I'm not quite sure what the difference is, and my understanding should be:
2. CPU time should be a method that consumes the CPU
3. 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 ~ ~ ~

The MQC test platform is a cloud platform that provides real-machine testing services to a broad range of enterprise customers and mobile developers, with a large number of popular models that provide 7x24 service.

We are committed to providing professional, stable, comprehensive, high-value automated testing capabilities, as well as an easy-to-use process, attentive technical services, and help customers to the lowest cost, the highest efficiency of the application to discover all kinds of hidden dangers (app crashes, various compatibility issues, functional issues, performance issues, etc.), Reduce user churn, improve app quality and market competitiveness.

Copyright NOTICE: This article is reproduced from http://bxbxbai.github.io/2014/10/25/use-trace-view/

Correct use of the Android profiling tool--traceview