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.