Traceview: What It Is, Android Tracing and Profiling Tool

What Is Traceview in Android

Traceview is a graphical profiler built into Android Studio that displays execution traces of Android application methods as a timeline and call table. It is part of the Android SDK and is available through Android Profiler starting from Android Studio 3.0, as well as through the dmtracedump command-line utility.

Tool Purpose

The main task of Traceview is to help developers find methods that consume the most CPU time. Unlike simple logging, Traceview records the exact entry and exit time of each method, builds a Call Chart and Top-Down tree, allowing visual detection of performance anomalies. The tool is especially useful when profiling the UI thread, where a 16 ms delay causes a frame drop.

History and Development

Traceview first appeared in early versions of the Android SDK as a standalone utility for viewing .trace files. With the release of Android Studio 3.0 (2017), it became part of Android Profiler, gaining integration with live CPU, memory, and network timelines. According to Google I/O 2018, the Android Studio team continues to develop the profiler, adding support for native code through systrace and perfetto. In current versions of Android Studio, Traceview works on top of the Perfetto format but maintains backward compatibility with the classic .trace format.

How Traceview Works

Traceview receives data from the System Tracing mechanism in the Android Runtime (ART). When an application is launched with tracing enabled, ART records the start and end timestamps of each executed method, including the class name, method name, and thread ID.

// Starting tracing in the app code
Debug.startMethodTracing("app_trace")

// Critical code section for profiling
loadHeavyData()

// Stopping tracing — the file is saved to the device
Debug.stopMethodTracing()

System Tracing operates at the ART virtual machine level and registers each method call with microsecond precision. Data is written to a ring buffer to minimize the impact on application performance. After tracing stops, the buffer is flushed to a .trace file on the device’s internal storage.

.trace File Format

A .trace file contains a header with the format version and start time, followed by records for each call: thread ID, method ID, entry timestamp, and exit timestamp. Android Studio automatically loads the .trace file and builds two main views: the Timeline Panel for chronology and the Profile Panel for call hierarchy. By default, the maximum buffer size is 8 MB, but it can be increased via Debug.startMethodTracing(filename, maxSize).

Key Features of Traceview

Traceview provides several complementary data views, each addressing a specific task in performance analysis.

Call Chart

Call Chart is a horizontal timeline where each thread is displayed as a separate lane. Methods are shown as colored rectangles: the rectangle width is proportional to execution time, and nesting reflects the call hierarchy. If a method calls another method, the child rectangle is drawn inside the parent rectangle. This visualization allows instant identification of operations that blocked the thread.

Top-Down and Bottom-Up Trees

The Top-Down tree shows the execution time of a method including all its nested calls — Inclusive Time. The Bottom-Up tree, conversely, shows which parent methods called a given method — useful for finding the source of a heavy operation. The difference between Inclusive and Exclusive Time is critical: a method may execute quickly itself but call a slow child method, which is only visible in Inclusive Time.

Search and Filtering

Traceview supports searching by method name, package, or class. Results are highlighted on the timeline, and the Profile Panel displays statistics only for the found methods. Filtering by threads is also available — you can hide background threads and focus on the main (UI) thread, where delays are most critical.

Data Export

Traceview allows exporting traces in CSV format for further analysis in spreadsheets or charting. In Android Studio, you can also copy a selected timeline fragment as an image — for inserting into bug reports or documentation. For CI/CD, export in Perfetto format is available via the cmdline-tools utility.

How to Use Traceview in Android Studio

Profiling via Traceview is available in two ways: through Android Profiler with live capture and through programmatic Debug API calls. The first method is convenient for ad-hoc analysis, the second for reproducible performance tests.

Capture via Android Profiler

In Android Studio, open the Profiler tab (View → Tool Windows → Profiler), select your device and application process. Click the CPU segment, then select “Trace Java Methods” mode and click Record. After interacting with the application, click Stop — Traceview will automatically open the recorded trace. The default recording duration is limited to 30 seconds, but the limit can be changed in the profiler settings.

Programmatic Tracing Start

For precise profiling of a specific code section, use Debug.startMethodTracing and Debug.stopMethodTracing. The file is saved to the application’s external storage at the path returned by context.getExternalFilesDir(null). After completion, transfer the .trace file to your computer via Android Studio Device Explorer, then open it through File → Open in Android Studio.

Debug.startMethodTracing(
    "heavy_computation",
    Debug.TRACE_COUNT_ALLOCS
)

processLargeDataset()

Debug.stopMethodTracing()

Configuring Tracing Parameters

Debug.startMethodTracing takes three parameters: the file name (without extension), the maximum buffer size (default 8 MB), and flags. The TRACE_COUNT_ALLOCS flag adds object allocation counting — useful for finding memory leaks. Traceview is not suitable for profiling native code — use SimplePerf or Perfetto. For long tests (over 30 seconds), it is recommended to increase the buffer to 64–128 MB via the maxSize parameter.

Reading the Traceview Timeline

The Traceview Timeline consists of two panels: the top Timeline Panel with colored call rectangles, and the bottom Profile Panel with a statistics table. The Timeline Panel shows thread execution from left to right, where each rectangle is a single method call. Rectangle colors are coded by method type: Android system calls (green), application methods (blue), library calls (orange).

How to Read the Profile Panel

In the Profile Panel, each row is a method with columns for Inclusive Time, Exclusive Time, Calls + Recur, and CPU Time. Sort the table by Inclusive Time (descending) to see methods that took the most total time first. If a method with high Inclusive Time has low Exclusive Time — the issue is in its child calls, and you need to expand the tree. For example, ListView.getView may have high Inclusive Time due to image loading calls.

Identifying Bottlenecks

Look for methods with anomalously high Real Time but low CPU Time — this indicates blocking (I/O wait, network operation, lock contention). Methods with high CPU Time require algorithm optimization. For the UI thread, each method should complete within 16 ms — if any call exceeds this threshold, the application drops a frame and the user sees jitter. According to Google recommendations, the total time of all calls in the UI thread per frame should not exceed 8–10 ms, leaving a margin for system operations.

Traceview vs Systrace: Tool Comparison

Although both Traceview and Systrace are Android tracing tools, they solve different tasks and are used at different profiling stages. The main difference is the level of detail: Traceview operates at the Java/Kotlin method level, Systrace at the system process level (CPU, GPU, Binder, SurfaceFlinger).

In practice, both tools complement each other: first Systrace helps identify which system component is causing the issue (e.g., frequent GC or Binder locks), then Traceview allows diving into a specific method inside the application. In Android Studio, both tools are combined in Android Profiler — CPU Profiler automatically selects the optimal recording mode. On devices with Android 12+, Systrace and Traceview work on top of Perfetto, providing a unified data format for all types of profiling.

Code Examples with Traceview

Effective profiling requires more than just starting tracing — you need to properly place capture points and interpret the results. Below are two practical examples: profiling RecyclerView loading and comparing two algorithms in a performance test.

Profiling RecyclerView Loading

The first example is tracing the critical path during list scrolling. RecyclerView calls onBindViewHolder for each visible item, and if this method takes longer than 16 ms, scrolling becomes jerky. Tracing around onBindViewHolder will show which specific operations inside it are taking time.

class MyAdapter : RecyclerView.Adapter<ViewHolder>() {
    override fun onBindViewHolder(
        holder: ViewHolder,
        position: Int
    ) {
        Debug.startMethodTracing("bind_card_$position")

        holder.bind(items[position])

        Debug.stopMethodTracing()
    }
}

Comparing Two Algorithms

The second example is an A/B speed test of two implementations: loading images via Glide versus manual BitmapFactory. This trace allows objective comparison of the Inclusive Time of both strategies and selection of the optimal one. It is important to run each test on a warmed-up device (after 3–5 cycles) under identical conditions (background load, temperature).

fun compareImageLoadingStrategies() {
    // Test A: Glide
    Debug.startMethodTracing("glide_test")
    loadWithGlide()
    Debug.stopMethodTracing()

    // Test B: BitmapFactory
    Debug.startMethodTracing("bitmap_test")
    loadWithBitmapFactory()
    Debug.stopMethodTracing()
}

After running, open both .trace files in Android Studio and compare Inclusive Time in the Profile Panel. If Glide shows 3x less Inclusive Time for the same task — this is an objective basis to choose the library. According to Tony John (Glide developer, 2023), the library uses caching and a thread pool, providing up to 40% gain on repeated loads.