[MUSIC PLAYING]
CARMEN JACKSON: Hey, everyone.
I'm Carmen from the Android Performance team.
And I'm here to talk to you about analyzing performance
using Systrace.
Of course, you know what your app is doing, right?
You wrote the code, you did the code reviews,
you wrote the tests, right?
You've been dog-fooding it for weeks.
Well, I hate to break it to you, but you probably don't actually
know what's going on under the hood
unless you use Systrace to visualize it.
Your code is just one piece of the puzzle.
The code that's actually running is
subject to A/B tests, libraries that you may or may not
have written, the Android framework, the kernel,
and even actual device hardware and drivers.
And all of these things can affect your app's performance
at the end of the day.
You've probably seen a talk like this before.
And you're thinking, OK, I'll just run these command lines.
I'll clone Systrace.
I'll run the catapult command with this random string,
a trace will come out.
And that'll still work.
But we've actually made it a lot easier.
Since Android P, there has been on-device system tracing
available in Developer Options .
So all you have to do is open this app and tap Record Trace,
and then repeat the behavior you're interested in recording.
You can customize which categories you
want to see inside this app.
And in Android 10, you can actually
switch from Ring Buffer mode to Long Trace mode,
where the trace is backed up to disk instead of continually
overwriting itself.
So you can take traces as long as you want.
You can add a tile to your Quick Settings panel
to make it easy to start and stop traces whenever you want.
And then once it's done, you can share it to email or drive,
or access it from the Files app.
And you can also always grab it, if you
want to plug in your phone, from Data Local Traces using ADD.
Now, if you read some traces before,
you've probably seen a UI that looks like this.
We've improved that, too.
We're starting to use a tool called Perfetto for both system
trace collection and analysis.
Perfetto gives us the option to collect a wider variety of data
than we were collecting before with Atrace.
And the new Perfetto Trace Viewer supports larger traces
without crashing Chrome.
We're also taking this opportunity to improve the UX.
And it's under active development,
so we're seeing real improvements almost daily.
You can load Perfetto trace files or Systrace files
into the Trace Viewer at ui.perfetto.dev
to try it out yourself.
So let's take a quick look at a few app startup sequences.
And I'll show you some easy wins or potential opportunities
for improvement that we can see at a high level.
In this trace, there are two red activity start sections
in the middle of the app startup.
Trampoline activities like this are always
a potential opportunity for improvement.
You want to ask, is the time it takes
to load an extra activity worth having a super fancy splash
screen or an activity-based redirection flow?
So I'd ask this developer, can you potentially
refactor your logging code or your permission check
so that the most common case is the fast one
and you only have to load in one activity?
In this trace, the app maybe did that refactor already and only
has one activity starting.
But inside their activity start, there
is a big inflate section for a view called Login View.
And I have to guess a little bit here,
but there is no actual visible login
page when I open this app.
So it's possible that this developer is creating
and inflating an entire Login View,
and then hiding it when it's not being used, which is
going to be most of the time.
They probably aren't aware that it's having
such an impact on app startup.
This 76 milliseconds is actually quite significant.
So to solve this, they could potentially
defer inflating those views until after checking to see
if the user has logged in.
In this app, we see a large background image
loading in as part of the startup inside the activity
resume.
And this image load takes 14 milliseconds, which is about 5%
of the overall app startup time.
>From this perspective, I can't tell whether that's definitely
good or bad.
It might be worth it for the image quality
that you're looking for.
But the developer might be able to optimize this image.
Like potentially, they could use WebP instead of PNG.
Or they could do an asynchronous loading effect,
like a fade-in, that doesn't actually
block that first frame of the app
from being drawn to the screen, but still
gets you the same effect.
These were all just some simple, quick examples of opportunities
that I was able to see using only the system trace points
and using just apps that I already had on my phone.
When you add your own trace points to your app code,
and when you're reading traces that correspond to the code
that you actually wrote and that you're familiar with,
you'll be able to understand what's
going on much more deeply.
And it will be even more useful to you.
So have fun, enjoy, and thank you.
I'll be at the Performance Sandbox
until the end of the day if you have any more questions.
[APPLAUSE]
[MUSIC PLAYING]