| page.title=Analyzing Network Traffic Data |
| trainingnavtop=true |
| |
| @jd:body |
| |
| <div id="tb-wrapper"> |
| <div id="tb"> |
| |
| <h2>This lesson teaches you to</h2> |
| <ol> |
| <li><a href="#general-traffic">Analyze App Network Traffic</a></li> |
| <li><a href="#traffic-types">Analyze Network Traffic Types</a></li> |
| </ol> |
| |
| </div> |
| </div> |
| |
| <p> |
| In the previous section, 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. |
| </p> |
| |
| |
| <h2 id="general-traffic">Analyze App Network Traffic</h2> |
| |
| <p> |
| 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. |
| </p> |
| |
| <p> |
| Figure 1 shows suboptimal network traffic from 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. |
| </p> |
| |
| <img src="{@docRoot}images/training/performance/suboptimal_network_traffic_pattern.png" |
| alt="" id="figure1" /> |
| <p class="img-caption"> |
| <strong>Figure 1.</strong> Battery-inefficient network activity measured from an app. |
| </p> |
| |
| <p> |
| 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. |
| </p> |
| |
| <img src="{@docRoot}images/training/performance/optimal_network_traffic_pattern.png" |
| alt="" id="figure2" /> |
| <p class="img-caption"> |
| <strong>Figure 2.</strong> Battery-efficient network activity measured from an app. |
| </p> |
| |
| <p> |
| 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 <a href= |
| "{@docRoot}training/performance/battery/network/action-any-traffic.html">Optimizing General Network |
| Use</a> |
| </p> |
| |
| <p> |
| 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. |
| </p> |
| |
| |
| <h2 id="traffic-types">Analyze Network Traffic Types</h2> |
| |
| <p> |
| 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. |
| </p> |
| |
| <p> |
| 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. |
| </p> |
| <img src="{@docRoot}images/training/performance/network_traffic_colors.png" /> |
| <p class="img-caption"> |
| <strong>Figure 3.</strong> Network traffic tagged for the three categories: user, app, and |
| server. |
| </p> |
| |
| <p> |
| The Network Traffic tool colors traffic based on the tags you created in the previous lesson. The |
| colors are based on the traffic type <a href= |
| "{@docRoot}training/performance/battery/network/gather-data.html#constants">constants you defined</a> in |
| your app code. Refer back to your app code to confirm which constants represent user, app, or |
| server-initiated traffic. |
| </p> |
| |
| <p> |
| The following sections discuss how to look at network traffic types and provides recommendations |
| on how to optimize traffic. |
| </p> |
| |
| |
| <h3 id="user">Analyzing user-initiated network traffic</h3> |
| |
| <p> |
| 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. |
| </p> |
| |
| <p> |
| 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. |
| </p> |
| |
| <p> |
| Here are some approaches for optimizing user-initiated network traffic: |
| </p> |
| |
| <ul> |
| <li> |
| <a href="{@docRoot}training/performance/battery/network/action-user-traffic.html#pre-fetch-data"> |
| Pre-fetch Network Data</a> - 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. |
| </li> |
| |
| <li> |
| <a href="{@docRoot}training/performance/battery/network/action-user-traffic.html#check-or-listen"> |
| Check for Connectivity or Listen for Changes</a> - Check for network connectivity or listen |
| for connectivity changes before performing an update. |
| </li> |
| |
| <li> |
| <a href="{@docRoot}training/performance/battery/network/action-user-traffic.html#reduce-connections"> |
| Reduce the Number of Connections</a> - Use server APIs that allow data to be downloaded in sets. |
| </li> |
| </ul> |
| |
| <p class="caution"> |
| <strong>Caution:</strong> 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. |
| </p> |
| |
| |
| <h3 id="app">Analyzing app-initiated network traffic</h3> |
| |
| <p> |
| 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. |
| </p> |
| |
| <p> |
| Here are some approaches for optimizing app-initiated network traffic: |
| </p> |
| |
| <ul> |
| <li> |
| <a href="{@docRoot}training/performance/battery/network/action-app-traffic.html#batch-schedule"> |
| Batch and Schedule Network Requests</a> - Defer your app's network requests so they can be |
| processed together and at a time which is advantageous for battery life. |
| </li> |
| |
| <li> |
| <a href="{@docRoot}training/performance/battery/network/action-app-traffic.html#check-connect"> |
| Allow System to Check for Connectivity</a> - 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. |
| </li> |
| </ul> |
| |
| |
| <h3 id="server">Analyzing server-initiated network traffic</h3> |
| |
| <p> |
| 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. |
| </p> |
| |
| <p> |
| Here is an approach for optimizing app-initiated network traffic: |
| </p> |
| |
| <ul> |
| <li> |
| <a href="action-server-traffic.html#gcm">Use GCM for Server Updates</a> - Consider using |
| the Google Cloud Messaging service for server side updates instead of polling. |
| </li> |
| </ul> |