Center pane: Connection View and Thread View

Connection View shows data sent/received in the highlighted portion of the timeline. Perhaps what is most notable is the ability to sort resource files by size, status time, and more. In the Timeline section in Figure 7-6, you may have noticed the colorful blocks split into two colors: orange and blue. The orange portion represents the time it takes to complete an HTTP request while the blue portion represents the time of the response coming back.

Figure 7-6. Connection View

The total amount of time that passes for rendering amounts to roughly 23 seconds, and the majority of the time within the request/response leans heavily for response time. In terms of data format, loading JPEG files is perhaps the best choice for the purpose of this application. We wish to use a good quality image for the user to zoom in to the tiles while keeping consistent quality. Using a JPEG also takes up less memory than a PNG file would. So the file format makes sense, but it would be worth opening the Thread View to see how this work is offloaded by threading.

We now show Thread View like in Figure 7-7 for the same network request made in the previous image. While Connection View looks close to the timeline in Thread View, they’re not quite the same. Thread View shows network activity for every CPU thread involved in the highlighted network requests.

Figure 7-7. Thread View

Seeing how worker threads divides labor real-time can help to reveal areas for improvement. Given the amount of data a single map works with, well, the rendering you see in the image above is by the design. The pooled-threads are responsible for dividing the work to download all these images.

So far, with the information we’ve looked at, the network activity appears to be reasonable. However, we can get more tangible and definite information when selecting on any call detected in Network Profiler. From either Connection View or Thread View, you can select any item for more granular detail in a separate pane. In the next section, we’ll be able to look into the specifics of each call and where we can look in our code for these network calls being made.

Right pane: Overview | Response | Request | Callstack

In software engineering and as an Android developer, it is common to work with other platforms for feature parity and more. Suppose a network call starts returning the wrong kind of information for a network request. The API team is in need of specifics for the network request and response you’re getting client side. How can you send them over the necessary request parameters and content headers they need to investigate on their side?

Network profiler gives us the ability to inspect network responses and requests on the right-side panel in a connection or thread view:

Figure 7-8. Network Profiler allows you to inspect HTTP response and request information

The Overview tab details notable highlights captured in HTTP request and response:

• Request: the path and potential query parameters.

• Status: the HTTP status code returned within the resulting response.

• Method: the type of method used in the HTTP rest.

• Content Type: the media type of the resource.

• Size: the size of the resource returned in the resulting response.

• “Is the format of the data I’m transferring most appropriate to work with?”

Request or Response tabs shows a break down of headers, parameters, body data, etc. This app uses a basic HTTP API. Other types of API data formats return HTML, JSON, and other types of resources. When applicable, the Request and Response tabs offers body data as formatted or raw representation. In our case, the resource media returns JPEGs.

Figure 7-9. Network Profiler captures network calls to render map from USGS.

Finally, the Callback tab that shows the stack trace for the relevant calls made to execute a network connection:

The calls that are not faded out represent the calls within the callstack coming from your own code. You can right-click the calls indicated to be able to jump to the source code with ease.

Using the Network Profiler proves useful for more than just analytics. As you can see for yourself, you’re able to process a lot of information quickly. From catching repetitive calls to confirming API contracts between client and server, the Network Profiler is one well worth keeping in your toolbelt.

Could TrekMe’s networking calls be the reason for the slower map rendering time? The task of creating a brand new topographical map is heavy in itself, but the network calls seem relatively straightforward. It appears the duration of network calls take longer for response times. There could be several reasons for this: for example, the server connection might be weaker if one attempts to pull this data from many countries away. Perhaps there are inefficiencies with the query call in the backend. However, it would be remiss in our exploration to chalk up slow loading times to network call response time without actually checking how long methods are running for. The CPU Profiler is able to provide insight for this. In the next section, we continue to examine IGN Spain map rendering and its consumption in processing using the CPU Profiler.

CPU timeline

The graph in Figure 7-11 shows spikes of CPU usage, where the number is percent of available CPU. If you have made a trace recording, you should be able to highlight the CPU timeline to see more information.

Figure 7-11. CPU Timeline

Android Studio allows you to drag-and-click over a recorded sample from the CPU timeline to show the Call Chart. Clicking on Record brings you to a separate trace CPU recording screen (covered in greater detail in Record Traces). To create more granular call charts we look into in the next section, it helps to highlight smaller portions of the recorded CPU trace.

Thread activity timeline and call chart

The Thread activity timeline accompanies the CPU timeline showing every running thread in the application. Granted that a section had been trace recorded, you should be able to select a thread to view the call stack captured within the selected time range.

Within Figure 7-12 20 threads are created and used within the application. These threads have been created either by your code, the Android OS, or a 3rd party library.

Figure 7-12. Thread activity timeline

The green blocks represents a running or active thread. There’s not a lot of greenery to see for the Main thread, but remember, this image captures a CPU trace of the network request downloading the map images. In this case, we expect background threads do the necessary work to download the network data. It seems we have the main thread waiting on one of the DefaultDispatcher threads for half the time. Double-clicking on an individual thread expands the callstack.

Below the thread activity timeline is a color-coded graph known as a Call Chart, pictured in Figure 7-13. The Call Chart shows a segmented range of time for CPU usage. The top most boxes represent the encapsulating parent method while the methods underneath represent child methods called within the parent method. The parent method waits on children methods to finish executing, so this is a good place to examine if any methods in the application code could be executing for a long time.

Figure 7-13. The Call Chart shows a Top-Down representation of captured methods

Android OS methods are color-coded orange, methods you’ve written in your application are green, and 3rd party library APIs are blue. Within this coroutine, the longest amount of execution time is with TileStreamProviderHttp.getTileStream(...). This is expected, given that this call makes individual network requests per tile.

As you’re starting to get the picture of what kind of information CPU Profiler tries to capture, we’ll turn to Method Tracing with the CPU Profiler and record a segment of TrekMe creating a new map.

Method tracing

CPU Profiler allows you to record a trace to analyze and render status, duration, and type, and more. Tracing relates to recording device activity over a short period of time. Method tracing doesn’t occur until the recording button is clicked twice: once to start recording, and another time to end the recording. Depending on the coding configuration pictured below in Figure 7-14, a Sample or Trace configuration may be to determine what the recording captures.

Figure 7-14. Configurations are available for Android Developers for samples and traces.

Sample Java Methods captures the application call stack, or a Call Chart (also seen in previous sections). The Call Chart renders under the Thread activity timeline, which shows which threads are active at a particular time. These traces store individual sessions to the right pane for comparison with others saved sessions.

Figure 7-15. Sample Java Methods

Figure 7-15 shows a screenshot hovering over on of the methods running in the main thread. By choosing the Sample Java Methods configuration, you can examine TrekMe’s callstack by hovering the mouse pointer over particular methods.

Unlike Sample Java Methods, Trace Java Methods strings together a series of timestamps recorded for the start and end of a method call. Should you wish, you can monitor Sample C/C+ Functions to gain insight on how the app is interacting with the Android OS. Recording sample traces for native threads are available for Android API 26 and up.

Finally, there is Trace System Calls in the configurations shown in Figure 7-14. System Trace is a powerful CPU recording configuration made available for Android developers. It gives back graphical information on frame-rendering data.

A closer look for the previous image shows how the Android system’s draw function takes up a good portion of time in the main thread. In Figure 7-16 below, we zoom in to show how performDraw() takes signficantly longer than the network calls previously highlighted in Figure 7-15.

Figure 7-16. Main thread shows more time dedicated to perform draw.

A System Trace records analytics on CPU Cores to see how scheduling occurs across the board. System Tracing becomes more meaningful for detecting CPU bottlenecks across the CPU Cores. These kinds of bottlenecks can jump out in places where the RenderThread chokes, especially for red-colored frames. Unlike other configurations, System Trace shows thread states and the CPU cor it currently runs on, as shown in Figure 7-17:

Figure 7-17. System Trace

One of the key features we show here is having access to RenderThread. RenderThread can be a great indicator to show where bottlenecks might be occurring when attempting to render application UI. In the case above, we can see that much of the idle time indeed seems to be running on idle around the actual drawing of the tiles themselves.

By modern standards, the Android system tries to redraw the screen depending on the refresh rate on the screen (between 8ms and 16ms). Even so, the same is still true that work packets taking longer than expected can cause dropped frames. In a CPU core, a red slot indicates a dropped frame where some task does not return quickly enough before the screen redraws itself. In the case of this TrekMe system trace recording, it appears we do have some dropped threads indicated in the Frames section below:

TrekMe saves each frame into a JPEG file and load the image into a Bitmap for decoding. However, Figure 7-17 above, we see that in the RenderThread, the length of DrawFrame doesn’t quite match up with the draw rate intervals. A bit further below that, some of that idle time is tied to various long-running decodeBitmap methods in the pooled threads.

From here, there are some options that could potentially be considered for faster drawing i.e. caching network responses for images, or even prefetching. Prefetching is a nice-to-have in the case a device has access to at least a 3G networking and a larger rate of MB. The problem with that is that it may not be the best option to render those bitmaps before we know what must be rendered. Another option could potentially encoding the data into a more compressed format for an easier time decoding. Whatever the decision, it’s up to the developer to evaluate the trade-offs and the effort of implementing certain optimizations.

Recording a Sample Method Trace

Now you are more familiar with what the recording configurations offers, we now turn to Sample Method Trace on TrekMe. CPU recordings are separated from the CPU profiler timeline. To begin, click the “Record” button at the top of the screen to analyze CPU activity while interacting with TrekMe.

Ending the recording renders a tabbed right pane of execution times for sample or trace calls. You can also highlight multiple threads at once for analysis. The average Android developer may not use all these tabs all the timeline. Still, it’s good to be cognisant of what tools are at your disposal given the right problem.

In TrekMe, there’s a predefined set iterable of tiles to download. A number of coroutines concurrently read the iterable and perform a network request per tile. Each coroutine decodes a Bitmap right after the network request succeeded. These coroutines are dispatched on a dispatched similar to Dispatchers.IO, and the rendering happens on UI thread. The UI thread is never blocked waiting for whatever Bitmap decoding, or network request.

Figure 7-18. CPU Profiler separates the recorded trace

The shrunken CPU timeline in Figure 7-18, at first glance, appears to be nothing more than a reference to the previous screen view. However, you can interact with this data to drill down further by highlighting a chunk of time via the range selector where the data below corresponds.

Figure 7-19. The range selector helps to manage sections of highlighted ranges.

In the image below, we look at one of the longer-running methods, getTileStream. Below the timeline, the left panel allows you to organize threads and interactions via drag-and-drop functionality. Being able to group threads together also means you can highlight groups of stack traces. You can expand a thread in recorded trace by double-clicking the thread twice to show a dropdown visual of a callstack:

Figure 7-20. You can search for a specific method via the search function.

Selecting an item also opens an additional pane to the right. The right side is the Analysis Panel, which allows you to examine stack trace and execution time in more granular detail. We cover this more in the subsequent section.

Analysis Panel

Analysis Panel holds a layered tab view. At the top of the pane highlights the active set of thread(s) showing. Beneath the tabbed menu sits a search bar above the stack trace. You can use a search bar to filter trace data related to a particular call. Below is set of tabs intended to render visual data from method-tracing in three views: Top Down, Bottom Up, and Flame Chart.

Top Down renders a graphical representation where method traces from the top to the bottom of the chart. Any callee methods made within a particular method renders as a child underneath the original method. In Figure 7-21, the method getTileStream used in TrekMe waits for a series of calls for internet connection and reading from a data stream.

Figure 7-21. Top Down

The Top Down view shows how CPU time breaks down in three ways:

• Self: the method execution time itself.

• Children: the time it takes to execute callee methods.

• Total: combined time of self and the children.

In the case of getTileStream, the majority of the time is spent on the network calls themselves: in particular, the connection request and getInputStream to receive incoming data from the network. For the IGN Spain server, these times can vary when accessed in another country and at different parts of the day. Being the client consuming server data, TrekMe has no control for how the server performs.

Contrary to Top Down, Bottom Up shows an inverse representation of leaf elements of the call stack. In comparison, such a view renders a substantial number of methods, which can be useful to locate methods consuming the most CPU.

Figure 7-22. Bottom Up

The final tab provides a Flame Chart view. A Flame Chart provides an aggregated visual of operations from the bottom up. It provides an inverted call chart to better see which functions/methods are consuming more CPU time. The horizontal axis is relative time it takes to execute a function compared to others (as opposed to real time).

To summarize, CPU profiling can render three different kinds of views depending on the kind of deep dive you wish to pursue:

• Top Down graphical representation shows each method call’s CPU time along with the time of its callees.

• Bottom Up inverts the Top Down representation and is most useful to sort methods consuming the most or the least amount of time.

• The Flame Chart inverts and aggregates the callstack horizontally with other callees of the same level to show which ones consumes the most CPU time first.

Tracking CPU usage is important, but perhaps you’d like to be able to analyze how an application interacts with Android hardware components. In the next section, we look into Android Studio’s Energy Profiler.

Excessive networking calls expensive can for an Android device in terms of processing and memory, but they are also power-hungry. The longer the device radio stays awake for network communication, the more CPU consumption and battery drainage there is. By this logic, it would be fair to assume that networking makes up the most of energy consumption. We can confirm this by using Energy Profiler.