CompilationMode

public sealed class CompilationMode

Known direct subclasses
CompilationMode.Full

Full ahead-of-time compilation.
CompilationMode.Ignore

This compilation mode doesn't perform any reset or compilation, leaving the user the choice to implement these steps.
CompilationMode.None

No pre-compilation - a compilation profile reset is performed and the entire app will be allowed to Just-In-Time compile as it runs.
CompilationMode.Partial

Partial ahead-of-time app compilation.

Type of compilation to use for a Macrobenchmark.

This compilation mode controls pre-compilation that occurs before running the setup / measure blocks of the benchmark.

On Android N+ (API 24+), there are different levels of compilation supported:

  • Partial - the default configuration of Partial will partially pre-compile your application, if a Baseline Profile is included in your app. This represents the most realistic fresh-install experience on an end-user's device. You can additionally or instead use Partial.warmupIterations to use Profile Guided Optimization, using the benchmark content to guide pre-compilation. This can mimic an application's performance after background dexopt has partially compiled the app during device idle time, after the app has been used (generally after a day or more of usage after update/install).

  • Full - the app is fully pre-compiled. This is generally not representative of real user experience, as apps are not fully pre-compiled on user devices more recent than Android N (API 24). Full can be used to show unrealistic but potentially more stable performance by removing the noise/inconsistency from just-in-time compilation within benchmark runs. Note that Full compilation will often be slower than Partial compilation, as the increased code size creates more cost for disk loading during startup, and increases pressure in the instruction cache.

  • None - the app isn't pre-compiled at all, bypassing the default compilation that should generally be done at install time, e.g. by the Play Store. This will illustrate worst case performance, and will show you performance of your app if you do not enable baseline profiles, useful for judging the performance impact of the baseline profiles included in your application.

  • Ignore - the state of compilation will be ignored. The intended use-case is for a developer to customize the compilation state for an app; and then tell Macrobenchmark to leave it unchanged.

On Android M (API 23), only Full is supported, as all apps are always fully compiled.

To understand more how these modes work, you can see comments for each class, and also see the Android Runtime compilation modes (which are passed by benchmark into cmd compile to compile the target app).

Summary

Nested types
public final class CompilationMode.Full extends CompilationMode

Full ahead-of-time compilation.

This compilation mode doesn't perform any reset or compilation, leaving the user the choice to implement these steps.
@RequiresApi(value = 24)
public final class CompilationMode.None extends CompilationMode

No pre-compilation - a compilation profile reset is performed and the entire app will be allowed to Just-In-Time compile as it runs.
@RequiresApi(value = 24)
public final class CompilationMode.Partial extends CompilationMode

Partial ahead-of-time app compilation.

Public fields
static final @NonNull CompilationMode

Represents the default compilation mode for the platform, on an end user's device.

Protected constructors

Public fields

DEFAULT

public static final @NonNull CompilationMode DEFAULT

Represents the default compilation mode for the platform, on an end user's device.

This is a post-store-install app configuration for this device's SDK version - Partial(BaselineProfileMode.UseIfAvailable) on API 24+, and Full prior to API 24 (where all apps are fully AOT compiled).

On API 24+, Baseline Profile pre-compilation is used if possible, but no error will be thrown if installation fails.

Generally, it is preferable to explicitly pass a compilation mode, such as Partial(BaselineProfileMode.Required) to avoid ambiguity, and e.g. validate an app's BaselineProfile can be correctly used.

Protected constructors

CompilationMode

protected CompilationMode()