[MUSIC PLAYING] BEN TRENGROVE: Hi, I'm Ben from
the Android Developer Relations team. I will also be joined by
Chuck from the Compose team. And together, we're here
to talk to you today about common performance
gotchas in Jetpack Compose. Ah, Chuck, Chuck, you
can stop waving now. Our goal with Compose is
to provide a performance UI system right out of the box. We can write code how it
comes naturally to you. And it will perform well,
as you would expect. There are a few steps
you can take, though, and some common gotchas
to avoid to ensure you maximize performance
in your Compose app. We'll start by taking a look
at how you can correctly configure your app with
regards to performance. Then we will dive straight
into those common gotchas and describe the best
practices for avoiding them. Let's get started. Configuration-- first,
let's take a look at how to configure your app
for testing and evaluating performance. When evaluating how your
Compose app is performing, it is very important to ensure
you are running in release mode with R8 optimization enabled. Why? An application is
slower when deployed as debug because the
Android runtime turns off optimizations to improve
the debugging experience. For example, not
having minification enabled is what allows you
to step through your code. Many of the optimizations
disabled when running in debug are critical for a
jank-free application. If you are noticing
performance issues in your app, you should first check if the
problem exists in Release Mode. It may be that you don't
have a problem at all. Gotchas-- now we've seen
how to configure the app. Let's take a look at some common
gotchas and how to fix them. Number 1, something
to remember-- for these first few
examples, we will be working on a simple
contacts app that shows a large list of names. Pause the video and see
if you can guess what the problem with this line is. Don't worry. I'll wait. If you guessed
that the list would be resorted with
every recomposition, then you are correct. Even though it might be easy
to just sort in line like this, you have to remember
that composables can be run very
frequently and must be written with that in mind. In this example, we
would have resorted the contacts list any time a
new row appeared on the screen. That's because, when
a [INAUDIBLE] appears, the LazyList composition
scope is invalidated. And Compose recomposes it. This means all our
code is re-executed. Because our sort is
inside this scope, the sort is called on
every recomposition. We can use the remember function
to catch expensive operations or allocations and ensure
they are only run when needed. Let's return to
our contacts list. We can move the sort
into a remember function. We key the remember function
with the contacts list and the sort comparator. This will ensure the
list gets resorted whenever one of these keys
changes, but won't get resorted on every recomposition. An even more optimal
improvement would be to move this sorting into
our view model or data source and out of Compose completely. By only changing Compose
state when needed, we will have the lowest
overhead possible. Number 2, a key piece-- now that we've taken care
of sorting the contacts, let's return to
the list composable and see if we can make
any further improvements. We can provide LazyColumn
with additional information here to help it know
which items have changed. Do you know what it is? A key. You can define a key for
your items in a LazyList. Without providing a key,
Compose will use the position of that item as the key. This can be very
bad for performance when an item moves in the
list, as every item after it will also be recomposed. Providing a key is easy. Adding the key lambda
to the items function allows us to provide the key. The only consideration is
that each key must be unique. Now when items move
in the list, Compose will know which
item moved and only have to recompose that item. A key is used for more than
just optimization in a LazyList. It also unlocks a
lot of features. For more information on this,
check out the Lazy Layouts in Compose talk. Number 3, deriving change-- next up, our designers have
asked us to add a button to scroll back to the top. The trick is they only want
it to show once the list has been scrolled down. Declarative programming in
Compose makes this easy. We can add a Boolean
variable called showButton that becomes true when
the first visible item index is greater than 0. We will use this
variable as a parameter for animated visibility, to
ensure a nice fade effect when the button
appears and disappears. There is a catch though. Because LazyList updates
the listState variable on every frame of
every scroll and we are reading the listState, we
are introducing a large amount of recomposition we don't need. For the showButton
variable, we only care about when the first
visible index changes from or to 0. There's another
Compose function, like remember, that
can help us here. Do you know what it is? derivedStateOf. Compose provides the
derivedStateOf function for situations just like this. derivedStateOf will take our
frequently changing list state and buffer those changes
to only the ones we need. In our case, that's when
the first visible index is greater than 0. We wrap our condition in
a remember derivedStateOf function. Now, we will only recompose
when this condition actually changes-- so once when the list
is scrolled down, and then again if the
list is scrolled back up. derivedStateOf really shines
in cases such as this one, converting a busy stream
into a Boolean condition. Any time you're converting
state into a Boolean, consider if
derivedStateOf could help. It's important to keep in mind
what derivedStateOf is not good for. You do not need to
use derivedStateOf every time you create a
variable out of some state. In this example, we
want to know the number of items in our contacts list. You might think that, because
we are deriving state, that you should
use derivedStateOf. But this is not true. Because this would not actually
buffer out any changes-- that is, our item count variable
needs to update just as much as the state of
the count changes-- derivedStateOf would actually
introduce a slight overhead here and is redundant. CHUCK JAZDZEWSKI: Number
4, procrastination-- the next example we'll
look at is not so much a gotcha than a potential
missed opportunity. Our designer has asked us
to animate the background of the user interface. Here, we want to
continuously animate the background color of box
between cyan and magenta. Not something I recommend,
but let's go with it. It's very easy to create
these animations in Compose. This does exactly what
the designers asked us for and seems to perform well. But there is a
potential optimization that can be done here that
might be difficult to spot. Here, we're asking Compose to do
much more work than necessary. The animation is
requiring this code to be recomposed in every frame. Well, to understand why
composition might not be necessary here,
we should first understand how Compose works. Compose has three
primary phases-- composition, layout, and draw. In the first phase, composition,
the composable functions are executed. This phase creates or updates
the content of your application and defines what the
next two phases will do. In the second phase, layout, the
content defined by composition is measured and placed where
it'll appear on the screen. This phase takes into account
all the modifiers and calls to other composable functions,
such as text, row, and column, and in a single pass, measures
and places all the content. This phase is discussed in much
more detail in the 2021 Android Studio Dev Summit Talk titled "A
Deep Dive into Jetpack Compose Layouts." You might want to check it out. In the final phase, draw, the
actual graphic instructions are issued to draw the
content to the canvas of the application. These instructions
are primitives, such as drawing lines, arcs,
rectangles, images, and text. And they are drawn in
the locations determined by the previous phase, layout. These three phases are
repeated in every frame that the data they read changes. If, however, the data does
not change, then one or more of the phases can be skipped. Since in our
application, the color is changing on every frame
because it's being animated, composition will also
occur for every frame. Since we're only drawing
a different color, it would be nice
if we could just redraw the box in the new
color, skipping the composition and layout phases altogether. Deferring the reading of
state until it is required is an important
concept in Compose. Deferring a read can
reduce the number of functions that need
to be re-executed, as it is in this case, and can
allow us to skip composition and even layout entirely. In this version, we
use drawBehind instead of background. drawBehind
takes a function instance that is called during
the draw phase of Compose. Since that's the only time
the color value is read, only the results
of the draw phase need to change when
the color changes. Draw then becomes the only phase
that needs to be re-executed, allowing Compose to skip
both composition and layout. The magic here is the read of
the color state in the function instance, not the
composition function. Since the function
instance doesn't change, the variable it
reads is the same. Nothing has changed from
composition's perspective, so it doesn't need to
re-execute this function. Reading the state in
function instances like this and passing it as
parameters is a useful tool that can be used to not only
allow phases to be skipped, as in this case,
but it could also be used to reduce the
amount of code that needs to be re-executed
when the state changes. One way to take
advantage of this is by nesting, as
nesting implicitly creates function instances. Here, for example, when
the contact's name changes, only the call to Text
will be re-executed. The calls to
ContactCard and MyCard are skipped, as they do not
read the contact's name. Just the call to
Text does, which is captured in a
function instance. Because recomposition
can restart at the beginning of any
compositional function instance, a function
instance can be used to reduce the
amount of code that needs to be re-executed when
the data it reads changes. Number 5, running backwards-- unlike the last
example, where it worked but could be
optimized, this next gotcha is code that should
always be avoided. Here, the designer has
asked us to display a list of banking transactions
and the corresponding balances, such as you would find
on a banking statement. To do this, we maintain a
running total of the balance, and updating it for
each transaction, and then displaying
the transaction and the new balance. However, this has a problem. Before we dig deeper,
can you spot it? We began to realize
that there was a problem when we took a system
trace of our application. After building a released
version of our app, ensuring it's configured,
as Ben recommended, we use Android Studio's
built-in profiler to take a system
trace in the CPU view. This trace is the trace
we're looking at now. We immediately noticed that the
main thread of our application is much busier than we expected. In fact, we expected
it to go idle, as the screen isn't
changing at all. As Android Studio enables
the application trace markers automatically for us, we can
see that the recompose marker is present in every frame. We can tell it's every frame,
as Android Studio highlights each frame in
contrasting color bars. Composition is occurring
all the time now and never seems to stop. Let's go back and try
and figure out why. The problem turns out to be
the line to update the balance. This code violates a core
assumption of Compose. Compose assumes that once
a value has been read, it will not change until
after composition completes. You should never write to
a value that has already been read in composition. Writing to data that
has already been read is what we call a
backwards write. And it violates a core
assumption of Compose and might cause recomposition
to occur on every frame, like it does here. To better understand when
backwards writes occur, let's go back to the code. The backwards right is on
the line updating balance. But the read appears to occur
after the write in the call to Text. Well, how is this
a backwards write? Well, the backwards write
is more obvious if we were to unroll the loop like this. The writes to balance
before it reads are fine. It is the write to
balance in the loop itself that causes
composition to always think it's out of date and
needs to be re-executed. It is updating the
value beginning with the second item
in the list that's the root cause of the problem. When composition thinks
it's out of date, it will schedule a new
composition for the next frame. If that composition
marks itself out of date, composition will schedule itself
for the next frame, endlessly. This is a better version
of the code which uses our friend remember
again, and also avoids writing to state entirely. This version only executes
the composable function once when it is first displayed. And it's only considered out of
date when transactions change. An even better
version of this would be one that calculates
balances in the view model, just like the sort
example before, allowing these calculations
to be performed even before composition starts. But that example wouldn't
fit on this slide. Now, after making these changes,
we take a system trace again. And we see what we
originally expected. The main thread is initially
busy, and then goes idle. Looking more closely
at the trace markers, we can see that the
composition is run once when transactions list
is shown, and is not scheduled to run again. So remember, to avoid
backwards writes, never write to state that
has already been read. BEN TRENGROVE: Number
6, covering your bases-- when running our app
from Android Studio, we noticed that it seems to
be janky for the first couple of seconds. But after that,
it appears smooth. We first checked
that it was correctly configured with release
mode and R8 optimization. But we are still
seeing it happen. Do you have any idea what
could be going on here? We are seeing the effects
of just-in-time compiling. When running from
Android Studio, there is often a
performance drop at startup as your code is interpreted. Most likely, your
users will never see this effect, thanks to our
next item, baseline profiles. Adding a baseline
profile to your app can help to speed up startup,
reduce jank, and improve performance. But what exactly is
a baseline profile? As Compose is an
unbundled library, this has allowed us to
support older Android versions and devices,
as well as easily update Compose with new
features and bug fixes. We don't have to wait
for an Android upgrade to bring those changes to you. However, this comes
with a small drawback. Android shares system resources,
including toolkit classes and drawables, between apps. This speeds up the startup time
and decreases memory usage. As an unbundled library,
Compose does not take part in this sharing and
is treated as just another part of your app. When a user installs an
app from the Play Store, the APK downloaded to the
device includes all your code, plus any libraries
bundled with your app. On startup, this code has to
be interpreted by the Android runtime and compiled
to machine code. This process takes time, so
it can slow down performance. The Play Store has
an existing feature to improve this situation-- cloud profiles. Over time, the Play
Store will aggregate data about classes and methods
used at startup by your app. The data is simply a list
of the code used by your app during startup. We call this list
a cloud profile. The Play Store will
then ship this profile with subsequent downloads
of your app by other users. At install time,
the Android runtime will use this data to precompile
the listed classes and methods. This means there will be
less to interpret on startup. If you frequently update your
app roughly more than every two weeks, your users may never
see this benefit in action. Every update to your app also
clears the existing cloud profile data. A baseline profile is a way to
provide this list to the Play Store yourself-- that is, to provide a baseline. When a user downloads
your app, the Play Store will include your
baseline profile to ensure at install time
there is always profile data available. So the runtime knows
what to precompile. It will also continue to
aggregate the Cloud Profile data over time to
improve it further. Compose also ships with its
own Baseline Profile, which will be included in
your APK by default. You may not have to do
any additional work at all to see the benefits
of Baseline Profiles. Just know that it is there. But when running
from Android Studio, baseline profiles
are not included. And so you won't see this
benefit in your local testing. If you notice that your app
is slow on first startup and then gets faster,
this will probably be fixed by the default
baseline profile. You can configure
your app to start up with the baseline profile
enabled using our testing library Macrobenchmark. This can be useful to test
the first-run experience users will get when installing
from the Play Store. Because we are already
including an optimized profile for the Compose libraries,
adding your own baseline profile is not a guaranteed
performance gain, as profiles need to be
tweaked and optimized. If you do add a
baseline profile, be sure to test it is actually
improving your metrics. Both the generation of a profile
and the testing of the benefits are done using the
Macrobenchmark library. When a profile is
properly optimized, it can have a massive effect
on your app's performance. By adding a baseline profile
to one of our Compose samples, jetsnack, we improve our
startup performance by 22%. Google Maps added a
profile to their app and improved their average
startup time by 30%. It's not just
startup performance that has improved though. Play Store added a
profile to their app and were able to improve
the initial rendering time of the search page by 40%. As you can see, adding
a baseline profile can be one of the
best things you can do for your app's performance. For details on how to
generate your own profile or how to configure
Macrobenchmark for the generation and
testing of profiles, check out our
documentation and codelab. And that's it. To sum up today,
we looked at how to configure an app for
the best performance. Remember, the first
thing to check if you see a performance issue
is if it persists in release mode and you have R8 enabled. We then saw some common
mistakes and how to fix them. Here are the key
takeaways to remember-- remember, LazyList keys,
derivedStateOf, defer reads, backwards writes, and
baseline profiles. For more details on anything
we talked about today, check out our new Compose
performance documentation, as well as the baseline profiles
documentation and codelab. And that's it. Thanks, everyone. [MUSIC PLAYING]
