[MUSIC PLAYING]
PHILIP TAYLOR: Welcome to Google Game Dev Summit 2022.
Happy to see you here.
This session is optimize your game with Android tools.
I hope you find the talk useful and gives you information
you could use every day.
Performance optimization is really a way of thinking,
and it's best done every day, not
at the end as an afterthought.
I am Phil Taylor.
I work in Android Games Developer Relations and help
developers with performance evaluations.
I'm here to talk about Android tools for optimizing your game.
understanding what tool, when, and how
to get an end-to-end view of your game
are the goals of this talk.
Today, for our journey together, I
am covering the Android developer relations evaluation
process and tools.
Five areas and tools in 25 minutes
will give you a taste of what you
can accomplish with Android tools
and set you up for exploring on your own.
Setting up for analysis is as important as the analysis,
so I spend a bit of time on setup.
With the setup in hand, I will describe each of the areas
I will focus on, guidance for each area,
and how to perform an initial probe
and then how to drill in for a deep dive.
Then we'll examine the results and discuss
where to go and close with next steps.
I'm assuming a PC and Windows, but the tools and process
are equally valid on a Mac.
You can get the tools that I'll be using through the Android
Game Development Kit, such as AGI,
and through the tools built into Android Studio or the Android
Game Development Extension.
For the purpose of this talk, I will use AGK Tunnel as the game
to use the tools on.
To build AGK Tunnel, you will need Python installed.
If you have path issues, using GitHub to clone the repository
may be a better path than using the ZIP download.
Then we'll make use of a play dev account
on the Play Console, as well.
This presentation, as per the previous slide,
relies on Android Studio and the AGK.
In particular, we'll be focusing on performance optimization
tools to improve your game both pre and post-launch,
such as with Android GPU Inspector.
What tools do you use when is one key question.
But before we get to that, let's talk about the workflow
and process a bit.
Performance optimization is a way
of life for a game programmer.
It's important to start with a performance budget
and continually measure your progress.
That way, you can catch performance regressions
early when you make them, not much later.
Having a performance baseline and a relatively lightweight
process to examine your performance regularly
can make performance optimization
less of a heroic effort at the end
and more of a regular activity.
With that in mind, here I advocate an initial probe
to compare against the general guidance
for an area and a deep dive if the area is not
meeting the general guidance.
For this talk, let's consider five areas
for overall game performance, loading times, package size,
memory use, CPU use, and GPU use.
These areas can help get an end-to-end view
for graphics performance across loading, memory, and CPU/GPU
workloads.
Next, we will examine each area using an initial probe
then deep dive process.
We begin with startup and start time versus load time.
For background, see developer.android.com
on app startup time.
Here, we're looking at time to initial display, TDID,
versus time to fully drawn, TTFD, basically visible
versus interactable.
For startup time, TDID, use Logcat and search for display.
Load time, TTFD, can be more complex.
You can instrument report fully drawn to measure,
or finally, Android Performance Tuner
can help you measure real world performance,
with results visible in the Play Console.
Using ADB, get the log and find the display line.
It's good enough as initial probe, time to initial display.
In this case, the start time's below one second.
But let's take a look at the APT details
in a test track for this app just
to perform the deep dive step to get used to the process.
In this case, even though the start time is below one second,
it's useful to use your Play dev account and check details.
If you've integrated Android Performance Tuner, then
APT loading and frame time show up in the Console.
For this example, an internal test track was created
and a few instances installed to get viewable results.
Now we can see the load times for each device
and if users are dropping off.
Note the interesting device with 1.94k milliseconds to start.
Play call is your friend to understand cases like that.
Understanding and using Vitals can make a difference
in your app performance.
Perhaps this device should be excluded, for instance.
Let's look at package size.
The quickest check is to see the size of your as built game
in File Explorer Finder, your release build.
Game sizes over 130 meg need to be
addressed before publication.
Either you can reduce the size of your assets
or split out your assets.
Play Asset Delivery is one great way to do just that.
If your install time is an issue,
use PAD to split out just those resources that
may be downloaded at the start.
Now, let's drill in using APK analyzer in Android Studio.
As is typical, assets are the overwhelming majority
of the APK size.
The other elements of your APK should be no surprise.
If they are, you can drill in further here.
And if that isn't enough, you can
consider using other tools outside the APK,
such as Bloaty McBloatface.
Bloaty is especially useful for code assets when size of those
is a concern.
Now click into the Assets bullet to take a quick look
at the assets.
In this case, nothing unusual.
Lots of small and odd sized texture
should be combined, for instance.
There are two benefits from doing so,
reduced file size overhead and reduced texture overhead.
More textures is more texture handles and more set
texture calls.
Using texture atlases to combine small textures
pays off all the way around.
Let's look at memory usage.
Android game dev recommends targeting 800 meg of memory
on 2 gig devices, for instance.
More than that, and you risk LMKs
when you consider system usage.
If you're close to that on a 2 gig device,
the new memory API will let you dial in.
Check out Victor and Bill's talk on memory management
to learn more about that.
More memory, higher threshold.
More memory, less percent of the total is system,
so that helps threshold be a higher percent.
ADB Shell Dumpsys Meminfo is a easy way
to check initial thresholds.
ADB is one of the primary tools for developers.
It's used for a wide variety of tasks.
The shell command has a lot of versatility,
and this is just one use.
And if you're over the threshold for your budget,
then a deep dive is required.
Starting a profile in Android Studio gets the above view.
Here, we see the total allocation size.
You can drill into the memory bucket
to see the types of memory in more detail.
Note, if you're close to the 800 meg threshold on a 2 gig
device, the new memory API will help
you dial in C talk, GGDS, ADDK, introducing the memory API
and how to diagnose memory problems for more details.
Now, drilling into the memory bucket,
we can see the types of allocations and size.
And we're just checking to see if the allocations
and sizes make sense.
Those 35 meg of graphics memory makes sense for the few assets,
for instance.
So here, the ABK analysis is reused
when examining the graphics assets in memory.
Now, on to CPU use.
Here, we're using CPU profiling to determine
if we're making a consistent frame rate, check thread
workloads, et cetera.
You use Systrace to get a CPU thread view,
and you use the Android Studio CPU profile or call stack
recording SimplePerf to drill in on a thread
with the [INAUDIBLE] and get timings.
If you're making frame rate, great.
If not, we'll use AGI to drill in
to continue the deep dive here.
I also want to note the frame pacing library can help.
It's available to integrate in EGK.
Another thing about this sample, note
having to tweak the manifest to get game mode to work
with the AGDK sample.
Of course, this is just a sample.
It would be a real world game, it
will have a real world workload.
Look at the CPU tracks and server slinger present
and see the pattern.
Drilling in to see the surface slinger present pattern
and recognizing when you're not making a consistent frame time
is when it's time to drill into your graphics performance.
Note this to present fingerprint for future reference.
Use the Android Studio CPU profiler, drill in.
Start a call stack recording.
Pick a game thread of interest, then the top down tab,
and you can see the call stack in that thread with timings
and costs.
This can help identify hotspots.
Finally, GPU analysis some tools guidance AGI system profiler
gives you a tracelike insight into your app's performance
over multiple frames for CPU memory process and GPU details
AGI frame profiler ties GPU performance data to the render
pass and even down to draw calls through its static analysis
features for a single frame.
Use counter setting.
It's very useful.
Age decay tunnel findings, the AGI system profile
is consistent here with a Systrace profile
using the source surface flinger pattern.
It's a good cross-check.
Check out the AGI specific talk, AGDK optimizer GPU usage
with Android GPU inspector.
It will spend more time in the new UI and features.
One useful system profile or view
is the GPU view, which shows for each frame
the render stages for each surface render pass.
This lets you see the components of your frame
another is the GPU counters per capture
it can be useful to a set of predefined counters
for Vertex texture compute et cetera
the elements of your frame letting you examine them
separately in a final capture with a set of all the counters
this allows you to view specific data or all of it at once.
AGI Frame profiler ties GPU performance data to the render
pass here we show the frame buffer and the Command view.
This talk is more about workflow and putting the pieces
together.
There are other views in AGI to help
you understand your performance hotspots,
and as I said previously, check out AGDK, optimize your GPU
usage with Android GPU Inspector,
for more depth on AGI.
AGI has a wide range of features,
too many to go in detail in the time available.
AGI is your deep dive drilling tool for GPU performance
on Android.
This is the performance counter detailed graph view.
Please go to the AGI talk, optimize your GPU usage
with Android GPU Inspector, for an even deeper dive
on just AGI.
Now, pulling it all together.
With the five areas and tools included, what have we learned?
Craft a performance budget it's important.
To have a hard goal to measure against.
How do you know if you're done?
Just hitting 60 Hertz is a poor budget goal.
Measure regularly with your tools of choice.
Consider these five areas and others
as required by your needs.
Perform initial probe across your performance
areas and deep dive where you have issues
and iterate regularly.
Download AGDK, build great games, optimize.
The key is to understand what your target frame
budget is ahead of time and measure regularly.
Use the tools across the areas, assess, dig in.
Thank you for joining me today and learning more
about optimizing your game with Android tools.
I hope you enjoy the rest of the Summit.
[AUDIO LOGO]