Posted by Ben Weiss – Senior Developer Relations Engineer,
Breana Tate – Developer Relations Engineer,
Jossi Wolf – Software Engineer on Compose

Compose
yourselves and let us guide you through more background on performance.

Welcome
to day 3 of Performance Spotlight Week. Today we’re continuing to share details and guidance on
important
areas of app performance. We’re covering Profile Guided Optimization, Jetpack Compose
performance
improvements and considerations on working behind the scenes. Let’s dive right in.

Profile
Guided Optimization

Baseline
Profiles
and Startup
Profiles
are foundational to improve an Android app’s startup and runtime performance. They are part of a
group of
performance optimizations called Profile Guided Optimization.

When
an app is packaged, the d8 dexer takes classes and methods and populates your app’s classes.dex
files. When a user opens the app, these dex files are loaded, one after the other until the app
can start.
By providing a Startup
Profile
you let d8 know which classes and methods to pack in the first classes.dex
files. This structure allows the app to load fewer files, which in turn improves startup
speed.

Baseline
Profiles effectively move the Just in Time (JIT) compilation steps away from user devices and
onto developer
machines. The generated Ahead Of Time (AOT) compiled code has proven to reduce startup time and
rendering
issues alike.

Trello
and Baseline Profiles

We
asked engineers on the Trello app how Baseline Profiles affected their app’s performance. After
applying
Baseline Profiles to their main user journey, Trello saw a significant 25 % reduction in app
startup
time.

Trello
was able to improve their app’s startup time by 25 % by using baseline
profiles.

Baseline
Profiles at Meta

Also,
engineers at Meta recently published an article on how they are accelerating
their Android apps with Baseline Profiles.

Across
Meta’s apps the teams have seen various critical metrics improve by up to 40 % after
applying Baseline
Profiles.

Technical
improvements like these help you improve user satisfaction and business success as well. Sharing
this with
your product owners, CTOs and decision makers can also help speed up your app’s
performance.

Get
started with Baseline Profiles

To
generate either a Baseline or Startup Profile, you write a macrobenchmark
test that exercises the app. During the test profile data is collected which will be used during
app
compilation. The tests are written using the new UiAutomator
API,
which we’ll cover tomorrow.

Writing
a benchmark like this is straightforward and you can see the full sample on GitHub.

Considerations

Start
by writing a macrobenchmark tests Baseline Profile and a Startup Profile for the path most
traveled by your
users. This means the main entry point that your users take into your app which usually is
after
they logged in.
Then continue to write more test cases to capture a more complete picture only for Baseline
Profiles. You do
not need to cover everything with a Baseline Profile. Stick to the most used paths and measure
performance
in the field. More on that in tomorrow’s post.

Get
started with Profile Guided Optimization

To
learn how Baseline Profiles work under the hood, watch this video from the Android Developers
Summit:

And
check out the Android Build Time episode on Profile Guided Optimization for another in-depth
look: 

We
also have extensive guidance on Baseline
Profiles
and Startup
Profiles
available for further reading.

Jetpack
Compose performance improvements

The
UI framework for Android has seen the performance investment of the engineering team pay off.
From version
1.9 of Jetpack Compose, scroll jank has dropped to 0.2 % during an internal long scrolling
benchmark
test. 

These
improvements were made possible because of several features packed into the most recent
releases.

Customizable
cache window

By
default, lazy layouts only compose one item ahead of time in the direction of scrolling, and
after something
scrolls off screen it is discarded. You can now customize the amount of items to retain through
a fraction
of the viewport or dp size. This helps your app perform more work upfront, and after enabling
pausable
composition in between frames, using the available time more efficiently.

To
start using customizable cache windows, instantiate a LazyLayoutCacheWindow
and pass it to your lazy list or lazy grid. Measure your app’s performance using different cache
window
sizes, for example 50% of the viewport. The optimal value will depend on your content’s
structure and item
size.

Pausable
composition

This
feature allows compositions to be paused, and their work split up over several frames. The APIs
landed in
1.9 and it is now used by default in 1.10 in lazy layout prefetch. You should see the most
benefit with
complex items with longer composition times. 

More
Compose performance optimizations

In
the versions 1.9 and 1.10 of Compose the team also made several optimizations that are a bit
less
obvious.

Several
APIs that use coroutines under the hood have been improved. For example, when using Draggable
and Clickable,
developers should see faster reaction times and improved allocation counts.

Optimizations
in layout rectangle tracking have improved performance of Modifiers like onVisibilityChanged()
and onLayoutRectChanged().
This speeds up the layout phase, even when not explicitly using these APIs.

Another
performance improvement is using cached values when observing positions via onPlaced().

Prefetch
text in the background

Starting
with version 1.9, Compose adds the ability to prefetch text on a background thread. This enables
you to
pre-warm caches to enable faster text layout and is relevant for app rendering performance.
During layout,
text has to be passed into the Android framework where a word cache is populated. By default
this runs on
the Ui thread. Offloading prefetching and populating the word cache onto a background thread can
speed up
layout, especially for longer texts. To prefetch on a background thread you can pass a custom
executor to
any composable that’s using BasicText
under the hood by passing a LocalBackgroundTextMeasurementExecutor
to a CompositionLocalProvider
like so.

Depending
on the text, this can provide a performance boost to your text rendering. To make sure that it
improves your
app’s rendering performance, benchmark and compare the results.

Background
work performance considerations

Background
Work is an essential part of many apps. You may be using libraries like WorkManager or
JobScheduler to
perform tasks like:

• Periodically
  uploading analytical events

• Syncing
  data between a backend service and a database

• Processing
  media (i.e. resizing or compressing images)

A
key challenge while executing these tasks is balancing performance and power efficiency.
WorkManager allows
you to achieve this balance. It’s designed to be power-efficient, and allow work to be deferred
to an
optimal execution window influenced by a number of factors, including constraints you specify or
constraints
imposed by the system. 

WorkManager
is not a one-size-fits-all solution, though. Android also has a number of power-optimized APIs
that are
designed specifically with certain common Core User Journeys (CUJs) in
mind.  

Reference
the Background
Work landing page
for a list of just a few of these,  including updating a widget and getting location in the
background.

Local
Debugging tools for Background Work: Common Scenarios

To
debug Background Work and understand why a task may have been delayed or failed, you need
visibility into
how the system has scheduled your tasks. 

To
help with this, WorkManager has several related
tools to help you debug locally
and optimize performance (some of these work for JobScheduler as well)! Here are some common
scenarios you
might encounter when using WorkManager, and an explanation of tools you can use to debug
them.

Debugging
why scheduled work is not executing

Scheduled
work being delayed or not executing at all can be due to a number of factors, including
specified
constraints not being met or constraints having been imposed
by the system. 

The
first step in investigating why scheduled work is not running is to confirm
the work was successfully scheduled. 
After confirming the scheduling status, determine whether there are any unmet constraints or
preconditions
preventing the work from executing.

There
are several tools for debugging this scenario.

Background
Task Inspector

The
Background Task Inspector is a powerful tool integrated directly into Android Studio. It
provides a visual
representation of all WorkManager tasks and their associated states (Running, Enqueued, Failed,
Succeeded). 

To
debug why scheduled work is not executing with the Background Task Inspector, consult the listed
Work
status(es). An ‘Enqueued’ status indicates your Work was scheduled, but is still waiting to
run.

Benefits:
Aside from providing an easy way to view all tasks, this tool is especially useful if you have
chained work.
The Background Task inspector offers a graph view that can visualize if a previous task failing
may have
impacted the execution of the following task.

Background
Task Inspector list view

Background
Task Inspector graph view

adb
shell dumpsys jobscheduler

This
command
returns a list of all active JobScheduler jobs (which includes WorkManager Workers) along with
specified
constraints, and system-imposed constraints. It also returns job
history. 

Use
this if you want a different way to view your scheduled work and associated constraints. For
WorkManager
versions earlier than WorkManager 2.10.0, adb
shell dumpsys jobscheduler
will return a list of Workers with this name:

If
your app has multiple workers, updating to WorkManager 2.10.0 will allow you to see Worker names
and easily
distinguish between workers:

Benefits:
This
command is useful for understanding if there were any system-imposed
constraints, which
you cannot determine with the Background Task Inspector. For example, this will return your
app’s
standby bucket,
which can affect the window in which scheduled work completes.

Enable
Debug logging

You
can enable custom
logging
to see verbose WorkManager logs, which will have WM—
attached. 

Benefits:
This allows you to gain visibility into when work is scheduled, constraints are fulfilled, and
lifecycle
events, and you can consult these logs while developing your app.

WorkInfo.StopReason

If
you notice unpredictable performance with a specific worker, you can programmatically observe
the reason
your worker was stopped on the previous run attempt with WorkInfo.getStopReason. 

It’s
a good practice to configure your app to observe WorkInfo using getWorkInfoByIdFlow to identify
if your work
is being affected by background restrictions, constraints, frequent timeouts, or even stopped by
the
user.

Benefits:
You can use WorkInfo.StopReason to collect field data about your workers’
performance.

Debugging
WorkManager-attributed high wake lock duration flagged by Android vitals

Android
vitals features an excessive partial wake locks metric, which highlights wake locks contributing
to battery
drain. You may be surprised to know that WorkManager
acquires wake locks to execute tasks,
and if the wake locks exceed the threshold set by Google Play, can have impacts to your app’s
visibility.
How can you debug why there is so much wake lock duration attributed to your work? You can use
the following
tools.

Android
vitals dashboard

First
confirm in the Android
vitals excessive wake lock dashboard
that the high wake lock duration is
from WorkManager and not an alarm or other wake lock. You can use the Identify
wake locks created by other APIs
documentation to understand which wake locks are held due to WorkManager. 

Perfetto

Perfetto
is a tool for analyzing system traces. When using it for debugging WorkManager specifically, you
can view
the “Device State” section to see when your work started, how long it ran, and how it
contributes to power
consumption. 

Under
“Device State: Jobs” track,  you can see any workers that have been executed and their
associated wake
locks.

 

Device
State section in Perfetto, showing CleanupWorker and BlurWorker execution.

Resources

Consult
the Debug
WorkManager page
for an overview of the available debugging methods for other scenarios you might
encounter.

And
to try some of these methods hands on and learn more about debugging WorkManager, check out
the
Advanced WorkManager and Testing
codelab.

Next
steps

Today
we moved beyond code shrinking and explored how the Android Runtime and Jetpack Compose actually
render your
app. Whether it’s pre-compiling critical paths with Baseline Profiles or smoothing out scroll
states with
the new Compose 1.9 and 1.10 features, these tools focus on the feel
of your app. And we dove deep into best practices on debugging background work.

Ask
Android

On
Friday we’re hosting a live AMA on performance. Ask your questions now using #AskAndroid and get
them
answered by the experts. 

The
challenge

We
challenged you on Monday to enable R8. Today, we are asking you to generate
one Baseline Profile
for your app.

With
Android
Studio Otter,
the Baseline Profile Generator module wizard makes this easier than ever. Pick your most
critical user
journey—even if it’s just your app startup and login—and generate a profile.

Once
you have it, run a Macrobenchmark to compare CompilationMode.None
vs. CompilationMode.Partial.

Share
your startup time improvements on social media using #optimizationEnabled.

Tune
in tomorrow

You
have shrunk your app with R8 and optimized your runtime with Profile Guided Optimization. But
how do you
prove
these wins to your stakeholders? And how do you catch regressions before they hit
production?

Join
us tomorrow for Day
4: The Performance Leveling Guide,
where we will map out exactly how to measure your success, from field data in Play Vitals to
deep local
tracing with Perfetto.