7 ms·

> Every decision you make should be based on minimizing the number of times the radio powers up. This is lunacy. Ok, lunacy is a bit strong. But I disagree wit

> Every decision you make should be based on minimizing the number of times the radio powers up. This is lunacy. Ok, lunacy is a bit strong. But I disagree with this and am throwing a "premature optimization" flag. Modern phone batteries last plenty long, and the radio being on is nothing compared to the big bright screen. /edit Given the opportunity to chose, I know I would gladly sacrifice a few minutes per charge battery life for a better user experience, especially since my phone never gets below 20%. Your users will be better served by you fixing bugs or adding features. Really, unless you're a huge team with a huge budget, there's other stuff to worry about in your app experience before "maximizing battery life" should be a responsibility you want to help the OS/device maker with.(If you're one of the lucky ones who has the time and money to do both, by all means, go nuts.) Being conservative with resource usage is sound advice. Making battery usage the prime concern for most apps is overkill. Games and other applications that you know users will have open for extended periods of time, and/or that are already eating up battery should give this issue some thought, everyone else, really, don't worry about it.

ultimoo 13y ago
Maybe a good mobile app can determine its optimization/ux strategy depending on what level the battery is currently at. I am not sure whether apps can query for battery levels though.
- canthonytucci 13y ago
  At least on iOS you can indeed. It's available from UIDevice. And if you're doing something that sucks up battery, you should know about it and act accordingly. If you're not doing heavy lifting, It's just not something you should have to think about as an app developer, there are so many other areas to focus on to keep users happy. Apple has a few WWDC sessions that talk about it I think. Here's what they have to say in their "performance tuning" section: https://developer.apple.com/library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/PerformanceTuning/PerformanceTuning.html#//apple_ref/doc/uid/TP40007072-CH8-SW1 https://developer.apple.com/library/ios/documentation/iphone...
  - king_jester 13y ago
    The dev bytes cited in the article are specifically focused on Android development. Android provides some interesting framework classes that help with making requests efficiently to the network, both from a power and speed standpoint. A lot of these APIs are really underused (e.g. SyncAdapter) in apps right now, so Google clearly wants more devs to use it since it requires less thinking.
- ProblemFactory 13y ago
  They can. A number of well-built apps pause background data sync if battery is too low. However, changing behaviour based on battery level is trickier than it seems. * The point of reducing energy usage is to leave the user more juice for the actions that are most important to them. It could be that your app is the important one. * Stopping expensive operations at 20% or 30% battery level means that 70-80% was already wasted. If there are good ways of optimising energy use, they should be applied at all times, and prolonging the time until you reach 20%. * The appropriate threshold depends on what the user imagines doing for the rest of the day. If I'm travelling to another city, I disable background data in the morning to make sure I still have battery left for phone calls in the evening after heavy use of maps during the day. If I'm travelling to the office, it doesn't matter, since a charger is nearby. Predicting "time to next charging" and "use of other apps before charging" automatically for context-aware app behaviour is non-trivial.
droopybuns 13y ago
Lunacy is too strong! I think the average mobile app developer has no business thinking about radio optimization. They should however be spending lots of time thinking about cacheing and minimizing interaction with servers. Developers in general have gotten too comfortable with unnecessary traffic on Desktop machines. There are too many devs who have been focused on speed as the limiting factor for mobile apps, when it fact should be cost. The end user is paying not only to acquire your app, but also to use the mobile provider's transport. We should take every opportunity to reinforce the importance of minimizing mobile traffic to only what is necessary. Just because you can use a 4G connection to move a ton of data doesn't mean you should.
- cbhl 13y ago
  It seems like lunacy to me to use a smartphone on a connection where you're charged using usage-based billing. My provider throttles me when I'm over my "cap"...
hyperpape 13y ago
Prefetching is often an element of a pleasant user experience. It also can bring difficult UI problems with it (when is information too stale to display, etc), but that just means it's not easy. It feels like so many apps are designed by people who never have experienced a bad connection, and just assume that their app can download everything it needs quickly as soon as it starts up. What you end up with is bad experiences when your connection is slow or has high latency.
ianstallings 13y ago
I disagree because there are fundamentals, highlighted by the author, that a lot of experienced mobile developers know already through trial and error that should be acknowledged up front. For instance, doing single calls to APIs for multiple pieces of information instead of a bunch of calls. If you design for these up front, you can then head the problem off before it even becomes a problem. It's not premature because users expect it. They do notice network lag, they do notice battery usage, and they will give you one star on the app store or play store, etc. I've literally seen this play out in real life. It's no different than making sure your website loads quickly IMHO. You still have to do all those other things you listed to worry about, but this isn't to be glossed over and addressed when you realize people are noticing.
- mtrimpe 13y ago
  Indeed. This isn't about premature optimization, but about preventing the equivalent of what I've seen happen when you give desktop developers GWT and get a public facing website with a 3 MB JavaScript app that polls a hard to generate 5k document every second just to check if a posted job has completed or not.
timthorn 13y ago
Modern phone batteries last a fraction of the time they used to - you could get phones with 2 weeks life in the days before smartphones. We've got used to short lives but devs should aim to keep power demands down. Radio power consumption is very significant. It could well be more than the screen takes - it's not just the RF amplification, but also the computation required to generate the modulated RF in the first place.
miratrix 13y ago
The difference between DCH (the full-on high power state) and PCH (the lowest power, waiting-for-paging state) is about 2-orders of magnitude. Last time I measured, it was about ~100mA vs ~1mA (at ~3.7V) used by the radio. So, it's not couple of minutes of battery life, but rather _many_ hours of standby life instead. People usually aren't very happy when a fully charged phone dies overnight. I've seen apps do some crazy things and it really has a significant effect in over-all battery life. A popular Android weather clock widget woke the phone up every minute to update the minute number on the graphics and updated the weather information every ~15 minutes (gps + radio!) which single handily crushed the standby battery life from multiple days to less than 8 hours. Yes, I don't think _every_ decision should be based on minimizing the wake ups... but on the other hand, all developers should at least try to have as much understanding of the platforms that they're working on so that they know what trade-offs they're making with each feature they're adding. I'm glad that Google has these videos available and that they're being picked up in places like HN.
- vacri 13y ago
  Anecdata: I turn my phone's wifi off when not required because it has a significant effect on the battery life - particularly when I'm not in range of a wifi signal. I've had a full charge die on an 8-hour country drive because wifi was on. On the return trip, wifi was turned off and it behaved as expected. Go for a long walk in the park? All that time your phone's wifi is straining to find a wifi signal. It's not as big a power sap as the screen, however it's constantly, silently in use and the screen isn't.
  - miratrix 13y ago
    Wifi scanning is also pretty terrible for power consumption as you found out. If you are on Android, my guess is that your phone was set to be connected to Wifi during sleep. You can control it by going to Wifi networks section -> menu -> Advanced -> Keep Wi-Fi on during sleep, then setting it to "Only when plugged in" or "Never". If you're driving around with the phone set to leave the Wifi on during sleep, it'll be constantly going in and out of range of various Wifi connections. If the Wifi part is set for passive scan, then the processor needs to be kept up as the Wifi chip attempts to collect the BSSID of all the network it see and processor tries to figure out whether these networks have been seen or not. If it's set for active scan, then the Wifi needs to power up the radios to transmit beacons. Pretty bad news in either case, unfortunately.
zyb09 13y ago
Not only are you helping the battery, but prefetching a lot of data, is also a good way to structure your app. It leads to better User Experience in the app if implemented correctly. If you start relying less on On-Demand connections in your app, you can separate UI code and Network code much more easily, which speeds up the UI and enables/improves offline functionality. Doing it in an IntentService on Android also allows for implementing very specific scheduling strategy.
deleted 13y ago
[deleted]
kintamanimatt 13y ago
Respecting known limitations and working within best practices is absolutely not premature optimization. If you know that using the mobile radio in a certain way is a source of excessive battery usage, it's silly to just disregard this information. It's not premature optimization if you know where the performance issues are from the outset, and these performance issues are so incredibly common that the Android team put out videos about them. The mobile radio will eat your battery very quickly, and probably chews through as much power as your screen. If you want to see how expensive it actually is, disable fast dormancy†. A slightly less brutal demonstration can be had by opening an OpenVPN connection. The keep-alive packets will keep your mobile radio in a higher power state, pretty much in the same way some disrespectful apps do and you'll (quite unsurprisingly) see your battery drain faster. A badly written app can drain hours of battery charge, not minutes. > Your users will be better served by you fixing bugs or adding features. Excessive power drain is undoubtedly a bug. I absolutely love apps that respect the fact I want to go as long as possible without charging my phone. I might often be in a position where I can't charge my phone too. (Carrying a second or third battery is useful, if you've got a phone that has a replaceable battery.) > Really, unless you're a huge team with a huge budget... It's quite trivial to think about performance and battery life. This is something every mobile developer should be thinking about from the get-go anyway, and if you can't afford to write an app that performs well, you can't afford to write an app. > Making battery usage the prime concern for most apps is overkill. I'll uninstall apps that I identify as too power hungry without a second thought, and I'll also write negative reviews too. I'm pretty sure that when put in this light, power consumption suddenly becomes important. -- † Don't do this. Some phone networks are misconfigured and may fail to ever recognize that the phone is FD-capable again.
- dllthomas 13y ago
  It's premature optimization if you're caring about this in your prototype. It's not at all premature optimization to look at battery life before you ship.
  - timthorn 13y ago
    There's no such thing as a prototype. The design decisions you make early on will stay with you. How you treat "occasionally connected" users is likely to have some architectural impact. Keep their requirements in mind as you sketch out your application.
rjzzleep 13y ago
i would like to place a bet that these measurements are made in an environment where the only app running is your own. that said, this is hardly new knowledge. or is it? i thought there had been articles about it a couple of years back, and even though i would consider this advanced common sense there is a high chance that i would take this optimization into account right away.

ultimoo 13y ago

Maybe a good mobile app can determine its optimization/ux strategy depending on what level the battery is currently at. I am not sure whether apps can query for battery levels though.

canthonytucci 13y ago
At least on iOS you can indeed. It's available from UIDevice. And if you're doing something that sucks up battery, you should know about it and act accordingly. If you're not doing heavy lifting, It's just not something you should have to think about as an app developer, there are so many other areas to focus on to keep users happy. Apple has a few WWDC sessions that talk about it I think. Here's what they have to say in their "performance tuning" section: https://developer.apple.com/library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/PerformanceTuning/PerformanceTuning.html#//apple_ref/doc/uid/TP40007072-CH8-SW1 https://developer.apple.com/library/ios/documentation/iphone...
- king_jester 13y ago
  The dev bytes cited in the article are specifically focused on Android development. Android provides some interesting framework classes that help with making requests efficiently to the network, both from a power and speed standpoint. A lot of these APIs are really underused (e.g. SyncAdapter) in apps right now, so Google clearly wants more devs to use it since it requires less thinking.
ProblemFactory 13y ago
They can. A number of well-built apps pause background data sync if battery is too low. However, changing behaviour based on battery level is trickier than it seems. * The point of reducing energy usage is to leave the user more juice for the actions that are most important to them. It could be that your app is the important one. * Stopping expensive operations at 20% or 30% battery level means that 70-80% was already wasted. If there are good ways of optimising energy use, they should be applied at all times, and prolonging the time until you reach 20%. * The appropriate threshold depends on what the user imagines doing for the rest of the day. If I'm travelling to another city, I disable background data in the morning to make sure I still have battery left for phone calls in the evening after heavy use of maps during the day. If I'm travelling to the office, it doesn't matter, since a charger is nearby. Predicting "time to next charging" and "use of other apps before charging" automatically for context-aware app behaviour is non-trivial.

droopybuns 13y ago

Lunacy is too strong! I think the average mobile app developer has no business thinking about radio optimization. They should however be spending lots of time thinking about cacheing and minimizing interaction with servers. Developers in general have gotten too comfortable with unnecessary traffic on Desktop machines. There are too many devs who have been focused on speed as the limiting factor for mobile apps, when it fact should be cost. The end user is paying not only to acquire your app, but also to use the mobile provider's transport. We should take every opportunity to reinforce the importance of minimizing mobile traffic to only what is necessary. Just because you can use a 4G connection to move a ton of data doesn't mean you should.

cbhl 13y ago
It seems like lunacy to me to use a smartphone on a connection where you're charged using usage-based billing. My provider throttles me when I'm over my "cap"...

hyperpape 13y ago

Prefetching is often an element of a pleasant user experience. It also can bring difficult UI problems with it (when is information too stale to display, etc), but that just means it's not easy. It feels like so many apps are designed by people who never have experienced a bad connection, and just assume that their app can download everything it needs quickly as soon as it starts up. What you end up with is bad experiences when your connection is slow or has high latency.

ianstallings 13y ago

I disagree because there are fundamentals, highlighted by the author, that a lot of experienced mobile developers know already through trial and error that should be acknowledged up front. For instance, doing single calls to APIs for multiple pieces of information instead of a bunch of calls. If you design for these up front, you can then head the problem off before it even becomes a problem. It's not premature because users expect it. They do notice network lag, they do notice battery usage, and they will give you one star on the app store or play store, etc. I've literally seen this play out in real life. It's no different than making sure your website loads quickly IMHO. You still have to do all those other things you listed to worry about, but this isn't to be glossed over and addressed when you realize people are noticing.

mtrimpe 13y ago
Indeed. This isn't about premature optimization, but about preventing the equivalent of what I've seen happen when you give desktop developers GWT and get a public facing website with a 3 MB JavaScript app that polls a hard to generate 5k document every second just to check if a posted job has completed or not.

timthorn 13y ago

Modern phone batteries last a fraction of the time they used to - you could get phones with 2 weeks life in the days before smartphones. We've got used to short lives but devs should aim to keep power demands down. Radio power consumption is very significant. It could well be more than the screen takes - it's not just the RF amplification, but also the computation required to generate the modulated RF in the first place.

miratrix 13y ago

The difference between DCH (the full-on high power state) and PCH (the lowest power, waiting-for-paging state) is about 2-orders of magnitude. Last time I measured, it was about ~100mA vs ~1mA (at ~3.7V) used by the radio. So, it's not couple of minutes of battery life, but rather _many_ hours of standby life instead. People usually aren't very happy when a fully charged phone dies overnight. I've seen apps do some crazy things and it really has a significant effect in over-all battery life. A popular Android weather clock widget woke the phone up every minute to update the minute number on the graphics and updated the weather information every ~15 minutes (gps + radio!) which single handily crushed the standby battery life from multiple days to less than 8 hours. Yes, I don't think _every_ decision should be based on minimizing the wake ups... but on the other hand, all developers should at least try to have as much understanding of the platforms that they're working on so that they know what trade-offs they're making with each feature they're adding. I'm glad that Google has these videos available and that they're being picked up in places like HN.

vacri 13y ago
Anecdata: I turn my phone's wifi off when not required because it has a significant effect on the battery life - particularly when I'm not in range of a wifi signal. I've had a full charge die on an 8-hour country drive because wifi was on. On the return trip, wifi was turned off and it behaved as expected. Go for a long walk in the park? All that time your phone's wifi is straining to find a wifi signal. It's not as big a power sap as the screen, however it's constantly, silently in use and the screen isn't.
- miratrix 13y ago
  Wifi scanning is also pretty terrible for power consumption as you found out. If you are on Android, my guess is that your phone was set to be connected to Wifi during sleep. You can control it by going to Wifi networks section -> menu -> Advanced -> Keep Wi-Fi on during sleep, then setting it to "Only when plugged in" or "Never". If you're driving around with the phone set to leave the Wifi on during sleep, it'll be constantly going in and out of range of various Wifi connections. If the Wifi part is set for passive scan, then the processor needs to be kept up as the Wifi chip attempts to collect the BSSID of all the network it see and processor tries to figure out whether these networks have been seen or not. If it's set for active scan, then the Wifi needs to power up the radios to transmit beacons. Pretty bad news in either case, unfortunately.

zyb09 13y ago

Not only are you helping the battery, but prefetching a lot of data, is also a good way to structure your app. It leads to better User Experience in the app if implemented correctly. If you start relying less on On-Demand connections in your app, you can separate UI code and Network code much more easily, which speeds up the UI and enables/improves offline functionality. Doing it in an IntentService on Android also allows for implementing very specific scheduling strategy.

deleted 13y ago

[deleted]

kintamanimatt 13y ago

Respecting known limitations and working within best practices is absolutely not premature optimization. If you know that using the mobile radio in a certain way is a source of excessive battery usage, it's silly to just disregard this information. It's not premature optimization if you know where the performance issues are from the outset, and these performance issues are so incredibly common that the Android team put out videos about them. The mobile radio will eat your battery very quickly, and probably chews through as much power as your screen. If you want to see how expensive it actually is, disable fast dormancy†. A slightly less brutal demonstration can be had by opening an OpenVPN connection. The keep-alive packets will keep your mobile radio in a higher power state, pretty much in the same way some disrespectful apps do and you'll (quite unsurprisingly) see your battery drain faster. A badly written app can drain hours of battery charge, not minutes. > Your users will be better served by you fixing bugs or adding features. Excessive power drain is undoubtedly a bug. I absolutely love apps that respect the fact I want to go as long as possible without charging my phone. I might often be in a position where I can't charge my phone too. (Carrying a second or third battery is useful, if you've got a phone that has a replaceable battery.) > Really, unless you're a huge team with a huge budget... It's quite trivial to think about performance and battery life. This is something every mobile developer should be thinking about from the get-go anyway, and if you can't afford to write an app that performs well, you can't afford to write an app. > Making battery usage the prime concern for most apps is overkill. I'll uninstall apps that I identify as too power hungry without a second thought, and I'll also write negative reviews too. I'm pretty sure that when put in this light, power consumption suddenly becomes important. -- † Don't do this. Some phone networks are misconfigured and may fail to ever recognize that the phone is FD-capable again.

dllthomas 13y ago
It's premature optimization if you're caring about this in your prototype. It's not at all premature optimization to look at battery life before you ship.
- timthorn 13y ago
  There's no such thing as a prototype. The design decisions you make early on will stay with you. How you treat "occasionally connected" users is likely to have some architectural impact. Keep their requirements in mind as you sketch out your application.

rjzzleep 13y ago

i would like to place a bet that these measurements are made in an environment where the only app running is your own. that said, this is hardly new knowledge. or is it? i thought there had been articles about it a couple of years back, and even though i would consider this advanced common sense there is a high chance that i would take this optimization into account right away.