preface

Do Android development for five years, development tools from the initial Eclipse +ADT plug-in to AndroidStduio. Google has also integrated Profiler, an Android application performance analysis tool, into the new AndroidStudio.

This paper analyzes and locates the cause of the problem based on the official AndroidStudio 3.2.1 version. Attached is the download address:

  1. Download the Windows version
  2. Mac version download
  3. The Linux version download

An overview of

In the Run project in AndroidStudio, you can find the Profiler in the bottom TAB. When opened, the Profiler will default to show information about the current run application. Click the plus sign on the top right of the Profiler page to select connected devices and other applications that can be debugged.

As you can see, Profiler can monitor CPU, memory, network, and power usage of selected applications and display them in real time through waveforms, bars, and line charts.

Click the red square in the upper left corner or right-click in the monitoring session to pop up the option box to end the monitoring of the current application or delete the monitoring session.

The top toolbar is in order:

  1. Add processes to be monitored.
  2. End the current monitoring session.
  3. Show/hide the sidebar.
  4. Zoom out the monitoring view.
  5. Zoom in on the monitoring view.
  6. Reset the monitoring view.
  7. Display the collection range.

CPU analysis

In the overview diagram, click on the CPU module to go to the CPU usage analysis page.

The three menus in the figure are:

  1. Can switch to memory, network, electricity monitoring.
  2. Switch between different monitoring targets. , respectively,Sampled Java,Instrumented Java,Sampled Java,System Trace.
  3. Record button, click to start collecting CPU usage information.

Click the Record button to start collecting CPU usage data, and click the Stop button to Stop collecting data. The appearance after collection is shown in the figure.

The dark part in the figure represents the collection range. You can zoom in on the monitoring view, then narrow down the recording range, select a thread, and see the method executed in the thread in detail.

Profiler supports four ways to display executed methods.

  1. Call Chart: display by order of execution, as shown in the figure above.
  2. Flame Chart: Displayed by Flame Chart.
  3. Top Down: Display from the Top Down.
  4. Bottom Up: Call display from the Bottom Up.

By analyzing the view of CPU usage, you can roughly locate the following problems.

  1. Collect CPU usage information for five to six minutes, zoom in and out the view to a minimum, and observe the CPU usage globally during monitoring.
  2. ProfilerUser touch events and page jumps are recorded synchronously. Compare instantaneous CPU usage to find the problem code.
  3. Select a period of time to record, focusing on the analysis of method execution in each thread in this period of time.

The figure above shows the CPU resources used by ImageLoader to load images. It is possible to conclude that the repeated execution of imageloader-related code is itself an anomaly.

A macro analysis of the CPU usage waveform shows that there are periodic CPU usage peaks.

The optimized CPU usage waveform has been attached to eliminate the peak CPU usage.

The reason for the spikes is that method calls from monitoring threads alone are not easy to locate unless you are particularly familiar with the code. Usually, a comprehensive analysis of memory usage and network usage is required to locate problems.

Memory analysis

The memory analysis page is displayed.

The three menus in the figure are:

  1. Can switch to CPU, network, power monitoring.
  2. Manually perform GC to free memory.
  3. Dump memory usage data and save it to text data.

Memory usage can also be analyzed from a macro and micro perspective. Profilers color the amount of memory used by different types of data. The options are Java, Native, Graphics, Stack, Code, and Others.

As shown, memory continues to grow until the system frees up memory resources, so the macro memory waveform is zigzagged. Moreover, it can be seen that the memory occupied by Native space keeps increasing.

From the micro point of view, enlarge the display range, click the dump button to start recording, select the analysis range, and check the space occupied by various types of data in memory.

  1. Distinguish between two types of memory allocation.Live Allocation 和 Heap Dump.
  2. You can view memory allocation for four types of HEAP.image heap 、zygote heap 、app heap 、JNI heap.
  3. Three types of instance view sorting are supported:Arrange by class 、Arrange by package 、Arrange by callstack.

The figure shows the optimized memory monitoring diagram. The memory usage has leveled off.

Network analysis

Network analysis tools are relatively simple. A peak value in the line graph represents a network connection.

By selecting a network connection, you can view the address of the connection request and the data sent and received.

Finally, the optimized network monitoring is attached.

Power monitoring

Power consumption monitoring, which usually does not detect any problems, is generally used to measure the power consumption of applications. If an application fails to consume power, problems can be detected in the CPU, memory, and network monitoring. For example, in the process of network connection, network card module is required to send and receive data, long connection for push function is required to maintain, GC memory and positioning function all need power support. Note the bar chart of power usage in the Light baseline for the before-and-after comparison. The problem of application power consumption has been improved obviously.


conclusion

The above is a brief introduction to the four modules of the memory analysis tool. Perhaps readers are confused about the comparison before and after optimization. The following interpretation, the author to test the problems existing in the application.

Application Details:

  1. The image rotation module is used in the test application, showing a picture every 2~3s.
  2. Load images using ImageLoader.

Normally, ImageLoader supports level 3 caching, and according to the LRU algorithm, the images should be saved in memory and reused. Network connections and memory will not continue to grow.

Question details:

  1. There are two images in the rotation chart, one of which is empty. So ImageLoader will try to initiate a network connection to download the image each time.
  2. When ImageLoader is initialized, the configuration disables memory caching and the global memory cache space is only 2M. The image of the rear tube configuration needs 3M space to load in memory, resulting in memory cache failure.

In summary, the application under test always makes network requests and the memory resource usage keeps increasing, leading to system GC. Indirectly, the application consumes power. Interested children can verify the correlation between peak power consumption, network connection, memory GC and peak CPU usage. The relationship between the four of them is very delicate.

For the sake of space, it is briefly introduced here. Four modules may be elaborated on later. Stay tuned.

Think it works? I’ll give you a bonus.I’d like to make a reward

Here’s the AD: Flueky’s tech site