Shulou(Shulou.com)06/03 Report--

This article introduces you how to use the cpumemorynetwork analyzer in AndroidProfiler, the content is very detailed, interested friends can refer to, I hope it can be helpful to you.

CPU Analyzer CPU Profiler

The CPU parser helps you check your application's CPU usage and thread activity in real time, and record method traces so that you can optimize and debug your application's code.

To open CPU Profiler, follow these steps:

Click View > Tool Windows > Android Profiler (or click on the toolbar).

Select the device and application process to configure from the Android Profiler toolbar (if you have connected the device through USB but do not see it, make sure that USB debugging is enabled)

Click anywhere in the CPU Timeline to open CPU Profiler.

1.1 Why optimize the use of CPU

Optimizing CPU usage has many advantages, such as providing a faster and smoother user experience and maintaining device battery life. It can also help your application work well on a variety of newer and older devices, and you can use the CPU parser to monitor CPU usage and thread activity as you interact with the application, but you should record and check the method trace for more detailed information about the application's code execution.

For each thread in the application process, you can find out which methods are executed over a period of time and the CPU resources consumed by each method during execution. You can also use method tracking to identify the caller and the callee, the caller is a method that invokes another method, and the callee is a method called by another method. You can use this information to determine which methods invoke specific resource-heavy tasks too frequently, and you can try to optimize the application's code to avoid unnecessary work.

If you want to collect detailed system-level data to help you examine local system processes and resolve UI jank caused by frame loss, you should use Systrace. Or, if you are exporting a .trace file captured using Debug, you should use Traceview

1.2 Overview of CPU Profiler

When you open the CPU parser, it immediately starts displaying the application's CPU usage and thread activity. You will see something similar to the following picture.

① Event timeline: displays the activity of your application transitioning to different states during its life cycle and indicates the user's interaction with the device, including screen rotation events. To learn more about the event timeline, including how to enable it, read enable Advanced Analytics in my previous article

② CPU timeline: shows your application's real-time CPU usage (as a percentage of the total available CPU) and the total number of threads used by your application, and the timeline also shows the CPU usage of other processes (such as system processes or other applications), so you can compare it with application usage. You can check historical CPU usage data by moving the mouse along the horizontal axis of the Timeline.

③ Thread activity timeline: list each thread that belongs to your application process and use a different color to indicate its activity on the timeline. After the recording method is tracked, you can select a thread from this timeline to check its data in the trace pane.

Green: the thread is active or ready to use CPU. That is, it is in the "runnable" or "runnable" state.

Yellow: the thread is active, but it is waiting for an I / O operation (such as file or network I / O) before completing its work.

Gray: threads are sleeping and do not consume any CPU time, which sometimes occurs when threads need to access resources that are not yet available. Either the thread goes to voluntary sleep or the kernel hibernates the thread until the required resources are available.

④ Tracing type: allows you to select one of the following options to determine how the parser records method tracking.

Sampled: you can frequently capture the application's call stack during application execution. Profiler compares the captured datasets to get information about the timing of application code execution and resource usage. An inherent problem based on sampled tracing is that if your application captures the call stack and exits the method before the next capture, the method call will not be logged by the parser. If you are interested in tracing methods with such a short life cycle, you should use tool tracing.

Instrumented: record the timestamps at the beginning and end of each method call while your application is running. Collect timestamps and compare them with generation method tracking data, including time information and CPU usage. Note that the overhead of detecting each method affects run-time performance and may affect performance analysis, so this is more noteworthy for methods with relatively short lifecycles. In addition, if your application executes a large number of methods in a short period of time, profiler may quickly exceed its file size limit and cannot record any further trace data.

⑤ Record button: starts and stops logging method tracking. For more information, please keep reading.

Tip: profiler also reports the CPU usage of threads added by Android Studio and Android platforms during your application, such as JDWP, Profile Saver, Studio:VMStats, Studio:Perfa, and Studio:Heartbeat (although the exact names shown in the thread activity timeline may be different). This means that the CPU usage of your application on the CPU timeline also reports the CPU time used by these threads. You can see these threads in the thread activity schedule and monitor their activity. However, because profiler threads execute native code, method trace data cannot be recorded for them.) Android Studio reports this data so that you can easily identify that thread activity and CPU usage are actually caused by your application code.

1.3 tracking of recording and inspection methods

To start recording method tracking, select Sampled or Instrumented type from the drop-down menu, then click Record to start recording, and then click Stop recording to stop recording. Profiler automatically selects the recorded time frame and displays its tracking information in the method tracking pane, as shown in the following figure. If you want to check the method trace for different threads, simply select it from the thread activity timeline.

① Selected time frame: the part of the record time frame checked in the trace pane. When you first record a method trace, the CPU analyzer automatically selects the entire length of your record in the CPU timeline. If you want to check the method tracking data for only part of a recorded time frame, you can click and drag the edge of the highlighted area to change its length.

② Timestamp: represents the start and end times tracked by the recording method (as opposed to when profiler starts collecting CPU usage information from the device). You can click the timestamp to automatically select the entire record as your selected time frame-this is useful if you have multiple records you want to convert.

③ Trace pane: displays the method tracking data for the time frame and thread of your choice. This pane appears only if you record at least one method trace. In this pane, you can choose how to view each stack trace (using the trace tab) and how to measure execution time (use time refer to the drop-down menu).

④: select the graphs that are displayed as Top Down tree, Bottom Up tree, Call Chart, or Flame Chart. You can learn more about each trace pane tab in the following sections.

Select one of the following options from the drop-down menu to determine how to measure timing information for each method call:

Wall clock time: indicates the actual elapsed time.

Thread time: timing information represents any part of the actual elapsed time minus any period of time that does not consume CPU resources. For any given method, its thread time is always less than or equal to its clock time. Using thread time gives you a better understanding of the actual CPU usage of threads consumed by a given method

1.3.1 check the trace using the Call Chart tab

The Call Chart tab provides a graphical representation of method tracking, where the period and time of a method call (or caller) is represented on the horizontal axis, while its callees is displayed on the vertical axis. Method calls to the system api are shown in orange, your application's own methods are shown in green, and method calls to third-party api (including the java language api) are shown in blue. The following figure shows an example call diagram and illustrates the concepts of self-time, sub-time, and total time for a given method. For the section on how to use top-down and bottom-up check marks, please read on

Tip: if you want to jump to the source code of a method, right-click the method and select Jump to Source. This can be done from any pane tab.

1.3.2 check for traces using the Flame Chart (Flame Chart) tab

The Flamogram tab provides a reverse call diagram that aggregates the same call stack. That is, the same method of collecting the same sequence of calls is collected and represented as a longer column in the flame graph (rather than displaying them as multiple shorter bars, as shown in the call diagram). This makes it easier to see which methods consume the most time. However, this also means that the horizontal axis no longer represents the timeline, instead, it represents the relative time that each method executes.

To help illustrate this concept, consider the call diagram in figure 4 below. Note that method D makes multiple calls to B (B1, B2, and B3), some of which make calls to C (C1 and C3).

Because B1, B2, and B3 share the same sequence caller (A → D → B) aggregation, as shown below. Similarly, C1 and C3 aggregate because they share the same sequence caller (A → D → B → C) note that C2 is not included because it has different caller sequences (A → D → C).

The aggregate method call is used to create the flame diagram, as shown in the following figure. Note that for any given method call, the callees that consumes the most CPU time appears first in the flame diagram.

1.3.3 use top-down and bottom-up checks

The Top Down tab displays a list of method calls, and the extended method node displays its callees. The following figure shows the top-down diagram of the invocation diagram in figure 3 above. Each arrow in the figure is from the caller to the callee.

As shown in the following figure, the node that extends method An in the top down tab displays its callees, methods B, and D. After that, the node of the extended method D will expose its callees, methods B and C, and so on. Similar to the flame chart tab, the top-down tree aggregates trace information and is used to share the same methods of the same call stack. That is, the flame chart label provides a graphical representation of the label under the top.

The Top Down tab provides the following information to help describe the CPU time spent on each method call (time also represents a percentage of the total thread time within the selected time period):

Self: the amount of time a method call uses to execute its own code instead of its callees, as shown in figure 3 above.

Children: the method call spends time executing its callee rather than its own code, as shown in method D in figure 3.

Total: the sum of the time of the method's Self and Children. This represents the total amount of time the application takes to perform method calls, as shown in figure 3, method D.

The Bottom Up tab displays a list of method calls, and the node that extends the method shows its caller. Using the example shown in the above figure, the following figure provides a bottom-up approach C. Open the node of method C in the bottom-up tree, showing each unique caller, methods B and d. Note that although B calls CPerry B twice when the enlarged node appears only once, the tree of the bottom-up method C. After that, expand node B to show its caller methods An and D.

The Bottom Up tab is useful for sorting methods that consume the most (or least) CPU time. You can examine each node to determine which callers spend the most CPU time calling these methods. Compared to the above tree, the timing information for each method in the bottom tree is the method at the top (top node) of each tree. During recording, the CPU time is also expressed as a percentage of the total thread time. The following table helps explain how to interpret timing information for top-level nodes and their caller methods (child nodes).

For a given record, when profiler reaches the file size limit, Android Studio stops collecting new data (but this does not stop recording). This usually happens faster when performing a detection trace because this type of trace collects more data in a shorter period of time rather than sampling a trace. If you extend the check time frame to the recording period that occurs after the limit is reached, the timing data in the trace pane will not change (because there is no new data available). In addition, when you select only the part of the record that does not have available data, the trace pane displays NaN for timing information.

Memory Analyzer memory profiler

The memory analyzer is a component of Android Profiler that helps you identify memory leaks and spills, resulting in stubs, freezes, and even application crashes. It shows a real-time graph of application memory usage, allowing you to capture heap dumps, force garbage collection, and track memory allocations.

To open the memory analyzer, just like the cpu inspector, it is next door.

2.1 Why do you use a memory analyzer

Android provides a managed memory environment-when it determines that your application is no longer using certain objects, the garbage collector releases unused memory back to the heap. At some point in all Android versions, the system must briefly pause the code. Most of the time, the pause is imperceptible. However, if your application allocates memory faster than the system collects, your application may be delayed and the collector frees up enough memory to meet your allocation. Delays can cause the application to skip frames and cause significant slowness.

Even if your application does not appear slow, if it leaks memory, it can still retain that memory, even if it is in the background. This behavior can degrade other parts of the system's memory performance by enforcing unnecessary garbage collection events. Eventually, the system has to kill your application to reclaim memory. Then when the user returns to your application, it must be restarted.

To help prevent these problems, you should use a memory analyzer to do the following:

Look for poor memory allocation patterns in timelines that can cause performance problems

Dump Java heap to see which objects are using memory at any time. Long heap dumps can help identify memory leaks.

Record memory allocations during normal and extreme user interactions to accurately determine which objects your code allocates or which objects are leaked in a short period of time.

For information about programming practices that can reduce application memory usage, see Managing Application memory.

2.2 Overview of memory Analyzer

As shown in the above figure, the default view of the memory analyzer includes the following:

A button for the ① to enforce garbage collection events.

The button for ② to capture heap dumps.

A button for ③ to record memory allocation.

④ zooms in on the timeline button.

A button for ⑤ to jump to real-time memory data.

The ⑥ event timeline displays active status, user input events, and screen rotation events.

⑦ memory usage schedule, which includes the following:

A stack diagram of how much memory is used for each memory category, as shown in the y-axis on the left and the color key at the top.

The dotted line represents the number of allocated objects, as shown in the y-axis on the right.

The icon for each garbage collection event.

However, not all analysis data is visible by default. If you see a message saying that advanced analysis is not available for the selected process, you need to enable advanced analysis to see the following:

Event schedule

Number of assigned objects

Garbage collection event

Tip: the new memory analyzer records your memory usage compared to the previous Android monitoring tool, so it looks like your memory usage will be higher. The memory analyzer monitors some additional categories that increase the total, but if you only care about Java heap memory, the number of "Java" should be similar to that of the previous Android monitor. The new number records all physical memory pages in the Java heap dispatched from Zygote to the application, which indicates exactly how much physical memory your application actually uses.

2.3 record memory allocation

When looking at heap dumps, it is useful to see a snapshot of how much memory has been allocated, which does not show how memory is allocated. To do this, you need to record the memory allocation. After completing the recording session, you can see the duration of the following records:

Which objects are allocated and how much space they use.

Assign the location of each object, including threads, in the stack trace.

To view the memory allocation for your application, click Record memory allocations in the memory analyzer toolbar. When it records, interact with your application to cause memory spills or leaks. When you are finished, click Stop recording.

The list of assigned objects appears below the Timeline, grouped by class name and sorted by heap count, as shown in the figure above.

The allocation tracker records up to 65535 allocations. If your record exceeds this limit, only the last 65535 assignments will be saved in that record.

To check the allocation record, follow these steps:

Browse the list for objects that have a very large heap count and may leak. To help find known classes, click the class name column header to sort alphabetically. Then click a class name, and the Instance View pane appears on the right, showing each instance of the class, as shown in the following figure.

In the Instance View pane, click an instance. The Call Stack tab is shown below, showing which instance is assigned to which thread.

In the Call Stack tab, click any row to jump to the code in the editor.

By default, the list is arranged by class name. At the top of the list, you can use the right drop-down menu to switch between lists:

Arrange by class: assigned according to the class name.

Arrange by package: allocated according to the package name.

Arrange by callstack: sort by call stack

2.4 capture heap dump

The heap dump shows the objects that the application was using memory when the heap dump was captured. Especially after extending the user session, heap dumps can help identify memory leaks by displaying objects that are still in memory. After capturing the heap dump, you can view the following:

What types of objects are assigned to your application, and the number of objects per object.

How much memory is used per object

The reference to each object is kept in your code.

The call stack, which is used to allocate the location of the object (only when the record allocation captures the heap dump).

To capture the heap dump, click the dump Java heap in the Memory-Profiler toolbar. The amount of Java memory may increase temporarily when you dump the heap. This is normal because heap dumps occur in the same process as the application and require some memory to collect data.

The heap dump appears below the memory timeline, showing all class types in the heap, as shown in the figure above.

To check your heap, follow these steps:

Browse the list to find an object with an unusually large heap count because it may be compromised. To help find known classes, click the class name column header to sort alphabetically. Then click the class name. The instance view pane appears on the right, showing each instance of the class, as shown in the following figure.

In the Instance View pane, click an instance. The References tab is shown below, showing all references to the object. Or click the arrow next to the instance name to view all its fields, and then click the field name to view all its references. If you want to view instance details for a field, right-click the field and select Go to Instance.

In the References tab, if you identify a reference that may be a memory leak, right-click it and select Go to Instance. This will select the appropriate instance from the heap dump and display your own instance data.

By default, heap dumps do not display stack traces for each allocated object. To get a stack trace, you must start recording memory allocations before clicking dump the Java heap. If you do this, you can select an instance in the instance view and see the Call Stack tab next to the References tab, as shown in the following figure. However, some objects may have been allocated before you start recording the allocation, so they cannot use the call stack. An instance that contains a call stack has a stack tag on the icon.

In the classes list, you can see the following information:

Heap Count: the number of instances in the heap.

Shallow Size: the total size in bytes of all instances in this heap.

Retained Size: the total amount of memory reserved by all instances of this class (in bytes).

At the top of the class list, you can use the left drop-down list to switch between the following heap dumps:

Default heap: when the system does not specify a heap.

App heap: the main heap where the application allocates memory.

Image heap: the system boot image that contains classes that are preloaded during boot. The assignment here is guaranteed never to move or leave.

Zygote heap: write-time replication heap of distribution application processes in Android systems

By default, the list is sorted by reserved size column. You can click any column header to change how the list is sorted.

In Instance View, each instance includes the following:

Depth: the shortest hop count from any GC root to the selected instance.

Shallow Size: the size of this instance.

Retained Size: the amount of memory this instance dominates (according to the dominator tree).

3. Network Analyzer (Network Profiler)

The network analyzer displays real-time network activity on the timeline, showing data sent and received, as well as the number of current connections. This allows you to check how and when the application transfers data and optimize the underlying code appropriately.

The steps to open the panel are almost the same as above.

3.1 Why use a Network Analyzer

When an application makes a request to the network, the device must use a power-consuming mobile or WiFi radio to send and receive packets. The receiver not only uses power to transmit data, but also uses additional power to turn on and keep awake.

Using a network analyzer, you can find frequent, short spikes in network activity, which means that your application requires the network to open frequently or stay awake for a long time to handle many short requests. This mode indicates that you can optimize your application by batch processing network requests to improve battery performance, thereby reducing the number of times the network must open or receive data. This also allows the network to switch to low power mode to save battery time.

For more information about techniques for optimizing application network activity, see Reducing Network Battery Drain.

3.2 Overview of Network Analyzer

At the top of the window, you can see the event timeline and the ① radio power status (high/low) and wi-fi. On the Timeline, you can click and drag to select part of the ② Timeline to check the traffic. The following ③ window displays the files sent and received in the selected part of the Timeline, including file name, size, type, status, and time. You can sort the list by clicking any column header. You can also see a detailed breakdown of the selected part of the timeline, showing when each file was sent or received.

Click the name of the connection to view the details of sending or receiving the selected file. Click the ④ tab to view the response data, header information, or call stack.

Tip: you must enable advanced profiling to select part of the timeline to check, view a list of files sent and received, or view the details of the selected files sent or received. To enable advanced analysis, check out the previous article

3.3 troubleshoot network connection

If the network analyzer detects a flow value, but does not recognize any supported network requests. You will receive the following error message: "Network Profiling Data Unavailable: There is no information for the network traffic you've selected."

Currently, network analyzers only support HttpURLConnection and OkHttp libraries. If your application uses another network connection library, you may not be able to view your network activity in the network analyzer. If you have received this error message, but your application does use HttpURLConnection or OkHttp, please report the error so that we can investigate the problem.

Summary

The above is the relevant knowledge of AndroidStudio3.0 's latest Android Profiler analyzer (cpu memory network analyzer) introduced to you by the editor. I hope it will be helpful to you. If you have any questions, please leave me a message and the editor will reply to you in time. Thank you very much for your support to the website!

On how to use the cpumemorynetwork analyzer in AndroidProfiler to share here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.