The most authoritative performance analysis tool for Android TraceView

What is TraceView?

TraceView is an Android platform equipped with a good performance analysis tool. It can be graphically used to let us know the performance of the program we want to track, and can be specific to method.

The role of TraceView

Review the execution time of the tracking code, and analyze what is a lengthy operation
A call that can be used to track methods, especially the method call relationships of the Android framework layer

How to use TraceView

There are two main ways of using TraceView:

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 below the picture, and then you can start the analysis.

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 image below appears.
An example of the 2nd way:

1. Select a tracking range to add a record code

First, the code must be added to the program to generate the trace file that can be converted to a graph with this trace file.
The code to add is as follows:

Debug.startMethodTracing(“wirelessqa”)；   //开始Debug.stopMethodTracing()；  //结束

Where parameter WIRELESSQA is the name of the trace file to create, Wirelessqa.trace. The default path is/sdcard/wirelessqa.trace, or you can make your own/DATA/LOG/WIRELESSQA, indicating that the file is in/data/log/wirelessqa.trace.

2. Example code reference:

Publicclass Mainactivity extends Activity {@OverrideProtectedvoid onCreate (Bundle savedinstancestate) {Super. OnCreate (Savedinstancestate);        Setcontentview (R.layout.activity_main); Settitle ( This. GetClass (). GetName ()); View Tologinview = Findviewbyid (R.id.to_login);//Start recording Sdcard/wirelessqa.trace fileDebug.startmethodtracing ("WIRELESSQA"); Tologinview.setonclicklistener (NewView.onclicklistener () {publicvoid OnClick (view view) {Intent Intent =NewIntent (Getapplicationcontext (), loginactivity.class);            StartActivity (Intent);    }        }); }@OverrideProtectedvoid OnStop () {Super. OnStop (); Debug.stopmethodtracing ();//end record Wirelessqa.trace}}

Description
The development documentation says that you can add debug.startmethodtracing () to the activity's OnCreate (), and add debug.stopmethodtracing () to OnDestroy (), But in the actual test it is not easy to find this way, because normally our activity's OnDestroy () is determined by the system when it is called, so it may wait for a long time to get the trace file.

Therefore, it is decided to call Debug.stopmethodtracing () in OnStop (). So when we switch to other activity or click on the Home button OnStop () will be called, we can also get the complete trace file.

3. Do not forget to join the access to the SD card permissions

<uses-permissionandroid:name="android.permission.MOUNT_UNMOUNT_FILESYSTEMS"/>   <uses-permissionandroid:name="android.permission.WRITE_EXTERNAL_STORAGE"/>  

4: Open the. trace file using tool trace view under Tools

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

Is:

Read the indicators in TraceView

Let's analyze this diagram in detail (a bit different from the data):

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 incl Cpu time

Define inclusive: All inclusive
You can see (toplevel) that the incl Cpu time takes up 100% of the times, this is not to say that 100% of the time is it in execution, see the following code:
public void Top () {
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:
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)

EXCL Cpu Time

        理解了Incl Cpu Time以后就可以很好理解Excl Cpu Time了，还是上面top方法的栗子：        方法top 的 Incl Cpu Time 减去 方法a、b、c、d的Incl Cpu Time 的时间就是方法top的Excl Cpu Time 了

Incl Real time

       这个感觉和Incl Cpu Time 差不多，第7条会讲到。

EXCL Real Time

    同上

Calls + recur Calls/total

    这个指标非常重要！

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.

Cpu Time/call

    重点来了！！！！！！！！！！

CPU Time

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:

是因为有过多的计算？还是因为有读取SD卡的操作？还是因为adapter中View太复杂了？还是因为需要有很多判断，设置View的显示还是隐藏还是因为其他原因…

Real Time/call

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

Cpu Time 应该是某个方法占用CPU的时间Real Time 应该是这个方法的实际运行时间

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 来分析Android app的内存使用Dump UI Hierarchy for UI Atomator，分析UI层级systrace其他

There are many profiling tools in this toolbar ~ ~ ~

Article reference: https://bxbxbai.github.io/2014/10/25/use-trace-view/
and http://blog.csdn.net/wirelessqa/article/details/8764622

The most authoritative performance analysis tool for Android TraceView