ArtMetric

@RequiresApi(value = 24)
public final class ArtMetric extends Metric

Captures metrics about ART method/class compilation and initialization.

JIT Compilation, Class Verification, and (on supported devices) Class Initialization.

For more information on how ART compilation works, see ART Runtime docs.

JIT Compilation

As interpreted (uncompiled) dex code from your APK is run, methods will be Just-In-Time (JIT) compiled, and this compilation is traced by ART. This does not apply to code AOT compiled either from Baseline Profiles, Warmup Profiles, or Full AOT.

The number of traces and total duration (reported as artJitCount and artJitSumMs) indicate how many uncompiled methods were considered hot by the runtime, and were JITted during measurement.

Note that framework code on the system image that is not AOT compiled on the system image may also be JITted, and will also show up in this metric. If you see this metric reporting non-zero values when compiled with CompilationMode.Full or CompilationMode.Partial, this may be the reason. See also "Class Verification" below.

Class Initialization

Class Initialization tracing requires either API 35, or API 31+ with ART mainline version >= 341511000. If a device doesn't support these tracepoints, the measurements will not be reported in Studio UI or in JSON results. You can check your device's ART mainline version with:

adb shell cmd package list packages --show-versioncode --apex-only art

Classes must be initialized by ART in order to be used at runtime. In CompilationMode.None (with warmupRuntimeImageEnabled=false) and CompilationMode.Full, this is deferred until runtime, and the cost of this can significantly slow down scenarios where code is run for the first time, such as startup. In CompilationMode.Partial, this is done at compile time if the class is trivial (that is, has no static initializers).

The number of traces and total duration (reported as artClassInitCount and artClassInitSumMs) indicate how many classes were initialized during measurement, at runtime, without pre-initialization at compile time (or in the case of CompilationMode.None(true), a previous app launch).

These tracepoints are slices of the form Lcom/example/MyClassName; for a class named com.example.MyClassName.

Even using CompilationMode.Partial(warmupIterations=...), this number will often be non-zero, even if every class is captured in the profile. This can be caused by a static initializer in the class, preventing it from being compile-time initialized.

Class Verification

Before initialization, classes must be verified by the runtime. Typically all classes in a release APK are verified at install time, regardless of CompilationMode.

The number of traces and total duration (reported as artVerifyClass and artVerifyClassSumMs) indicate how many classes were verified during measurement, at runtime.

There are two exceptions however:

1. If install-time verification fails for a class, it will remain unverified, and be verified at runtime.

2. Debuggable=true apps are not verified at install time, to save on iteration speed at the cost of runtime performance. This results in runtime verification of each class as its loaded which is the source of much of the slowdown between a debug app and a release app (assuming you're not using a compile-time optimizing dexer, like R8). This is only relevant in macrobenchmark if suppressing warnings about measuring debug app performance.

Class Verification at runtime prevents both install-time class initialization, and install-time method compilation. If you see JIT from classes in your apk despite using CompilationMode.Full, install-time verification failures could be the cause, and would show up in this metric.

Summary

public ArtMetric()