[MUSIC PLAYING] DAN CHUPARKOFF: Hello, and
welcome to Google I/O. I'm Dan. And, today, we're going to
talk about improving app health and stability by combining the
power of Firebase Performance Monitoring and Crashlytics. If you're an app
developer, whether you're building for Android,
or iOS, or both, you're probably
spending your days thinking about how to
make your app great. But what does great
mean, exactly? At Firebase, we think
about that a lot. Making an app is hard. Making an app great
is even harder. But Firebase is here to
help you along the way. There are three stages on
this app development journey. If you have an app, chances are
that every single one of you is in one of these three stages. The first stage on this
app development journey is the my-app-is-live stage. You've been there. You've been working hard
to build your new app and it's finally done. You've finished the
most critical features. You've tested it. You feel good about where
it is, and you've finally pushed it to production. It's on the app stores. Your users love it. User adoption is growing,
and life is good. If you're there,
congratulations. This is a huge milestone in
every app developer's life. And that's why we built
Firebase in the first place. But there's more work
ahead, a lot of it. The second milestone in
that app development journey is the fix-crashes-fast stage. Many of you have been here, too. Once your app is live, you soon
discover that your work is just getting started. It's not enough just to have
an app on the app stores. You've also got to keep it up
and running for your users. No matter how much
testing you do, every app crashes
once in a while. Your users are running your
app on a complex ecosystem of devices and form
factors and OS versions, and your team is
constantly releasing new features and fixing issues. All this creates change. And, sometimes, change
results in crashes. If you want to keep all
those users that you've worked so hard to
acquire, then you need to discover and fix
crashes as soon as they happen. That's where
Crashlytics comes in. You don't want to learn
about problems in your app from angry reviews on the app
store from frustrated users. The best way to ensure
your app's stability is to find out about crashes
as soon as they occur. In a few minutes, Mike will talk
about the great new features in Crashlytics and
how they will help you to discover and respond to
crashes as quickly as possible. Once your team
has built your app and you're responding
to crashes fast, then you might be ready to
move to the third stage. And this final stage on the road
to app development greatness is the
optimize-the-experience stage. If you're not here
yet, the Firebase team is here to help with
some great new features in Firebase
Performance Monitoring. Your users will use your
app on different devices, in different countries,
and on different networks. And this means that, even
when your app isn't crashing, your users still might be
experiencing speed and latency issues. Luckily, Performance
Monitoring helps you to collect and organize
your app's performance metrics so you can see
performance trends and identify opportunities to
improve your app's experience. After we hear from Mike, Jenny
from the Firebase Performance Monitoring team will talk about
going beyond managing crashes to optimizing the
experience of your app with an awesome new
feature that her team just brought to the platform. No matter where you are on
the app developer journey, we know that you want to make
your app great for users, and we want to help you do that. Today, as we continue
this discussion, we'll use a hypothetical
shopping app on the Android app store, and we're going to
dive into some of the newest advancements from Firebase
Performance Monitoring and Crashlytics so that
you can take your app development to the next
level for your users. Let's dive in. Here's Mike from
the Crashlytics team to get us started
with a closer look. MICHAEL DOYLE: Thanks, Dan. As Dan mentioned,
once your app is live, you need a way to identify
and respond to crashes as quickly as possible. You've entered the
fix-crashes-fast stage. If you're already
using Crashlytics, you're familiar with
how we group crash reports together
into distinct issues so that you can discover and
fix the most impactful bugs affecting your app's stability. To help you get even more out of
what Crashlytics has to offer, I'll walk you through
a few of the ways, new and old, that you can use
to prioritize and troubleshoot issues, no matter where you
are in your app development lifecycle. A typical process
that many developers follow before releasing a
new version of their app to customers is to
ship a test version out to a smaller group of people
first to get feedback. This could be internally
within your company or to a large group of people
who have signed up to receive beta versions of your app. If you're using Google Play
to distribute your app, you might be using Firebase
Release Tracks to do this. With different production,
testing, and beta versions live, you may be finding
it difficult to distinguish crashes from these
different release tracks in the Crashlytics dashboards. For example, you might
have a lot less activity in the beta version of your
app, making those crashes seem less important. Or maybe you just aren't
sure which version exactly is being served
to which groups of users. Well, Crashlytics is excited
to announce a new integration with the Play Developer
Console to make this process a lot easier for you. By linking your Crashlytics
and Play apps together, you'll be able to filter the
issues list by release track to help catch bugs before they
can make it to production. Let's see how it works. We'll start by opening
up the Project settings page on the Firebase Console,
then Integrations, followed by Connect to Google Play. You'll see a list
of Firebase features that can be enhanced
by linking to Play, which now includes Crashlytics. Any of these choices can be
toggled on or off individually. When you select
Crashlytics, you'll have the option to enable
one or more of your apps for the integration. Keep in mind that
you'll need to be an administrator on both
Firebase and Play to do this. But, once the link is
made, your entire team will be able to take
advantage of the feature. Click Link to Play, and
we get a confirmation that the link was made. Let's head back to the
issues list on Crashlytics. When we click on
the Versions filter, we now see an option
for each release track. If I select Closed
testing, only the versions participating in that
track are selected. Click Apply, and we'll see
only the issues impacting that track. That's much better. I can clearly see
there a few issues in particular that are
impacting our closed testing. I want to get these bugs patched
up before our release hits production. This is our first integration
between Crashlytics and Play and we're very excited
to launch it today. In the coming months,
we'll have more to share about how Crashlytics
and Play are collaborating to make both products
work better together. Check out the new
"Google Play Tools to Improve Your App
Quality" talk to learn more, and stay tuned for
future announcements. Now how should I
prioritize these issues? It's not always obvious which
crashes are the most important. Signals is a new feature
that Crashlytics recently released that will highlight
interesting attributes about a crash. It looks like I have a
few issues with signals that I should take
a closer look at. You can see we have
a fresh issue, which indicates that Crashlytics
saw this for the first time within the last seven days. In fact, by hovering
over the badge, we can see that this issue
occurred for the first time two days ago. You might also see other signal
types, like early crashes, which occur within
the first five seconds of opening the app;
repetitive crashes; or even regressed
issues, which are issues that were previously
marked as fixed but have reappeared
in a later version. All of these are indications
of a potentially poor user experience. Here's another type
of issue you might not have been thinking about-- ANRs, or Application
Not Responding errors. These are issues that occur
when the UI thread of your app is blocked for too long. This can be particularly
frustrating for users since they won't be able
to interact with your app during this time. In fact, according
to our data, ANRs account for nearly one third
of all unintended application exits on Android, making them
just as detrimental to your app quality as crashes. Previously, these
were only visible in the Play Developer Console. Now, you can see
them in Crashlytics, where your whole development
team can take advantage of the rich set of debugging
information provided by the Crashlytics SDK. Let's dive into this ANR
that a lot of my users are experiencing. We can see that Crashlytics
has already highlighted the blocking thread for us. And it looks like
the application is stuck while
waiting for an image to load on the product catalog. You can also see which
thread reported the ANR. If we go to the Logs tab
under the Event summary, we can see a detailed timeline
of steps the user took before encountering this error. We call these breadcrumbs. And, since we're using
Google Analytics, they're automatically
collected for us. You can even add your own
custom events if you need to. Since I'm using fragments,
I've instrumented my code to send an event any time a new
UI fragment comes into view. This way, I can track
all of the screens my users are viewing, even if
the current activity doesn't change. Here's a code snippet for
how you can do this, as well. I should also take a
look at the Keys tab. Custom keys are
key-value pairs that you can define to provide more
context about the app's state prior to a crash occurring. It looks like our user
is somewhere in the UK and they're on a slower
cellular network. Maybe that's a hint for
something I can look into. Here's another
code sample for how you might do this in your app. As we've seen, Crashlytics
not only now surfaces ANRs, but also gives you and your
team important contextual information to help reproduce
and fix these issues. You'll be back to five-star
reviews in no time. In order to take advantage
of ANR reporting, you'll want to make sure
you upgrade to the latest version of the Crashlytics SDK. One last thing I should mention. Wouldn't it be great if you
had access to crash reporting details right from your IDE
where you are already working? With the new App
Quality Insights window in Android Studio,
you can do just that. Available now in the
Android Studio Electric Eel canary channel. Finding, prioritizing, and
fixing issues in your app is a high priority
for most developers, and it isn't always easy. No matter which phase of
app development you are in, Crashlytics has the
features to help. Now that you're comfortable
with crash reporting and have your app
stability under control, you're entering the
optimize-the-experience stage. It's time to track and alert
on your app's performance. I'll pass things over to
Jenny to talk more about that. JENNY CONG: Thanks, Mike. After you fixed the critical
crashes in your app, the next step is optimizing your
app's performance as you scale. Performance is critical to
the success of your app. Users demand and
reward performance. Based on our recent analysis
of Google Play reviews, 54% of users who left a one-star
review in the Google Play Store mentioned app stability
and bugs as a reason for their low rating. Improving site speed by
just one tenth of a second increases progression
rates on almost every step of the mobile purchase journey. Notably, retail sites saw an
8% increase in conversion rates due to site speed improvements,
just one tenth of a second. This is where Firebase
Performance Monitoring can help. Performance Monitoring collects
performance data out-of-the-box for app start time, network
calls, and screen renderings. There are also a number
of customizations available so you can monitor
the user journeys most critical to your business. For example, you can
customize data collection by instrumenting custom traces
to measure specific user journeys in your app, like
the amount of time users spend in the checkout flow
or the number of items added to the shopping cart. Performance Monitoring
then organizes your app's performance metrics into
a comprehensive dashboard so you can easily understand
performance trends and anomalies. Now let's dive deeper to see
how Performance Monitoring can help take your app
to the next level. Let's first take a look
at the Firebase Console. At the top, you can
pick which percentile of data you want to view. What does percentile mean here? Let's say you have a
total of a hundred users who started your app, and you
order these a hundred app start times by duration from the
shortest to the longest. Then the 90th percentile
of your app start time is the 90th app start
time in this ordered list. 90% of your users have
an app start time faster than this number,
and 10% of your users have a slower app start time. Since the 90th
percentile tells you the app's experience
for 90% of your users, as well as the
most impacted 10%, Firebase recommends that you
monitor the 90th percentile of performance data
for your mobile apps, aligned with Google Play Vitals. Going back to the
dashboard, at the top, you can choose your
most important metrics so you can see how they're
performing at a glance, both across releases
and over time. At the bottom of the
dashboard, you'll find all of the network
requests, traces, and screen renderings captured
for your app. You can order the
metrics by their value to understand the current
performance of the metrics, or you can sort the metrics
by their value over time to see the metrics that degraded
the most week over week. Performance Monitoring
automatically aggregates data for
similar network requests to help you identify trends
in your network performance. But we know that sometimes you
need a more fine-grained view of your APIs. So you can also set
up custom URL patterns to monitor each
API more closely. Let's consider an example. Once your network data starts
to aggregate to the newly configured custom
URL patterns, you see that the
worst-performing API is the one that loads
images for a catalog page, with a 90th percentile
of 2.72 seconds. This means that 10% of
the calls of this API are slower than 2.72 seconds. This is definitely
not a good experience for your users when they try
to browse through the products. You take a look at
the trend over time and you notice there's a
big increase a few days ago. Hm. This is probably
because you just almost doubled the number of
products in your store from a new, exciting partnership
with a well-known brand. After showing the dashboard
trends to your product leads, your team decides to improve the
response time for your catalog page by implementing a cache
server so that your app performance can scale
as your business scales. A few weeks later,
your team finishes implementing the new cache
server for a backend. It's been tested locally
and you're finally about to roll out the changes. But the new cache
server is a risky change and you want to monitor
for any performance issues during the rollout,
like a misconfiguration or a sudden increase
in error rates. More importantly, you
want to discover issues as soon as they appear
to minimize the impact on your app and your users. Even though you know
your performance data is available to you in real
time in the Firebase Console, it's still a daunting task
to have to constantly monitor the dashboard. To make this task easier,
Performance Monitoring just added the ability
for you to set up threshold-based alerts so
that you will be the first one to know when your user
experience issues with releases or sudden performance
degradations, like those caused by network
outages or resource issues. Let's see this in action. Say you decide to set up alerts
for the image loading API, since that's the
API most important to the product-browsing
experience. The local tests you
conducted showed that the 90th
percentile response time for this API with
the new cache server is around 1.2 seconds. So you set up an alert for when
the 90th percentile response time exceeds 1.5 seconds,
accounting for some variance in the network latency. You also set up alerts
for when the success rate drops below 99%. When configuring
alerts, we recommend that you use the alert
thresholds with some buffer room for the metrics
you are monitoring. This way, you can account
for random factors, like lower latency, to have
less false positive alerts. With this monitoring set up,
you now confidently roll out the new cache changes. An hour later, you
receive a couple of alert emails in your inbox. Oh no. The success rate of the catalog
API has dropped from 99% to less than 80%, and the
90th percentile response time has increased to 3.4 seconds. There's definitely something
wrong with the new cache server. You click on the email
to view more details. After investigating,
you see that there is a decrease in success
rate specifically in Japan and the UK, and
there are a large number of new 499 errors for this API. This usually indicates that
the client connection is closed before the response
can be returned, typically because of
deadline exceeded errors. You decide to take a look
at the response time alert to see if there
are similar trends. The response time
for this API has improved as expected in
the US but is performing much worse for Japan and the
UK, just like the success rate. You know that the
majority of our users are from these countries,
and you quickly realize that your cache server
is only deployed in the US. For users in Europe and Asia,
cross-continental network calls were being made, which
caused network response time to be even worse than
when there was no cache. You quickly deploy two more
cache servers, one in Europe and one in Asia, and you see the
success rate returns to normal and the response time
improves across the board. You're glad that
you set up alerts before rolling out this change. Otherwise, you might
have missed these issues until your next visit to the
Firebase Console or, even worse, from low-rating
user reviews. Alerts are a powerful
tool for monitoring the performance of your app. You can set up alerts for
a wide range of metrics, but not every metric
needs an alert. We recommend that
you set up alerts for the most important user
journeys or the metrics that you're in the
process of optimizing. This way, when you receive
an alert in your inbox, you know it's something
you need to act on. Wherever you are in your
app development journey, performance issues should be
on your mind as a developer. Integrate your app with Firebase
Performance Monitoring today and get notified for
performance issues before they affect your users. DAN CHUPARKOFF: Thanks, Jenny. As a developer, you want to make
sure that your app is stable, it's performing as expected,
and all is going well. Whether you're building for
Android, or iOS, or both, the Firebase
Performance Monitoring and Crashlytics teams
are here to help you make your app great. We hope that you're
as excited about some of these new features as we are. When you're ready to take
the next step on the journey to app development
greatness, you can find out more about
each of these products on firebase.google.com and
in your Firebase Console. Thank you. [MUSIC PLAYING]
