Highly recommended article: Welcome to collect Android dry goods to share

##### Read five minutes, 10 o ‘clock every day, and learn for life with you. This is Android programmer

Systrace allows you to collect and examine timing information at the system level for all processes running on the device. It combines data from the Android kernel, such as CPU schedulers, disk activity, and application threads, to generate HTML reports.

This article covers some of the basics of Android development. Here’s what you’ll learn:

  1. Systrace profile
  2. Systrace usage
  3. Fetch Systrace using the command line
  4. Use Systrace to detect UI performance
  5. Use Systrace to detect warnings and drop frames
  6. Shortcut keys to view the Trace file
  7. Add a trace to the code to analyze the problem
  8. Analyze the trace Log using TraceView

# 1. Systrace profile

Systrace allows you to collect and examine timing information at the system level for all processes running on the device. It combines data from the Android kernel, such as CPU schedulers, disk activity, and application threads, to generate HTML reports.

2. Use of Systrace

Method of fetching Systrace

If you want to analyze the Android system or APP problems, first of all we need to grab the Systrace file analysis and find out the cause of the system stuck, or app slow response, and then solve the problem caused by slow in the source code.

Method of fetching Systrace

  1. First, link your phone and turn it onAndroid Device Monitor, select the process to analyze (e.gcom.google.process.gapps), and clickCapture system wide trace using Android systrace(the arrow in the upper right corner of the image below)

  1. The configuration requires capturing Systrace content

At this time, according to different requirements, configure different trace capture time (please do not spend too long, otherwise, part of the capture content will be lost), content, etc. Then click OK to analyze the part of the system that is stuck or running slowly, and the system will automatically collect running information. Then open the generated trace file in Chrome.

Note: If trace has been captured for many times, to avoid data loss, please clear the contents in the cache in time. The cleaning place is in the lower right corner of Android Device Monitor, as shown below

Open the generated Trace file in Chrome, as shown below, which contains each CPU, graphics rendering, input events, and more.

The captured Trace report provides an overview of Android system processes over a specific period of time. It examines the captured trace information and highlights the problems it detects, such as rough UI when displaying motion or animation, and provides suggestions on how to fix them. However, Systrace does not collect information about code execution in the application process. For more details about what methods your application executes and how much CPU resources it uses, use Android Studio’s built-in CPU profiler, or generate trace logs and view them using Traceview.

3. Use the cli to capture Systrace

This document describes how to generate Systrace reports from the command line, browse trace files generated by the tool, and use them to analyze and improve the performance of your application’s user interface (UI).

Before capturing Systrace, complete the following steps:

  1. Download and InstallAndroid SDK Tools
  2. The installationPython ,And include it in your workstation’s execution path.
  3. Connect your phone and open developer optionsUSB DebugOptions.
  4. SystraceThe storage path is as followsandroid-sdk/platform-tools/systrace/

Python Systrace. Py [options] [categories]

For example, the following command calls systrace to log device processes, including graphics processes, within 10 seconds and generate an HTML report called mynewTrace:

python systrace.py --time=10 -o mynewtrace.html gfx

If no category or option is specified, Systrace will generate a report containing all available categories, using the default Settings. The categories available depend on the connected device you are using.

4. Use Systrace to check UI performance

Systrace is particularly useful for checking the UI performance of your application because it can analyze your code and frame rate to identify problem areas and provide possible solutions. To get started, follow these steps:

  1. Connect your phone and run yourapp.
  2. Run systrace with the following command:python systrace.py view --time = 10
  3. After operating your application for 10 seconds,systraceGenerate an HTML report.
  4. Open the HTML report using a web browser.

You can now interact with the report to check device CPU usage during recording. The following sections describe how to examine the information in the report to find and fix UI performance problems.

5. Use Systrace to detect warnings and frame drop problems

The following report lists each process rendering UI frame and indicates each render frame along the timeline. The green frame circle indicates frames rendered in 16.6 ms to maintain a steady 60 frames per second. Frames that took more than 16.6 milliseconds to render are represented by yellow or red boxes.

Note: On devices running Android 5.0 (API level 21) or higher, UI rendering is done on the UI Thread and RenderThread threads. In previous versions, all the work of creating the framework was done on the UI Thread.

Clicking on an F frame provides additional information about the work done by the system to render the frame, including alerts. It also shows you the methods the system is executing at the time the frame is rendered, so you can investigate whether those methods are causing UI Jank.

After selecting slow frames, you may see an alert in the bottom pane of the report. Alert, shown in the figure above, suggests that the framework’s main problem is spending too much time in ListView recycling and rebinding. There are links to related events in the trace that explain more about what the system was doing during that time.

To see each Alert found by the tool in trace and how many times the device triggered the Alert, click on the Alerts TAB at the far right of the window, as shown below. The Alerts panel helps you see what problems are occurring and how often. Think of the Alert panel as a list of bugs to fix, and often a small change or improvement in one area can eliminate all alerts in your application.

If you are doing too much work on UI Threads, you need to figure out which methods are consuming too much CPU time. One way is to add trace flags (see Detecting application code) to the methods you think are causing these bottlenecks to see if these function calls show up in Systrace. If you’re not sure which methods might cause bottlenecks on the UI thread, use Android Studio’s built-in CPU profiler, or generate trace logs and view them using Traceview.

6. View the shortcut key of the trace file

7. Add a trace mark to the code to analyze the problem

Because Systrace displays information about processes at the system level, it is difficult to know what methods your application is executing at any given time in the HTML report. In Android 4.3 (API level 18) and later, you can use the Trace class in your code to mark execution events in an HTML report. You don’t need code to keep track of Systrace, but doing so can help you see which parts of your application code might cause threads to hang or UI to break. This approach differs from using the Debug class, which simply adds flags to systrace reports, which helps you examine detailed APP CPU usage by generating.trace files.

To generate a Systrace HTML report containing detected trace events, run Systrace using either the -a or –app command line option and specify the package name for your application.

We usually cause jank code in doubt, add the following content: Trace. BeginSection (” MyAdapter. OnCreateViewHolder “); And Trace endSection (); These two come in pairs.

If you call beginSection (String) more than once, calling endSection () only terminates the most recently called beginSection (String) method. Therefore, for nested calls, such as the one in the example above, you need to ensure that each call is correctly matched to beginSection () by calling endSection ().

In addition, you cannot call beginSection () on one thread and end it from another – you must call endSection () from the same thread.

8. Use TraceView to analyze trace logs

Traceview is a tool that provides a graphical representation of trace logs. You can set up code to generate logs by using the Debug class. This tracing method is very precise because you can specify exactly where in the code to start and stop recording trace data. If you have not already generated these trace logs and saved them from the connected device to the local computer, go to generating trace logs through the Detection application. Checking these logs with Traceview helps you debug your application and profile its performance.

Tip: You can use dmTracedump on the command line to generate a graphical call stack diagram that tracks log files.

If you don’t need to view trace logs logged by detecting your application using the Debug class, you can use the CPU profiler included with Android Studio 3.0 and later to see the thread and logging method trace for your application.

To view the trace Log content using Android Device Monitor, perform the following steps: Open Android Device Monitor, select File, and open *. Trace Log analysis. Of course, you can use the Android Device Monitor graphics button to trace and see.

When trace logging is turned on, Traceview displays log data using the following two panes:

    1. Timeline pane: A timeline pane that describes when each thread enters and exits
    1. The following sections provide additional information about the TraceView output pane.

1. Timeline pane

Each thread’s execution is displayed in its own process, and the time increases to the right. Each method is shown in a different color. The thin line below the first line shows the children of the selected method (from entry to exit), as shown in the figure below.

2. The configuration file pane

As shown in the figure below, the profile pane provides a list of each method executed by the system during log tracing and the time it took to execute those methods. Methods that call another method are called parent methods, and methods that are called by the parent are called children. When you select a method by clicking on methods, it displays its parent and child items under two separate nodes.

For each method (top-level node), the table shows the included and exclusive times in milliseconds and the percentage of total time. Exclusive time is the time to execute a method’s own code, while inclusive time is the time to execute a method’s own code plus the time to execute a subroutine. Timing information is also reported in CPU time and in real time. CPU time only takes into account the time that threads actively use CPU time, providing absolute time information in real time from the time your application enters a method to the time it exits the method – whether the thread is active or dormant.

For each top-level node in the profile pane, the Calls + Rec, Calls/Total columns in the table (not shown in Figure 2) report the number of Calls to the method and the number of recursive Calls. Or, for parent and child methods, this column shows how many times the method was called as a child or parent of the method in the top-level node.

Traceview is known to have problems

Traceview logging does not handle threads well, causing the following problems:

  • 1. Thread names are not emitted if the thread exits during analysis (fixed in Android 5.1 and later).

    1. The VM reuses thread ids. If one thread stops and another starts, they might get the same ID.

At this point, this has ended, if there is wrong place, welcome your suggestion and correction. Meanwhile, I look forward to your attention. Thank you for reading. Thank you!