Android TraceView is the most authoritative performance analysis tool, androidtraceview

Android TraceView is the most authoritative performance analysis tool, androidtraceview
What is TraceView?

Traceview is a good performance analysis tool on the android platform. It allows us to understand the performance of the program we want to track in a graphical way, and can be specific to the method.

Role of Traceview

View the execution time of the tracing code and analyze the time-consuming operations
It can be used to trace method calls, especially the method call relationships at the Android Framework layer.

How to Use TraceView

There are two main ways to use TraceView:

The simplest way is to directly open DDMS, select a process, and then press the "Start Method Profiling" button above. After the red dot turns black, TraceView has started to work. Then I can slide the list (the operation on the mobile phone will be very slow, because the Android system is detecting the call of every Java method in the Dalvik virtual machine, which I guess ). The operation should not exceed 5 s, because it is best to conduct a small range of performance tests. Then, click the button that you just clicked. The following image will appear in a moment, and then you can start the analysis.

The 2nd method is android. OS. debug. startMethodTracing (); and android. OS. debug. stopMethodTracing (); method. When this code is run, a trace file is generated in the/sdcard directory. You can also call startMethodTracing (String traceName) to set the file name of the trace file, finally, you can use adb pull/sdcard/test. run the trace/tmp command to copy the trace file to your computer. Then, use the DDMS tool to open the file.
Example 1:

1. Select the tracing range to add the record code

First, you must add code to the program to generate a trace file. With this trace file, you can convert it into a graph.
The code to be added is as follows:

Debug. startMethodTracing ("wirelessqa"); // start Debug. stopMethodTracing (); // end

The wirelessqa parameter is the name of the trace file to be created, wirelessqa. trace. The default path is/sdcard/wirelessqa. trace. You can also Customize/data/log/wirelessqa to indicate that the file is stored in/data/log/wirelessqa. trace.

2. instance code reference:

Publicclass MainActivity extends Activity {@ Override protectedvoid onCreate (Bundle savedInstanceState) {super. onCreate (savedInstanceState); setContentView (R. layout. activity_main); setTitle (this. getClass (). getName (); View toLoginView = findViewById (R. id. to_login); // starts to record sdcard/wirelessqa. trace file Debug. startMethodTracing ("wirelessqa"); toLoginView. setOnClickListener (new View. onClickListener () {publicvoid onClick (View view) {Intent intent = new Intent (getApplicationContext (), LoginActivity. class); startActivity (intent) ;}}) ;}@ Override protectedvoid onStop () {super. onStop (); Debug. stopMethodTracing (); // end record wirelessqa. trace }}

Note:
In the development documentation, you can add Debug in onCreate () of the activity. startMethodTracing (), and add Debug in onDestroy. stopMethodTracing (), but we found that this method is not useful in actual tests, because the onDestroy () of our activity is usually determined by the system when to call, therefore, the trace file may not be obtained for a long time.

Therefore, we decided to call Debug. stopMethodTracing () in onStop (). In this way, when we switch to another activity or click the home Key, onStop () will be called, and we can get the complete trace file.

3. Do not forget to add the permission to access the SD card.

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

4. Use the tool trace view in tools to open the. trace file.

The first method is relatively simple, but the test scope is very broad. The second method is relatively accurate. However, I personally prefer the first method because it is simple, in addition, it is used to detect one of your operations. Because the second method is more suitable for detecting the performance of a method, but it is not as good as that. It depends on the Use scenario and happiness...

Yes:

Understand the indicators in TraceView

Next we will analyze this figure (a little different from the data ):

Vertical Axis

In the table below the TraceView interface, the vertical axis is each method, including the JDK, Android SDK, and native method. Of course, the most important thing is the method you write in the app, in some Android systems, method execution takes a long time, which may be caused by too many calls to these methods in your app.

Each method is preceded by a number, which may be the sequence number of all methods sorted by the Incl CPU Time (which will be discussed later)

After clicking a method, we can see that there are two parts: Parents and Children.

Parent indicates the method to call this method, which can be called the Parent method.

Children indicates other methods called in this method, which can be called submethods.

Horizontal Axis Incl Cpu Time

Define fully inclusive
(Toplevel) Incl Cpu Time accounted for 100% of the Time. This does not mean that 100% of the Time is being executed. Please refer to the following code:
Public void top (){
A ();
B ();
C ();
D ();
}
Incl Cpu Time indicates the total execution Time of method top. If the execution Time of method top is 10 ms, method a executes 1 ms, and method B executes 2 ms, method c executes 3 ms, and method d executes 4 ms (for example, in actual situations, the total execution time of method a, B, c, and d must be a little smaller than the total execution time of method top ).

In addition, the execution time of the method that calls the top method is 100 ms, so:

Incl Cpu Time

Top 10 10%
A 10%
B 20%
C 30%
D 40%
From the figure above, we can see that:
Toplevel Incl Cpu Time is 1110.943, while io. bxbxbai. android. examples. activity. expandableLayoutMainActivity $ SimpleAdapter. the Incl Cpu Time of the getItemView method is 12.859, indicating that the latter's Incl Cpu Time % is about 1.2%

This indicator indicates the total execution time of this method and its sub-methods (such as the, B, c, and d methods in the top method ).

Excl Cpu Time

After understanding the Incl Cpu Time, you can understand the Excl Cpu Time very well. It is still the example of the top method above: the Incl Cpu Time of the method top minus the Incl Cpu Time of method a, B, c, and d is the Excl Cpu Time of the method top.

Incl Real Time

This is similar to the Incl Cpu Time, which will be described in Article 7th.

Excl Real Time

Same as above

Cballs + Recur cballs/Total

This indicator is very important!

It indicates the number of times this method is executed. There are two values in this indicator. One Call indicates the number of times this method is called, and the Recur Call indicates the number of recursive calls. See:

I selected a method, and we can see that the value of cballs + Recur cballs of this method is 14 + 0, indicating that this method has been called 14 times, but there is no recursive call.

From the perspective of Children, many method Calls are multiples of 13, which indicates that there is a judgment in the parent method, but this is not the key. Some Child method Calls CILS 26, this shows that these methods have been called twice. Is there a possibility of repeated calls? These are the places where performance can be optimized.

Cpu Time/Call

The point is !!!!!!!!!!

Cpu time

This indicator should be said to be the most important. As you can see, 133 of this method is called 20 times, and its Incl Cpu Time is 12.859 ms, the execution time of the 133 method is 0.643 ms (133 this method is the getItemView method of SimpleAdapter)

0.643ms is very fast for the getView method of an adapter (because there is only one TextView in this adapter, which I used for testing)

If the getView method takes a long time to run, it will inevitably cause lag when the list slides. You can find the longest method in the Children method list of the getView method to analyze the cause of the problem:

Is there too much computing? Or is there an operation to read the SD card? Or is the View in the adapter too complicated? Or is it because you need to make a lot of judgments, whether to set the View display to hidden or for other reasons...

Real Time/Call

I still don't quite understand the differences between Real Time and Cpu Time. My understanding should be:

Cpu Time should be the CPU usage Time of a method. Real Time should be the actual running Time of this method.

Why are they different? The actual execution Time of the method may be a little longer than the CPU Time because of Cpu context switching, blocking, GC, and other reasons.
Summary

TraceView is a very powerful performance analysis tool, because the Android official website has very few instructions on the use of this tool, and some of the Chinese Blog also writes are copied, I didn't explain how to use it.

Recently I have been doing performance analysis in this area, and I have been pondering over the use of this tool and found it very powerful. Let's write it down and summarize it.

There are many other Android performance analysis tools, such:

Eclipse Memory Analyzer Tool is used to analyze the Memory usage of Android apps using Dump UI Hierarchy for UI Atomator, and analyze other systrace levels at the UI level.

This Toolbar contains many performance analysis tools ~~~

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