[MUSIC PLAYING]
BEN WEISS: Welcome to this MAD Skills episode
on performance monitoring.
In the previous episodes, we talked about metrics
around app startup and jank avoidance
and how to inspect and improve your app's performance.
If you haven't watched them just yet, go ahead,
pause this video, and catch up.
I'll wait for you to get back here.
[MUSIC PLAYING]
Oh, you're back?
Great.
Now, let's talk about making sure all the hard work
to inspect and improve performance actually
pays off by monitoring the results.
Here, we also offer several tools, products,
and best practices to help your app perform at its best.
Monitoring performance can happen in one of two states--
firstly, in a lab environment.
Performance data gathered here is invaluable
because you can learn how your app performs
before it hits your users.
This helps you limit possible performance problems because
of the data that can be used as a key signal
to support a block shipping of a release.
You can also have fast turnaround time, thanks
to continuous integration.
Using your continuous integration pipeline,
kick off your benchmark suite every time a commit lands
onto a release branch or before it gets
merged onto your main branch.
This way, you can compare between releases
and raise a red flag in case the metrics are above a threshold
that you decided on.
Make sure to run your benchmarks on real devices.
Instead of maintaining your own local device pool for testing,
you can use a provider that offers
testing on physical devices, such as Firebase Test Lab.
Firebase Test Lab keeps devices connected and up to date
so you don't have to invest in your local test device setup.
You can use the scripting interface
to run benchmarks on every build and continuously see results.
Whether you choose to run benchmarks on local devices
or with a cloud provider, spotting regressions
can be tricky at times.
To automate reporting, you have to set thresholds
for each metric that you deem important
and then compare it to a previously run benchmark.
You will see performance fluctuate.
Some builds might complete faster, and some slower.
Spotting whether an increase in runtime for a benchmark
is a regression in your code requires
you to compare more than two builds.
Within our public AndroidX continuous integration
pipeline, we have faced this problem in the past
and came up with a viable solution.
Instead of comparing a single build to the previous one,
we accumulate a set number of builds
and compare builds before and after a change has
landed in the codebase.
While this might take a handful of builds to spot a regression,
the approach is very reliable and scales well,
even with hundreds of libraries and engineers involved.
In his article on fighting regressions with benchmarks,
Chris Craig describes exactly how that algorithm works
in our codebase and how you can integrate it
into your continuous integration pipeline.
The short version is--
write some Macrobenchmark tests.
Then run them on real devices, collect the output metrics,
and store them for processing.
Run the step-fitting algorithm over the amount
of builds that works for you.
When a regression occurs, notify your release guardian
and the person that introduced the regressive change.
You can read all the details about step fitting here.
Now you know how a local TI pipeline
can be used to run basic and advanced
benchmark and regression tests.
You can also monitor the app's performance
once you have started using it with field
monitoring in production.
The easiest way to monitor production metrics
is by looking at the data Android Vitals provides.
Android Vitals offers anonymized and aggregated data
over your installed user base.
To use Android Vitals, you don't need
to make any change to your app's code whatsoever.
Simply upload it to the Google Play Store,
and we'll take care of the rest.
Android Vitals provides you with metrics
on app startup time, slow and frozen frames,
unresponsive activities, crashes, and more.
You can compare how your app is doing in different categories,
such as Android operating system version, available RAM, CPU
speed, and others.
It's valuable to periodically check in
on the data provided by Android Vitals
to see what could be improved.
And if you want more details, Firebase Performance Monitoring
has you covered.
By adding the Gradle plugin to your app,
you can see important information about cold start
times, the rough source of slow and janky frames,
as well as network request durations.
All of this data is reported directly
into the Firebase Console.
And you can get even more specific data
using Firebase Performance Monitoring.
Begin by adding the library dependency.
Then you can add your own trace points
for any code within your app.
Here we trace when data is loaded.
By using the Kotlin extension trace function,
the call side for loading the data can be wrapped.
This is a quick way to span multiple methods calls.
Alternatively, you can use the AddTrace annotation
on a method.
This provides you with a way to trace a single method
every time it is called and then report it
to the Firebase Console.
We are also continuously expanding
our suite of Jetpack libraries related to performance.
We have released the Jank Stats library
that enables gathering janky frames alongside metadata
such as how the user got to the state
where a frame had to be dropped.
After you add the dependency to your app's
build file, install Jank Stats into an activity window
by calling createAndTrack.
When a frame is considered to be janky by the library's
heuristic, you can log it and add it to your reporting queue.
Jank Stats holds onto the state for you
in a PerformanceMetricsState object.
And you can add and remove state and key-value pairs.
This enables you to add metadata, such as navigation
destinations, which make it easier
for you to reproduce how the user reached the janky frame
in the first place.
To see more usage of Jank Stats in action,
check out the Now in Android sample, where
we have added jank tracking code to key areas such as scrolling
through the authors list or "for you" page.
The reported data will be shown to you
as a per-frame data which you can feed into your reporting.
This concludes our second MAD Skill series on performance.
You have learned how to inspect, improve, and monitor
app and library performance around app startup
and smooth runtime experiences.
If you haven't already, go and create a Baseline profile.
It really helps to make your app run faster and smoother.
We are aware that there's much more to cover
when talking about performance.
And while we didn't have time to cover everything
in this series, we continue to add
more content to our developer guidance and samples.
Check out the links in the description
for more information.
Let us know what you think about this episode below.
Hit the thumbs up if you liked it.
Subscribe to the Android Developers
channel for more guidance and best practices
all around Android.
[MUSIC PLAYING]