Stay organized with collections
Save and categorize content based on your preferences.
Recording the Java/Kotlin methods called during your app's code execution lets
you see the callstack and CPU usage at a given time, filtered to Java/Kotlin
methods. This data is useful for identifying sections of code that take a long
time or a lot of system resources to execute. If you want a full view of the
callstack including native call frames, use the
callstack sample
profiling task.
When you record Java/Kotlin methods using the Android Studio profiler, you can
choose the recording type:
Tracing: Instruments your app at runtime to record a timestamp at the
beginning and end of each method call. Timestamps are collected and compared
to generate method tracing data, including timing information. You should use
tracing when you care about the exact methods being called. Because tracing is
an intensive process, if you're using this option it's best to keep your
recording around five seconds or less.
Sampling (legacy): Captures your app's call stack at frequent intervals during
your app's Java- or Kotlin-based code execution. The profiler compares sets of
captured data to derive timing and resource usage information about your app's
Java- or Kotlin-based code execution. You should use sampling if you care more
about timing than the exact methods being called.
CPU Usage: Shows CPU usage of your app as a percentage of total available
CPU capacity by time. Note that the CPU usage includes not only Java/Kotlin
methods but also native code. Highlight a section of the timeline to filter to
the details for that time period.
Interactions: Shows user interaction and app lifecycle events along a
timeline.
Threads: Shows the threads that your app runs on. In most cases, you'll
want to first focus on the topmost thread that represents your app.
To identify the methods or call stacks that take the most time, use the
flame chart or
top down chart.
Content and code samples on this page are subject to the licenses described in the Content License. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.
Last updated 2024-08-29 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2024-08-29 UTC."],[],[],null,["# Record Java/Kotlin methods\n\nRecording the Java/Kotlin methods called during your app's code execution lets\nyou see the callstack and CPU usage at a given time, filtered to Java/Kotlin\nmethods. This data is useful for identifying sections of code that take a long\ntime or a lot of system resources to execute. If you want a full view of the\ncallstack including native call frames, use the\n[callstack sample](/studio/profile/sample-callstack)\nprofiling task.\n\nWhen you record Java/Kotlin methods using the Android Studio profiler, you can\nchoose the recording type:\n\n- Tracing: Instruments your app at runtime to record a timestamp at the\n beginning and end of each method call. Timestamps are collected and compared\n to generate method tracing data, including timing information. You should use\n tracing when you care about the exact methods being called. Because tracing is\n an intensive process, if you're using this option it's best to keep your\n recording around five seconds or less.\n\n | **Note:** The timing information from tracing might deviate from production due to the overhead introduced by the instrumentation itself.\n- Sampling (legacy): Captures your app's call stack at frequent intervals during\n your app's Java- or Kotlin-based code execution. The profiler compares sets of\n captured data to derive timing and resource usage information about your app's\n Java- or Kotlin-based code execution. You should use sampling if you care more\n about timing than the exact methods being called.\n\n| **Note:** If you're interested in tracing methods with lifecycles so short that they're likely to begin and end in between a sampling interval, and thus get missed by the profiler, you should try tracing instead.\n\nJava/Kotlin methods overview\n----------------------------\n\nAfter you [run the **Find CPU Hotspots** task](/studio/profile#start-profiling)\nthe Android Studio Profiler provides the following information:\n\n- **CPU Usage**: Shows CPU usage of your app as a percentage of total available CPU capacity by time. Note that the CPU usage includes not only Java/Kotlin methods but also native code. Highlight a section of the timeline to filter to the details for that time period.\n- **Interactions**: Shows user interaction and app lifecycle events along a timeline.\n- **Threads**: Shows the threads that your app runs on. In most cases, you'll want to first focus on the topmost thread that represents your app.\n\nTo identify the methods or call stacks that take the most time, use the\n[flame chart](/studio/profile/chart-glossary/flame-chart) or\n[top down](/studio/profile/chart-glossary/top-bottom-charts) chart."]]
