Android programming power saving-network update Method

The optimal frequency of regular updates depends on the device status, network connection, user behavior, and clear user preferences.

Optimized battery life and discussed how to create an efficient battery application by modifying the refresh Frequency Based on the status of the host device. This includes disabling background service updates after you lose connection and reducing the update speed when the battery is low.

Here we will introduce the update frequency to minimize the impact of the update operation on the radio state machine.

Use push information to replace email service

Every time the app sends a request to the server to check whether there is any update operation, the radio will be activated, resulting in unnecessary energy consumption (in 3G cases, it will consume almost 20 seconds ).

C2dm is a lightweight mechanism used to transmit data from the server to a specific app. When c2dm is used, the server notifies the app of this message when an app has new data. Compared with the polling method (the app needs to request data from the server on a regular basis to get the latest data in real time ), c2dm, an event-driven model, notifies the app to create a network connection to obtain data when only data is updated.

The result is to reduce unnecessary connections and reduce the latency of updated data in your application.

C2dm must be implemented by using a fixed TCP/IP. C2dm is recommended when you can declare the PUSH Service. Obviously, c2dm reduces the number of network connections, bandwidth, and power consumption. "

Round Robin is optimized through irregular repeated reminders and Exponential Backoff

If you need to use the polling mechanism without affecting the user experience, of course, setting the default update frequency is as low as possible [reducing power waste]. A simple method is to provide users with an update frequency option, allowing users to balance data timeliness and power consumption on their own. After the update operation is configured, you can use the uncertain repetition reminder method to allow the system to move the current operation in a targeted manner.

    int alarmType = AlarmManager.ELAPSED_REALTIME;    long interval = AlarmManager.INTERVAL_HOUR;    long start = System.currentTimeMillis() + interval;         alarmManager.setInexactRepeating(alarmType, start, interval, pi);
If multiple reminders are "targeted to move", it is very likely that they will be triggered at a certain point at the same time, so that multiple operations can be completed in the same radio state.
If yes, set the reminder type to elapsed_realtime or RTC instead of _ wakeup. This can further reduce the consumption of power while waiting for triggering at the same time.
We can also selectively reduce the update frequency based on the app usage frequency.
Another method is to use the exponential back-off algorithm to reduce the update frequency when the app is not used after the last update operation. Of course, we can also use methods similar to Exponential Backoff:
    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 Backoff Algorithm to reduce the impact of failed connections and download errors.
The cost of initializing a network connection does not change because data is successfully downloaded. We can use the Exponential Backoff Algorithm to reduce the number of retries to avoid wasting power. For example:
    private void retryIn(long interval) {    boolean success = attemptTransfer();    if (success) {    retryIn(interval* 2 < MAX_RETRY_INTERVAL ?    interval* 2 : MAX_RETRY_INTERVAL);    }    }
In addition, for transfer failures (such as regular updates), you can simply ignore connection failures and transfer attempts.