A detailed description of the performance analysis tools commonly used by Android: GPU Rendering mode, TraceView, Systrace, Hirearchyviewer

This article will focus on several commonly used Android performance analysis tools:

One, Logcat log

Select Tag=activitymanager, you can roughly know the interface displaying time consumption. When we open an activity, log prints a string of logs as follows:

I/activitymanager:displayed xxx.xxx.xxx/testactivity: +1s272ms (Total +3s843ms)  

• The first time indicates that the system accepts an open intent to the Testactivity interface showing the time 1.272 seconds.
• The second time special circumstances will have. For example, this invocation process: a->b (in OnCreate immediately finish off himself, jump directly to C)->c (testactivity), which contains the B page OnCreate processing and the time of finish. This time if too long, will cause the user to click the jump, the page also stays in the original interface, delay a period of time and then jump. This experience is poor and users will feel stuck and easily clicked multiple times. Many of the application's entry pages are designed to jump into this situation.

Here we only discuss the first time, in this time the system does the following: Activitymanager do some task-related processing----Create activity instances in the application, oncreate-> Initialization of the activity's onresume-> layout-something that is first drawn, this process refers to the case where an activity is first created in a task. If it is cleartop and other processes, may also involve other activity's finish, own onnewintent and so on process.

Second, GPU rendering mode analysis (peofile GPU Rendering tool)

1. On the adnroid phone, turn on this feature: Open "developer Options", "GPU Rendering Mode Analysis", "Display as a bar on the screen"

The GPU rendering mode is used to measure the app's frame rate, which is part of the GPU Profile tool. Currently Android base 60fps in full frame count, 60fps in a second not drawn, so you can calculate the 1÷60≈1.66 (the time required to draw each frame is about 16ms)

2. After the GPU rendering mode is turned on, when your application is running, you will see a row of bars on the screen, from left to right, with each vertical histogram representing a frame of rendering, and the longer the vertical histogram indicates the longer the frame needs to be rendered. With the number of frames that need to be rendered more and more, They will accumulate together so that you can observe the change in the time frame rate.

(1). Green horizontal line stands for 16ms, to make sure that you hit 60fps in one second, you need to make sure that each of these frames is below the green 16ms mark line. Any time you see a vertical bar above the green mark, you'll see that your animation is stuck.  (2). Blue represents the time it takes to measure the drawing, or how long it will take to create and update your displaylist. In Android, a view must be converted to a format familiar to the GPU before it can actually be rendered, simply by a few drawing commands, The complex point may be that your custom view embeds a custom path. Once done, the result is fed into the cache as a Displaylist object, and Blue is the recording of how long it takes to update the view on the screen (in other words, the OnDraw method of performing each view, creating or updating each view's display list object). When you see the Blue line is high, it's possible that a bunch of your views suddenly become invalid (that is, you need to redraw), or your OnDraw function for several custom views is too complex.  (3). Red represents the time of execution, which is part of the time Android performs 2D rendering of the display list, and in order to draw to the screen, Android needs to use the API interface of OpenGL ES to draw the display list. These APIs effectively send data to the GPU, It always shows up on the screen.  (4). The orange part represents the processing time, or the time that the CPU tells the GPU to render a frame, which is a blocking call because the CPU waits for the GPU to send a reply to the command, and if the histogram is high, it means you're giving too much work to the GPU, Too many responsible views require OpenGL commands to be drawn and processed.   

3. If you need to analyze specific detailed data, you need to combine the following commands:

$ adb shell Dumpsys gfxinfo your_package

In the log generated by executing the command, you will find a header titled: Profile data in Ms. This section contains 3 columns of tables that are generated for each of the applications that each window belongs to. In order to use this data, a simple copy of the form into your favorite spreadsheet software will generate a stacked histogram chart. The following figure is a measure of borrowing from someone on the Web:

Each column gives the approximate amount of time it takes to render each frame:

(1). Draw corresponds to the Blue line: The time that is consumed in building the Java display list displaylist.  To be blunt is to execute each view's OnDraw method to create or update the time of each view's Displaylist object. (2). The Process corresponds to the red line: It is the time that consumes the 2D renderer in Android to perform the display list.  The more layers you have, the more drawing commands you want to execute. (3). Execute corresponds to the Orange Line: the time that is consumed in arranging the order of each frame sent over. Or the CPU tells the GPU to render a frame of time, which is a blocking call because the CPU waits for the GPU to send a reply to the command. In fact, it can be simply understood as: Red Line <span style="font-family:arial, Helvetica, Sans-serif;">process time +gpu return </span><span style="font-family:arial, Helvetica, Sans-serif;">gpu</span><span style="font-family:arial, Helvetica, Sans-serif;"> Time to communicate with the CPU </span>

Note: Make smooth at 60 frames, each frame must be less than 16 milliseconds to complete.

About execute: If the execution takes too long, it means that you are running in front of the graphics pipeline. Android can have 3 buffers at run time. If you need another application, it will block until one of the buffers is released. This happens for two reasons. First, your app is drawn quickly in Dalvik but consumes a lot of time in the GPU display list. Second, your application takes a long time to execute the first few frames, and once the pipeline is full he will not be able to catch up.

The GPU profile tool is a great way to help you find rendering-related problems, but it's not that easy to fix these problems. The key to keeping the animation flowing is to keep the vertical bars as close to the Green Line as possible, and you may lose one frame of content at any time over the Green Line. You need to combine the code to analyze it, find the bottleneck of performance, and optimize it. Sometimes you can turn on GPU rendering mode to test the so-called fluency so that the person responsible for designing the product modifies his design to get a good user experience. Third, traceviewandroid with TraceView comparable to Java Performance Tuning tool, you can easily view the execution of the thread, a method of execution time, number of calls, the proportion in the overall, and so on, so as to locate the performance point.
1. There are two ways of running TraceView
(a). Call the Debug class

// where you start debugging, such as the activity's OnCreate function,  add Debug.startmethodtracing ("tracefilename");     // Place to end debugging, such as the activity's OnDestroy function  , add

After running your app for a while and exiting will generate the Tracefilename.trace log file in the SD card root directory, recording the running information for this period of time. Pull log files to PC side, CD to Android SDK Tools folder (or Bind SDK tools directory to system path), run TraceView Tracefilename.trace can open the TraceView analysis interface, the following is the way to start and end the debugging position, so appropriate for the specific code performance troubleshooting. (b). Use DDMS to open the Devices window, select a process, and click the Start method in the upper-right corner profiling

After running the app for a while, click the button that has changed to stop method profiling. Eclipse will automatically eject the debug tag (which can be saved via the menu File->save as), with the interface on top. This method does not need to modify the code, so the non-source program can also be used to troubleshoot. At the same time can be convenient for global performance troubleshooting.

2. Introduction of TraceView interface information. TraceView interface includes time Panel and method panel
(1) The Time Panel (Timeline panel)
The time panel shows the execution of each thread, where [1]main] is the UI main thread.
Move to a location to see the execution information for the method that corresponds to that point, and click on the method panel to select the appropriate method.
Can be left-click and hold the selected area to enlarge the local fine view, different methods with different color labeling

(2) method pane (profile panel)
The method panel shows the execution of all methods, clicking a method to see the execution time area on the corresponding thread, and displaying its parent and child methods.
Each method includes the following columns of information, which can be sorted by clicking on a column to determine the function that produces the performance problem:

1 incl Cpu   time 2 Excl Cpu   time 3 incl Real   time 4 Excl Real   time 5 incl CPU time%   6 Excl CPU time%   7 incl Real time%   8 Excl Real time%   9   calls+recurcalls/total CPUs time/call     One Real time/call  

All time is computed in milliseconds. The specific meanings and functions of each column are as follows:

Iv. Tools for Systrace performance Analysis 1. Systrace is the new performance data sampling and analysis tool in Android4.1. It helps developers to analyze system bottlenecks and improve performance by collecting operational information on key Android subsystems such as Surfaceflinger, Windowmanagerservice, and other framework-critical modules and services. The Systrace features include tracking system I/O operations, kernel work queues, CPU load, and the health of various Android subsystems. In the Android platform, it consists mainly of 3 parts:

• Kernel part: Systrace leverages the Ftrace functionality in Linux kernel. Therefore, if you want to use Systrace, you must turn on kernel and ftrace related modules.
• Data Acquisition Section: Android defines a Trace class. The application can use this class to output statistics to ftrace. At the same time, Android also has a atrace program, which can read statistics from the ftrace and then hand it to the data analysis tool to handle.
• Data Analysis Tool: Android provides a systrace.py (Python script file, located in the Android SDK directory/tools/systrace, which internally calls the Atrace program) to configure how data is collected, such as the label Output file name, etc.) and collect ftrace statistics and generate a result page file for users to view.

Essentially, Systrace is the encapsulation of ftrace in Linux kernel. Android 4.1 Adds Systrace functionality to several key processes and modules in the system. 2. How to use Systracesystrace can be started by command, or by using Eclipse, Android Studio. Systrace tools you can find in the sdk/platform-tools/, or in the source code located under External/chromium-trace. The process of using systrace on various platforms is basically the same:
(1) Mobile phone ready for the interface you want to crawl
(2) Click to start the Crawl (command line is to start executing commands)
(3) Start operation on the phone
(4) After the set time is up, the trace file will be generated and the file will be opened for analysis using Chrome.

• Usingeclipse

  1 . In Eclipse, open an Android application project.   2. Switch to the DDMS perspective, by selecting Window > Perspectives > DDMS.   Select  is  is enabled on the device.   3 . Click the Systrace icon at the top of the Devices panel to configure tracing.   4. Set The tracing options and click OK to start the trace.  

• Using Android Studio

  1 . In Android Studio, open an Android application project.   2. Open the Device Monitor by selecting Tools > Android > Monitor.   3 Select  is  is enabled on the device.   4 . Click the Systrace icon at the top of the Devices panel to configure tracing.   5. Set The tracing options and click OK to start the trace.  

• Usingdevice Monitor

  1. Navigate to your SDK tools/ directory.   2 . Run the monitor program.   3 Select  is  is enabled on the device.   4 . Click the Systrace icon at the top of the Devices panel to configure tracing.   5

• Command Line Usage

You can use Python systrace.py-h to view Systrace's help

1 Usage:systrace.py [Options] [Category1 [Category2 ...] 2Example:systrace.py-b32768-T thegfx input View sched freq3 Options:4-H,--help show ThisHelp message and exit5-o file write HTML to file6-T N,--time=n Trace forN seconds7-B N,--buf-size=n Use a trace buffer size of n KB8-K Kfuncs,--ktrace=Kfuncs9Specify a comma-separated list of kernel functions toTen Trace One-L,--list-Categories A list the available categories and exit --A app_name,--app=app_name -Enable Application-level tracing forcomma-separated the List of apps Cmdlines ---link-Assets link to original CSS or JS resources instead of - embedding them --- from-file=From_file +Read the Trace froma file (compressed) rather than - running a live trace +--asset-dir=Asset_dir A-E device_serial,--serial=device_serial atADB device serial Number

3. Below, we use an example to demonstrate that Systrace is executed using the above command, a file named trace.html is obtained (trace.html is the default file name, and the reader can also specify a different file name on the command line). The generated trace file needs to be opened by Chrome browser, as shown in the Figure trace.html page content is very similar to the TraceView timeline panel. The diagram contains the following content:
(1). Because the-f-l and-I parameters are specified in systrace.py, Systrace generates CPU frequency, payload, and status-related information. They are shown in the first red box in the diagram. As the author of the mobile phone CPU is dual-core, so the figure has CPU0 and CPU1 points. For ease of writing, use CPU N to refer to a core of the CPU.
The line shown in "CPU N" corresponds to the process information that runs on a core during the entire test time.
"CPU N c-state" shows the behavior of a certain CPU state during the entire test time. C-state values are shown in the table below.
The line shown in "CPU N Clock Frequency" shows how often a CPU is running. You can see how often CPU N runs at a point in time by clicking on the color block of this line.
"Cpufreq": This line shows the work of the CPU interactive frequency adjuster (Interactive Governor). The interactive CPU Tuner driver adds a trace of CPU frequency throttling events. Interested readers may wish to read the Include/trace/events/cpufreq_interactive.h file in kernel for more information.
(2). VSYNC: Shows the time of every tick tack about 16ms
(3). The com.example.systracedemo/com.example.systracedemo.mainactivity shown in the figure shows the Tick-tack case in which the application occupies the display buffer. If the use time exceeds 16ms, will cause the interface to display hysteresis and so on phenomenon.
(4). The Surfaceflinger line in the figure shows the CPU time-consuming condition of its function call (as indicated by arrow 1, the running information of the onmessagereceived function in Surfaceflinger).
(5). The bottom-most box in the figure shows details of the current mouse selection in the timeline (that is, onmessagereceived in Surfaceflinger). You can also use the following keyboard operation:

1 Key Description2 W Zoom into the trace timeline. 3S Zoom outOf the trace timeline. 4 a Pan left on the trace timeline. 5 D Pan Right on the trace timeline. 6 e Center The trace timeline on the current mouse location. 7 g Show Grid at the start of the currently selected task. 8shift+g Show Grid at the end of the currently selected task. 9Right Arrow Select the nextEventOn the currently selected timeline. TenLeft Arrow Select the previousEventOn the currently selected timeline.  One Double Click Zoom into the trace timeline.  AShift+double Click Zoom outof the trace timeline.

Find the process ID you want to analyze, and analyze what each thread does in a time class. If you find a method that takes a long time. You can go to the code inside to search for specific implementations. 4. Add trace in your own code
There is already a lot of trace code inside the Android framework. You can also include trace trace debugging in some of your own methods. You need to make sure that Tracebegin and traceend must appear in pairs and must be in the same thread.

1 " performtraversals " );   2 Try {  3     //TODO your  work4finally  {  5    trace.traceend (trace.trace_tag_view);   6 }  

5. Overall, systrace usage is more complex than TraceView, which supports performance data sampling of CPUs, native processes, and even kernel threads, helping developers to perform an exhaustive analysis of the performance of the entire system. Android official also has some introduction to Systrace, please read the reader:
Http://developer.android.com/tools/debugging/systrace.html
Http://developer.android.com/tools/help/systrace.html

Wu, Hierarchyviewer

1. How do I use Hierarchyviewer?

Hierarchy Viewer is a tool released with the Android SDK, located on Android Sdk/tools/hierarchyviewer.bat (the Windows operating system, shown on Mac as Hierarchyviewer), It's also super easy to use, and this tool provides a detailed understanding of the layout of the control in the current interface and the properties of a control (name, ID, height, and so on), and the debug UI interface analyzes its performance.
(1) Connect the device real machine or simulator (the real machine may not connect, I use 2.3, connected, not read the content)
(2) Start the application you want to observe
(3) Open Hierarchyviewer, click the Hierarchyviewer file. After connection such as:

• Load View Hierarchy: The control hierarchy of the interface, viewing the hierarchical relationships of the controls in the interface
• Inspect screenshot: Precise viewing mode, where developers can zoom in or out of any part of the interface to see where and how the controls in the interface are located

(4) Click "Load View Hierarchy", then double click on the top focused window, this is the current window, the current interface hierarchy will be displayed after loading.

(5) Observe the hierarchy chart, this figure is a bit large, you can drag. The View Hierarchy window shows all the view objects of the activity, and a view can be selected to see the details of the view, preferably the show Extras option in the tool.

(6) Observing a single view, selecting a single view will appear as shown in the graphic:

Here you will see the time-consuming measure, Layout, draw. A red or yellow dot in the view node represents a slower view object. Note that low performance does not necessarily indicate a problem, especially as a ViewGroup object, the more child nodes of view, the more complex the structure, the worse the performance. Just look at the color of each view node to find out which is the slowest view object (layout or drawing) so you can quickly identify the problem.

Unreasonable layouts can slow down the performance of our application UI, and Hierarchyviewer can intuitively get information about the UI layout design structure and various properties visually, helping us optimize the layout design.

Hierarchyviewer is one of the tools of our optimizer, which is a very useful tool for Android, which helps us to better view and design the user interface (UI) and is definitely a tool for UI inspection.

Transferred from: http://blog.csdn.net/wangbaochu/article/details/50396512

Android Common Profiling Tools in detail: GPU rendering mode, TraceView, Systrace, Hirearchyviewer (RPM)