WOJTEK KALICINSKI: Android Studio 3.0
introduces an integrated view for providing the memory, CPU,
and network request characteristics of your app.
It's a complete overhaul of the previous tools found
under the Android Monitor tab, which we've now
renamed to Android Profiler.
If you're profiling with an API 26, so Android O or above,
device or emulator, you're all set.
You can profile any APK, regardless of the build
system it was created with.
If you connect the Profiler to a device with a lower API level,
you might see this warning.
Because we need to instrument your code
to take full advantage of the Profiler on older devices,
you should use Android Studio to build and deploy your app.
The main view of the Profiler presents a unified timeline
showing you the user charts for CPU, memory,
and network in real time.
At the top, you can also see important app events
such as user input, activity state transitions, and device
rotations, giving you more context for the data below.
Clicking on any of the three charts
takes you to one of the detailed views.
Let's check out the CPU Profiler first.
The UI shows a live CPU utilization graph, and the list
of all threads in your app and their states,
such as when they were active or waiting
for I/O. You can get a detailed trace of methods executed
in a given period by pressing the record button.
One thing to note is the trace type.
Sampled has a smaller overhead, but is not as accurate,
meaning it could miss the execution of a very
short-lived method.
Instrumented means that the Profiler
will record every method, enter, and exit, accurately.
On pre-Android O devices, there's a limit to how much
data can be recorded.
So be aware that the instrumented trace capture
will reach that limit faster.
If you want to increase the limit
or change the sampling rate, you can
do that in the Edit Configuration window here.
After you've finished the capture,
select the thread you're interested in.
The Top Down view shows a tree of methods and their callees,
aggregating trace information for identical methods
that share the same call stack, similar to the flame chart.
The Bottom Up tab displays a list of method
calls where expanding a method's node displays its callers.
You can see a graphical representation
on the call chart, which shows time
spent in each call on the horizontal axis.
The Memory Profiler shows a real-time chart
of memory used by your app attributed
to various buckets such as Java, native, graphics, et cetera.
You can see any garbage collection events
on the timeline, and you can force one
using the button on the top left.
You can dump the heap at any moment
and examine instance properties of objects.
The References tab can help you figure out memory leaks
by listing all references, pointing
to the object being examined.
There's one more feature that is very useful for tracking
memory use over time--
allocation tracking.
If you're profiling against a device running
API 26 or higher, you can simply highlight
any part of the timeline, and you'll
get a list of all objects allocated and deallocated
within that period, including the call
stack of the allocation.
On API 25 and lower, you will need to explicitly
start and stop recording allocations using
the record button, similar to how the CPU method
tracing works.
Another difference is that on lower API versions,
the call stacks are, by default, capped to a depth of 16 frames.
There is a system property you can
set prior to running your app to temporarily enable
deeper stack traces.
Finally, let's look at the Network Profiler.
The line labeled Radio shows a high-level overview
of the networking state of the device.
By looking at it, you can tell how often
the device is waking up the radio
into a high-powered state, which might suggest you're not
batching your network requests correctly and wasting battery
life.
The chart below shows actual network connection activity,
including bytes sent and received.
Whenever advanced profiling is switched on
or you're running on a compatible API 26 device,
you can highlight any slice of time
and inspect all network calls made, including actual HTTP
request and response data and the call
stack where the call happened.
We even show previews for images and enable syntax
highlighting for XML and JSON.
If you've ever used anything like Chrome's DevTools Network
tab, this view should look very familiar.
It's great for debugging your app's HTTP server interactions
and data consumption.
The HTTP call inspection is currently
enabled for the standard HttpURLConnection
class and the OkHttp client but should also
work with other libraries built on top of these APIs.
So that's it for the three new Profilers.
We are shipping the first version in Android Studio 3.0
and will be continuing to add new features.
I hope they'll prove useful in debugging performance
issues in your apps.
And if there are any features you'd like to see,
let us know on the issue tracker.
Thanks for watching.
[MUSIC PLAYING]