Android App Optimizer (6) tool Chapter

This article introduces several tools for performance analysis on Android, all from the SDK, each strong enough for everyone to analyze and use.

First, say TraceView.

This tool in the SDK documentation is a bit more casual and probably says something about it. But the real need to use it to analyze the problem also requires a detailed understanding of how to use and quickly locate the problem.

The following will be divided into four parts:

The first is the basic operation:

1, get trace information, this has two ways, one is to select the Ddms interface needs to check the process, and then click on the start Method Profiling, will come out a mode selection box, we choose the default sample based Profiling just fine, Trace base The one that tracks each method causes the interface to lag and affect the test effect. End click on the same button stop.

2, this in the SDK document is more, in the code that needs to test add the following two methods, the trace is written to the file on SDcard, and then can be copied to the computer with a named line to start TraceView view this file, and the first way to get the same view.

Start tracing to "/sdcard/calc.trace"Debug. startmethodtracing ("Calc"); // ...  //Stop tracingDebug. stopmethodtracing ();

Note: Trace files can also be dmtracedumpGenerates a tree view of another stack call, which is later said.

Then the view structure:

The view shown in the previous two operations, divided into three regions, the 1 area shows the individual threads, the 2 area is the timeline, which shows the time of the execution of the various methods of the relationship, the 3 area is the method details, showing the invocation of each method and some parameter information. Select the time area will perform a zoom operation to display the selected area, double-click the upper right corner or the timeline can be converted to the original size, but this basic will not be used because even if the amplification is difficult to see each method, usually directly see the area 3.

Region 3 is used to analyze the CPU and the actual time-consuming of each method, then these indices must be recognized one by one.

Name: This is obviously the name of each method, expanded after including parents and children,parents is the caller, children is the method called in the other methods as well as itself, indicating that the method stack call information.

Incl CPU time% and incl CPU time: These two are said the method of the body of the overall consumption of CPU times and proportions, the denominator of this ratio is? Look at the following.

This 0 (toplevel) is the entire trace of the monitoring process represented, and all percentages are calculated based on it, and then only the value of the number without% is explained.

Continue to see, the expansion can be seen parents and children the time and proportion of each method, for parents is the current method in the parent method of the time and proportions, children each child is the sub-method in the total execution time of this method accounted for the value and proportion.

EXCL CPU time% and EXCL CPU time: Except for CPU times, how about this, this is still guessing, in some cases this value, such as the area 3 in the figure of the two red areas, the value is the same, that is, the time is the method itself in addition to the time spent in the call child method, But sometimes this value is not related, self is zero excl CPU time is also a value, I guess it should be process scheduling, method calls, and other system processing CPU times. If the value is too large, the time-consuming problem is mainly in the body of the method, and the sub-methods are relatively less time consuming.

The corresponding above parameters have a set of parameters called Real, which refers to the actual run time non-CPU time (including CPU time, switching time and wait time, but Looper.loop, Nativestart.main, Method.invoke Wait a few methods of time more strange, I haven't figured out why! ), which is consistent with the time interval and length on the zone 1 time axis.

Calls+recurcalls/total: This is the number of times and recursive calls that represent the method invocation.

CPU Time/call: The method call consumes CPU time.

Real Time/call: This method executes the actual time spent.

Quick Location Issues:

Through the above explanation of the parameters, I believe we all have an intuitive sense, that is, only need to pay attention to the real time of the relevant parameters and real Time/call value is higher or calls+recurcalls/total higher is to focus on the object, Because a single method execution takes most of the time to optimize, multiple calls need to see if the number of calls can be reduced in the process.

Generally speaking, the implementation of Android functionality has a performance problem, you can have the problem of the operation of the function of this analysis, directly incl Real time by size, pick a few big head to look carefully (the first few such as Looper.loop, Nativestart.main, Method.invoke can be ignored, these several time-consuming is also behind the operation of the cause, and do not aimlessly looking for their own analysis of the problem, this example is the start of the speed of a lot of systematic methods of interference, check sliding card is much simpler. See if the number of calls is inconsistent with the design logic or can be reduced to see if the execution time of the method is to perform database operations Ah, storage read and write Ah, create bitmap ah, or parse a very complex layout and so on.

Stack tree view structure:

This is the need to use the SDK Dmtracedump tool, Zennai I have tried many times can not read the generated trace file, no way to say that experience, to recommend a post it: http://blog.csdn.net/yiyaaixuexi/ article/details/6716884

I actually use and write this blog have reference to this article http://www.oschina.net/news/56500/traceview-android

And then the Systrace.

This is a tool to analyze the system drawing performance, such as why the animation dropped frames are not smooth and so on. Systrace It is more intuitive to analyze the operation of the application and the whole system on the same time line.

First say the basic operation, in the Ddms interface to the left of the Devices window select Capture system wide trace using Android Systrace this, will pop up an Android system trace of the selection box, The parameters of this collection need to be configured: trace file storage path, duration and size of the cache, and finally, the most important thing is that we need to focus on tags, In general, we need to consider the possible reasons for the scenario we are analyzing (for example, we can choose Graphics, resourceloading, Dalvik VMS, and synchronization tags when we analyze animation dropped frames). After setting the OK to collect state, then do we need to analyze the operation to get a trace.html file, in the Chrome browser to enter the Chrome://tracing/,load generated tram.html file.

Let's start by looking at a list of the Systrace graphs that slide the normal test code:

Can briefly take a look at what the figure contains, this picture, see VSync and Surfaceflinger the drawing interval is kept within 16.6ms and good correspondence, so that the drawing can meet 60 frames. However, if it is not optimistic as shown below, I deliberately placed in the adapter GetView method to create the bitmap operation so that the ListView sliding up and down, get the following systrace diagram:

Looking at this simple example above, it's easy to see that because of Decodebitmap and GC, So that the drawing interval is not the original 16.7ms, is currently 34.33ms, that is, now only 30 frames or so, of course, it seems that there will be a lag effect, change is also very good, the DECODEBITMAP process into the sub-thread and do cache processing to reduce GC.

Next mention allocation Tracker

This thing as the name implies Ah, is tracking memory allocation, select a process in DDMS and then in the Allocation Tracker window page Click Start Tracking, enter the tracking status, after performing an operation, click Get Allocatios will list the current memory allocations as shown in the following scenario:

This shows the sequence number, size, type, thread number, and the class and method where the Content object resides in the currently allocated memory allocation. For example, when I create a bitmap in the main thread, I see a record like this:

This makes it easy to track whether there is an unnecessary memory situation in the current operating area, which lists how the entire system allocates memory while the application is running, including the execution of the framework section, and is particularly well suited to analyzing the high peak of current application running memory. You can see which objects occupy a lot of memory can not be optimized, of course, can not analyze memory leaks ah, that depends on the heap and mat analysis.

In fact, there is also a NB tool OpenGL Trace, this thing is commonly used to analyze OpenGL drawing I have not yet said.

PS: Write about the time, inadvertently read a document on the great God: http://blog.csdn.net/innost/article/details/9008691, this shame Ah, said the same thing, that writing and thinking of the giant clear, It really helps the people who use them for the first time. I have to refuel.

Android App Optimizer (6) tool Chapter