Android Application optimization (6) tools and android application tools

Android Application optimization (6) tools and android application tools

This article describes several tools used for performance analysis on Android, all of which are provided by the SDK. Each tool is powerful enough for your analysis and use.

TraceView

This tool SDK document is more casual, so I will talk about what is there. However, if you really want to use it to analyze the problem, you also need to know in detail how to use it and quickly locate the problem.

The following sections are divided into four parts:

The first is the basic operation:

1. There are two ways to obtain trace information. One is to select the process to be checked on the DDMS interface, and then click Start Method Profiling. A mode selection box is displayed, you just need to select the default Sample-based profiling. The Trace base will cause the interface to lag due to tracking every method, which will affect the test result. Click Stop at the end.

2. This document describes a lot in the SDK. Add the following two methods to the Code to be tested and write the trace to the file on the sdcard, then, you can copy the file to your computer and start Traceview with the name line to view the file. The view is the same as that in the first method.

    // start tracing to "/sdcard/calc.trace"    Debug.startMethodTracing("calc");    // ...    // stop tracing    Debug.stopMethodTracing();

Note: trace files can also be used dmtracedumpGenerate a tree view of another stack call.

Then the view structure:

As shown in the preceding two operations, the view is divided into three regions. Area 1 shows the timeline of each thread and Area 2, the relationship between the execution time of each method is displayed here. The 3 region shows the method details, the call status of each method, and some parameter information. If you select a time area, the system will zoom in to display the selected area. You can double-click the upper right corner or change the timeline to the original size, but this will not be used because every method is hard to see even if it is zoomed in, generally, you can directly view area 3.

Area 3 is used to analyze the CPU and actual time consumption of each method, so you must understand these indexes one by one.

Name: this is obviously the Name of each method. After expansion, it includes Parents and Children. Parents is the caller, Children is other methods called in this method, and itself, indicating the method stack call Information.

Incl Cpu Time % and Incl Cpu Time: Both of them indicate the total CPU usage Time and proportion of this method. Who is the denominator of this proportion? Let's take a look at the following:

This 0 (toplevel) represents the entire trace of the monitoring process. All percentages are calculated based on it, and you only need to explain the values without %.

Next, we can see the time and proportion of each method of Parents and Children. For Parents, it is the time and proportion of the current method in this parent method, each subitem of Children is the value and proportion of sub-methods in the total execution time of this method.

Excl Cpu Time % and Excl Cpu Time: the CPU Time except for Excl. In this case, we still guess that in some cases, this value is like two red areas in Area 3, the values are the same. That is to say, this Time is the Time spent by the method except for calling the sub-method. However, sometimes this value does not matter. self is zero and Excl Cpu Time also has a value, I guess it should be the CPU time consumed by other systems such as process scheduling and method calling. If this value is too large, the time-consuming issue is mainly in the body of this method, and the sub-method consumes less time.

The preceding parameters have a set of Real parameters, which indicate that the actual running time is not the CPU time (including the CPU time, switching time, and waiting time, but the loose. loop, NativeStart. main, Method. the time for several methods such as invoke is quite strange. I haven't figured out why yet !), It is consistent with the time interval and length on the timeline of area 1.

CILS + recurcils/Total: This indicates the number of Calls to this method and the number of recursive Calls.

Cpu Time/Call: the Cpu Time used by this method.

Real Time/Call: the actual Time it takes to execute this method.

Quick problem locating:

Through the above explanation of each parameter, I believe everyone has an intuitive consciousness, that is, you only need to pay attention to the relevant parameters of Real Time, and the values of Real Time/Call are high or the values of CILS + recurcils/Total are high, because the execution time of a single method needs to be optimized in most cases, multiple calls need to check whether the number of calls can be reduced in the process.

In general, the implementation of a function on Android has a performance problem. You can analyze the problematic operation functions and arrange the Incl Real Time by size, pick a few big heads to take a closer look (the first few are logoff. loop, NativeStart. main, Method. invoke can be ignored. These time-consuming operations are also caused by subsequent operations, and do not seek out questions for your own analysis, the example in this article is that the startup speed is affected by many system methods, so it is much easier to check the slide card .) Check whether the calling Times are inconsistent with the design logic or can be reduced. Check whether the methods with long execution time have performed database operations, stored and read/write, and created Bitmap, or parse complicated la S.

Stack Tree View Structure:

This is the need to use the dmtracedump tool in the SDK, I tried many times can not read the generated trace file, there is no way to say experience here, to recommend a post for everyone: http://blog.csdn.net/yiyaaixuexi/article/details/6716884

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

Then systrace

This is a tool for analyzing the system's rendering performance, such as why the animation is not smooth when frames are dropped. Systrace is more intuitive for analyzing the running status of applications and the entire system on the same time line.

First, let's talk about the basic operation. In the Devices window on the left side of the DDMS interface, select Capture system wide trace using Android systrace. A select box for Android System Trace is displayed, you need to configure the collection parameters: the path, duration, and cache size of the trace file. Finally, the most important thing is to pay attention to tags, generally, we need to consider the possible causes based on the analysis scenario. (For example, we can select Graphics, ResourceLoading, and Dalvik placement files when analyzing the animation frame drop, enter Chrome: // tracing/In the chrome browser and load the generated tram.html file.

First, let's take a look at the systrace diagram obtained from a list sliding normal test code:

Let's take a brief look at what is included in this figure. In this figure, we can see that the draw interval between VSYNC and surfaceflinger is kept within ms, and it works well, this method can meet 60 frames. However, if it is not optimistic as shown in, I intentionally placed the Bitmap creation operation in the getView method of the Adapter, so that the listview slides and gets stuck, and the following systrace figure is obtained:

Looking at the simple example above, it is easy to see that due to decodeBitmap and GC, the draw interval is no longer 34.33 ms. Currently, it is ms. That is to say, this is only about 30 frames, of course, it seems that there will be a choppy effect, and the change is also very good, put the decodeBitmap process into the Child thread and perform cache processing to reduce GC.

Next, we will mention Allocation Tracker.

As the name suggests, this is to track memory Allocation. In DDMS, select a process and click Start Tracking in the Allocation Tracker window page to enter the Tracking status. After performing an operation, click get allow. OS to list the current memory allocation as follows:

The sequence number, size, type, thread number, and class and method of the currently allocated memory are displayed. For example, if I create a bitmap in the main thread, we will see this record:

In this way, it is easy to track whether unnecessary memory exists in the current operation area. This tool lists the memory allocated by the entire system during the application runtime, including the execution of the framework, it is particularly suitable for analyzing the high peak memory usage of the current application program. We can see which objects occupy a large amount of memory and whether they can be optimized. Of course, we cannot analyze memory leaks, the analysis depends on Heap and MAT.

In fact, there is another NB tool OpenGL Trace, which is generally used to analyze OpenGL rendering.

PS: When I was writing about it, I accidentally read a huge article on the Internet: Workshop. I have to cheer up.