preface




1. Start analysis







2. The CPU Profiler

2.1 Overview of CPU profilers


  • Green: the thread is active or ready to use the CPU. That is, it is “running” or in the “runnable” state.
  • Yellow: indicates that the thread is active, but it is waiting for an I/O operation (such as disk or network I/O) before it can complete its work.
  • Gray: indicates that the thread is sleeping and is not consuming any CPU time. This occasionally happens when a thread needs to access a resource that is not yet available. The thread goes into self-sleep or the kernel puts the thread into sleep until the required resources are available.
  • Sampled: Records in a fixed period. Frequently capture the application call stack during application execution. The analyzer compares the captured data sets to derive time and resource usage information related to application code execution. The problem with “Sampled” -based tracing is that if an application enters a function after capturing the call stack and exits the function before the next capture, the parser does not log the function call. If you are interested in such a tracing function with a short lifetime, use “Instrumented” tracing.
  • Instrumented: The value is recorded periodically when a function is called. Set up the application at run time to record timestamps at the beginning and end of each function call. It collects timestamps and compares them to generate function tracking data, including time information and CPU utilization. Note that the overhead associated with setting up each function affects runtime performance and may affect analysis data, especially for functions with relatively short life cycles. In addition, if the application executes a large number of functions in a short period of time, the analyzer can quickly exceed its file size limit and cannot record any more trace data.
  • Edit Configurations: Allows you to change certain default values of the “Sampled” and “Instrumented” record configurations above and save them as custom configurations.

2.2 Record and check function tracing

  • Wall clock time: indicates the actual elapsed time.
  • Thread time: The actual elapsed time minus the time that the Thread did not consume CPU resources.

2.2.1 Use Call Chart label to check tracking

2.2.2 Use the Flame Chart label to check the trace









  • Self: Represents the time that a function call takes to execute its own code (not the code of the called party).
  • Children: Represents the time that a function call takes to execute its own called rather than its own code.
  • Summation: the summation of Self and Children times of the function. Represents the total time the application takes to execute a function call.





2.3 Creating Record Configurations





3. The Memory Profiler

3.1 Overview of Memory Profilers


  • A stacked chart showing how much memory is used by each memory category, as shown on the Y-axis on the left and the color keys at the top.
  • The dotted line represents the number of objects allocated, as shown on the Y-axis on the right.
  • An icon used to represent each garbage collection Event.

  • Java: Object memory allocated from Java or Kotlin code.
  • Native: Object memory allocated from C or C++ code.
  • The buffer queue displays the memory used by pixels (including GL surfaces, GL textures, and so on) to the screen. (Note that this is CPU-shared memory, not GPU-dedicated memory.)
  • Stack: The memory used by the native Stack and Java Stack in the application, usually depending on how many threads the application is running.
  • Code: Memory used by the application to process Code and resources such as dex bytecodes, optimized or compiled dex codes,.so libraries, and fonts.
  • Other: Memory that the application system does not know how to classify.
  • Allocated: Number of Java/Kotlin objects Allocated by the application. Objects that do not count toward allocation in C or C++.

3.2 Viewing Memory Allocation

  • What types of objects are allocated and how much space they use.
  • The stack trace for each assignment, which thread is included.
  • When an object is unallocated (Android 8.0+).





  • Arrange by class: Groups all assignments based on class names.
  • Arrange by Package: Groups all assignments based on software package names.
  • Arrange by callstack: groups all assignments into their corresponding callstack.

3.3 Capturing heap dumps

  • Which types of objects are allocated to apply, and how many are allocated to each type.
  • How much memory each object is using.
  • Where in the code each object is still referenced.
  • The call stack to which the object is assigned. (Currently, heap dumps can only use the call stack in Android 7.1 and later if they are captured while recording allocations.)




  • Heap Count: the number of instances in the Heap.
  • Shallow Size: The total Size, in bytes, of all instances in the heap.
  • Retained Size: The total Size (in bytes) of memory Retained for all instances of this type.
  • Default heap: when the system does not specify a heap.
  • App heap: The main heap to which memory is allocated.
  • Image Heap: A system boot Image that contains classes preloaded during boot. The allocation here is guaranteed never to move or disappear.
  • Zygote Heap: copy-on-write heap in which application processes are derived from the Android system.

  • Depth: The shortest number of hops from any GC root to the selected instance.
  • Shallow Size: The Size of this instance.
  • Retained Size: Specifies the memory Size controlled by this instance.

3.4 Save the heap dump as HPROF


3.5 Analyzing Memory Leaks








4. Network Profiler

4.1 Overview of Network Profilers



Recent Articles:

  • 3 minutes to get to the bottom of generics

  • Multithreaded! You only have to read this one

  • Summary of an advanced Android interview for a program yuan

Question of the day:

What other high-end Android Studio operations are there? Whisper it to jack.

Exclusive upgrade community: I Finally Figured it out