Transferring Data Without Draining the Battery - Minimizing the Effect of Regular Updates
2015-02-28 14:50
477 查看
The optimal frequency of regular updates will vary based on device state, network connectivity, user behavior, and explicit user preferences.
Optimizing Battery Life discusses how to build battery-efficient
apps that modify their refresh frequency based on the state of the host device. That includes disabling background service updates when you lose connectivity and reducing the rate of updates when the battery level is low.
This lesson will examine how your refresh frequency can be varied to best mitigate the effect of background updates on the underlying wireless radio state machine.
Every time your app polls your server to check if an update is required, you activate the wireless radio, drawing power unnecessarily, for up to 20 seconds on a typical 3G connection.
Google Cloud Messaging for Android (GCM) is a lightweight mechanism used to transmit
data from a server to a particular app instance. Using GCM, your server can notify your app running on a particular device that there is new data available for it.
Compared to polling, where your app must regularly ping the server to query for new data, this event-driven model allows your app to create a new connection only when it knows there is data to download.
The result is a reduction in unnecessary connections, and a reduced latency for updated data within your application.
GCM is implemented using a persistent TCP/IP connection. While it's possible to implement your own push service, it's best practice to use GCM. This minimizes the number of persistent connections and allows the
platform to optimize bandwidth and minimize the associated impact on battery life.
A simple approach is to offer preferences to allow users to explicitly set their required update rate, allowing them to define their own balance between data freshness and battery life.
When scheduling updates, use inexact repeating alarms that allow the system to "phase shift" the exact moment each alarm triggers.
If several alarms are scheduled to trigger at similar times, this phase-shifting will cause them to be triggered simultaneously, allowing each update to piggyback on top of a single active radio state change.
Wherever possible, set your alarm type to
than to their
You can further reduce the impact of these scheduled alarms by opportunistically reducing their frequency based on how recently your app was used.
One approach is to implement an exponential back-off pattern to reduce the frequency of your updates (and / or the degree of prefetching you perform) if the app hasn't been used since the previous update. It's often
useful to assert a minimum update frequency and to reset the frequency whenever the app is used, for example:
You can use a similar exponential back-off pattern to reduce the effect of failed connections and download errors.
The cost of initiating a network connection is the same whether you are able to contact your server and download data or not. For time-sensitive transfers where successful completion is important, an exponential
back-off algorithm can be used to reduce the frequency of retries in order to minimize the associated battery impact, for example:
Alternatively, for transfers that are failure tolerant (such as regular updates), you can simply ignore failed connection and transfer attempts.
Optimizing Battery Life discusses how to build battery-efficient
apps that modify their refresh frequency based on the state of the host device. That includes disabling background service updates when you lose connectivity and reducing the rate of updates when the battery level is low.
This lesson will examine how your refresh frequency can be varied to best mitigate the effect of background updates on the underlying wireless radio state machine.
Use Google Cloud Messaging as an Alternative to Polling
Every time your app polls your server to check if an update is required, you activate the wireless radio, drawing power unnecessarily, for up to 20 seconds on a typical 3G connection.Google Cloud Messaging for Android (GCM) is a lightweight mechanism used to transmit
data from a server to a particular app instance. Using GCM, your server can notify your app running on a particular device that there is new data available for it.
Compared to polling, where your app must regularly ping the server to query for new data, this event-driven model allows your app to create a new connection only when it knows there is data to download.
The result is a reduction in unnecessary connections, and a reduced latency for updated data within your application.
GCM is implemented using a persistent TCP/IP connection. While it's possible to implement your own push service, it's best practice to use GCM. This minimizes the number of persistent connections and allows the
platform to optimize bandwidth and minimize the associated impact on battery life.
Optimize Polling with Inexact Repeating Alarms and Exponential Backoffs
Where polling is required, it's good practice to set the default data refresh frequency of your app as low as possible without detracting from the user experience.A simple approach is to offer preferences to allow users to explicitly set their required update rate, allowing them to define their own balance between data freshness and battery life.
When scheduling updates, use inexact repeating alarms that allow the system to "phase shift" the exact moment each alarm triggers.
int alarmType = AlarmManager.ELAPSED_REALTIME; long interval = AlarmManager.INTERVAL_HOUR; long start = System.currentTimeMillis() + interval; alarmManager.setInexactRepeating(alarmType, start, interval, pi);
If several alarms are scheduled to trigger at similar times, this phase-shifting will cause them to be triggered simultaneously, allowing each update to piggyback on top of a single active radio state change.
Wherever possible, set your alarm type to
ELAPSED_REALTIMEor
RTCrather
than to their
_WAKEUPequivalents. This further reduces battery impact by waiting until the phone is no longer in standby mode before the alarm triggers.
You can further reduce the impact of these scheduled alarms by opportunistically reducing their frequency based on how recently your app was used.
One approach is to implement an exponential back-off pattern to reduce the frequency of your updates (and / or the degree of prefetching you perform) if the app hasn't been used since the previous update. It's often
useful to assert a minimum update frequency and to reset the frequency whenever the app is used, for example:
SharedPreferences sp = context.getSharedPreferences(PREFS, Context.MODE_WORLD_READABLE); boolean appUsed = sp.getBoolean(PREFS_APPUSED, false); long updateInterval = sp.getLong(PREFS_INTERVAL, DEFAULT_REFRESH_INTERVAL); if (!appUsed) if ((updateInterval *= 2) > MAX_REFRESH_INTERVAL) updateInterval = MAX_REFRESH_INTERVAL; Editor spEdit = sp.edit(); spEdit.putBoolean(PREFS_APPUSED, false); spEdit.putLong(PREFS_INTERVAL, updateInterval); spEdit.apply(); rescheduleUpdates(updateInterval); executeUpdateOrPrefetch();
You can use a similar exponential back-off pattern to reduce the effect of failed connections and download errors.
The cost of initiating a network connection is the same whether you are able to contact your server and download data or not. For time-sensitive transfers where successful completion is important, an exponential
back-off algorithm can be used to reduce the frequency of retries in order to minimize the associated battery impact, for example:
private void retryIn(long interval) { boolean success = attemptTransfer(); if (!success) { retryIn(interval*2 < MAX_RETRY_INTERVAL ? interval*2 : MAX_RETRY_INTERVAL); } }
Alternatively, for transfers that are failure tolerant (such as regular updates), you can simply ignore failed connection and transfer attempts.
相关文章推荐
- Transferring Data Without Draining the Battery -
- Transferring Data Without Draining the Battery - Modifying your Download Patterns Based on the Conne
- Android: Transferring Data Without Draining the Battery
- Android开发训练之第五章第三节——Transferring Data Without Draining the Battery
- Minimizing the Effect of Regular Updates
- android-Transferring Data Without Draining the Battery
- Transferring Data Without Draining the Battery - Optimizing Downloads for Efficient Network Access
- Transferring Data Without Draining the Battery - Redundant Downloads are Redundant
- Transferring Data Without Draining the Battery【数据传输中有效降低电池消耗】
- A data exploring of the titanic effect
- The techniques of data store and presentation in SAP
- Exploring the Power of Links in Data Mining-韩家炜演讲摘录
- End of the "Road to DataStage Certification" D
- The Tomes of Delphi: Algorithms and Data Structures
- BUG: The GetSchemaTable method of the SqlDataReader object returns the wrong column name
- Algorithms and Data Structures: The Science of Computing
- What is the key of Data Assimilation?
- [zz]Determine the maximum of two integers using macro without any operators.
- Get the data of today only use c language
- A simple Example of data processing from Excel as the datasource