The Network Traffic tool is deprecated. If you're using Android Studio 3.0 or higher, you should use the[Network Profiler](https://developer.android.com/studio/profile/network-profiler)to examine how and when your app transfers data over a network.

In the[previous section](https://developer.android.com/topic/performance/power/network/gather-data), you tagged your app code with traffic identifiers, ran tests, and collected data. This lesson teaches you how to look at the network traffic data you have collected and directs you to actions for improving your app's networking performance and reducing power consumption.

## Analyze app network traffic

Efficient use of network resources by an app is characterized by significant periods where the network hardware is not in use. On mobile devices, there is a significant cost associated with starting up the radio to send or receive data, and with keeping the mobile radio active for long periods. If your app is accessing the network efficiently, you should see that its communications over the network are tightly grouped together, well spaced with periods where the app is making no connection requests.

Figure 1 shows suboptimal network traffic from an app, as measured by the Network Traffic tool. The app is making frequent network requests. This traffic has few periods of rest where the radio could switch to a standby, low-power mode. The network access behavior of this app is likely to keep the radio on for extended periods of time, which is battery-inefficient.

![](https://developer.android.com/static/images/topic/performance/power/network/suboptimal_network_traffic_pattern.png)**Figure 1.**Battery-inefficient network activity measured from an app.

Figure 2 shows an optimal network traffic pattern. The app sends network requests in bursts, separated by long periods of no traffic where the radio can switch to standby. This chart shows the same amount of work being done as figure 1, but the requests have been shifted and grouped to allow the radio to be in standby most of the time.

![](https://developer.android.com/static/images/topic/performance/power/network/optimal_network_traffic_pattern.png)**Figure 2.**Battery-efficient network activity measured from an app.

If the network traffic for your app looks similar to the graph in figure 2, you are in good shape! Congratulations! You may want to pursue further networking efficiency by checking out the techniques described in[Optimizing General Network Use](https://developer.android.com/training/performance/battery/network/action-any-traffic).

If the network traffic for your app looks more like the graph in figure 1, it's time to take a harder look at how your app accesses the network. You should start by analyzing what types of network traffic your app is generating.

## Analyze network traffic types

When you look at the network traffic generated by your app, you need to understand the source of the traffic, so you can optimize it appropriately. Frequent network activity generated by your app may be entirely appropriate if it is responding to user actions, but completely inappropriate if you app is not in the foreground or if the device in a pocket or purse. This section discusses how to analyze the types of network traffic being generated by your app and directs you to actions you can take to improve performance.

In the previous lesson, you tagged your app code for different traffic types and used the Network Traffic tool to collect data on your app and produce a graph of activity, as shown in figure 3.

![](https://developer.android.com/static/images/topic/performance/power/network/network_traffic_colors.png)**Figure 3.**Network traffic tagged for the three categories: user, app, and server.

The Network Traffic tool colors traffic based on the tags you created in the previous lesson. The colors are based on the traffic type constants you defined in your app code. Refer back to your app code to confirm which constants represent user, app, or server-initiated traffic.

The following sections discuss how to look at network traffic types and provides recommendations on how to optimize traffic.

## Analyze user-initiated network traffic

Network activity initiated by the user may be efficiently grouped together while a user is performing a specific activity with your app, or spread out unevenly as the user requests additional information your app needs to get. Your goal in analyzing user-initiated network traffic is to look for patterns of frequent network use over time and attempt to create, or increase the size of, periods where the network is not accessed.

The unpredictability of user requests makes it challenging to optimize this type of network use in your app. In addition, users expect fast responses when they are actively using an app, so delaying requests for efficiency can lead to poor user experiences. In general, you should prioritize a quick response to the user over efficient use of the network while a user is directly interacting with your app.

Here are some approaches for optimizing user-initiated network traffic:

- [Pre-fetch Network Data](https://developer.android.com/training/performance/battery/network/action-user-traffic#pre-fetch-data)- When the user performs an action in your app, the app anticipates which data may be needed for the next user actions, fetches it in bulk in a single connection, and holds it until the user requests it.
- [Check for Connectivity or Listen for Changes](https://developer.android.com/training/performance/battery/network/action-user-traffic#check-or-listen)- Check for network connectivity or listen for connectivity changes before performing an update.
- [Reduce the Number of Connections](https://developer.android.com/training/performance/battery/network/action-user-traffic#reduce-connections)- Use server APIs that allow data to be downloaded in sets.

| **Caution:** Beware of network activity grouping bias in your user activity test data! If you ran a set of user scenarios with your network testing plan, the graph of user-initiated network access may be unrealistically grouped together, potentially causing you to optimize for user behavior that does not actually occur. Make sure your user network test scenarios reflect realistic use of your app.

## Analyze app-initiated network traffic

Network activity initiated by your app code is typically an area where you can have a significant impact on the efficient use of network bandwidth. In analyzing the network activity of your app, look for periods of inactivity and determine if they can be increased. If you see patterns of consistent network access from your app, look for ways to space out these accesses to allow the device radio to switch into low power mode.

Here are some approaches for optimizing app-initiated network traffic:

- [Batch and Schedule Network Requests](https://developer.android.com/training/performance/battery/network/action-app-traffic#batch-schedule)- Defer your app's network requests so they can be processed together and at a time which is advantageous for battery life.

- [Allow System to Check for Connectivity](https://developer.android.com/training/performance/battery/network/action-app-traffic#check-connect)- Avoid the battery cost of running your app just to check for a network connection when you can let the system run the check while your app sleeps.

## Analyze server-initiated network traffic

Network activity initiated by servers communicating with your app is also typically an area where you can have a significant impact on the efficient use of network bandwidth. In analyzing the network activity from server connections, look for periods of inactivity and determine if they can be increased. If you see patterns of consistent network activity from servers, look for ways to space out this activity to allow the device radio to switch into low-power mode.

Here is an approach for optimizing server-initiated network traffic:

- [Use FCM for Server Updates](https://developer.android.com/topic/performance/power/network/action-server-traffic#fcm)- Consider using the Firebase Cloud Messaging service for server side updates instead of polling.