I’ve been working on an android application for a Special Topics class here at UMich. I chose the android platform for the app, because it offered me one great asset: background processes. I had to give up the much larger user base of the iPhone just for this. (Well, there’s also the fact that android is open, java based etc etc etc).
It’s now coming to that time of the semester when I’ve got to stop procrastinating and get started on the app. I now also have an Android Dev 1 device to play around with. So with all of that in mind, I decided to do get to work. First, I wanted to see how well background processes integrate into the android framework, so I downloaded a few generally useful applications to test this. I tried: meebo (for IM), and twidroid (for twitter). I very quickly found that these apps integrate into the android system beautifully. They use the notifications area to display alerts and also use the phone’s vibrate/LED/ring tone features to alert me. I was very encouraged by this. That’s when I hit the snag.
Most of my testing was being done at home and on campus (which is where I spend all of my time). Both places have access to Wifi networks, and therefore I was using those instead of the much slower EDGE network (no T-Mobile 3G in Ann Arbor yet). The result was that the first time I pulled the phone out of my pocket to make a phone call, the battery level was critically low. I was pretty shocked by this considering that I’d charged the phone overnight, and it had been on for barely 2 hours. Initially I thought this was a one off thing, maybe the charger had been unplugged accidentally or something. But, turned out that was not the case since it happened 3-4 times repeatedly. That’s when I thought it was because I was using Wifi all the time. So, I turned off the Wifi and started using EDGE instead. This helped significantly. The battery life went up to roughly 4-6 hours (keep in mind that I’m not much of a cell phone user – I made/received approximately 1-2 calls in each period). Still, this was really no good (who charges their phone every 4-6 hours).
Having seen this I started playing around with the apps themselves. Meebo pretty much has to run continuously and use the network. I thought this might be the root cause of the problem and turned meebo off. I also set twidroid to look for updates every 1 hours instead of every 5 minutes. And voila! I haven’t charged my phone for over a day, and the battery level indicator is still showing well above 50%.
This led me to the following belief: running background processes on a cell phone is simply *not* a good idea. The drain on battery life that it poses is absurd.
As if to prove me right, Apple said the very same thing at the preview of iPhone OS 3.0. They said that background processes reduced battery life by roughly 80% even if the phone was not being used. They cite this as their reason for using push notifications instead. I think they’ve got it absolutely right on this one. While it’d be amazing to have background processes, as things stand, they’re of no real value. I’d much rather have push notifications.
Afterthoughts:
1. It’s pretty obvious that push notifications are a better way of doing things (given current technology). But, there are some uses of background processes that push notifications can’t handle. It turns out the app that I’m building is one such use. What if you need to constantly receive the phone’s location (via GPS, say)? There’s no way you can do that with push notifications. If you know a good solution to this problem, please let me know :)
2. I didn’t mention earlier that the android system keeps your contacts, gmail and google calendar in sync (almost instantaneously). I also have the phone set up to receive my UMich email via IMAP (also almost instantaneously0. Somehow, this doesn’t seem to drain battery life at all. Is it just the case that the applications I chose are badly written?
- Sir Lapog Kahn.
Maybe meebo tries to pull from the server that much more often than GMail or your UMich Mail clients? Given that these processes are hogging most of your battery life, even a half as frequent pull would result in half as bad battery life.
ReplyDeleteRegarding the GPS system, I can sort of think of a workaround:
1) If you're constantly changing location anyway, Push/Pull are not going to make a difference to your battery life, because the notifications will be as frequent in both cases.
2) If you're going to be stationary intermittently, the phone can pull its new location only when it needs to. One way to do this would be to use a motion sensor. Only when the sensor thinks it might have changed coordinates, it should pull its location. The iPhone's accelerometer could possibly be used for this.
These should be completely unnecessary hacks; I'd argue that the device should be enforcing this constraints, and not crappy programming. Why should the user have to suffer for subpar optimization practices? iPhone got this one right. Bye bye, android.
ReplyDeleteBy the way, as far as GPS is concerned, the device's *default* mode of operation should be to pull more frequently when you're in motion, and pull less frequently if you're sitting down or something. This should not have to be hacked in by the applications programmer.
ReplyDeleteMotion sensing wouldn't work at all. For instance, me getting up from a chair, or swiveling around to look at someone else's screen would trigger the motion sensor. This would be a terrible waste.
ReplyDeleteI also agree that push vs pull won't make a difference. But, what Apple does right is how they push. They maintain one connection to their servers for all notifications. On android, each background process maintains its own connection, thereby worsening the situation a lot.
I also agree that the device should somehow enforce these constraints. All this while I kept thinking Apple had it absolutely wrong to not have background processes. After having seen this, it's obvious they did the right thing. Bad apps would have completely butchered the iPhone.
-Sir Lapog Kahn.
I'm not a programmer, but I know that Symbian allows some background processes and in my limited experience (I have a Nokia 5800) the battery life is still decent. Any idea why this might be?
ReplyDeleteHard to say whose fault this is, but as a point of reference, my Nokia E71 will run the IM client, VOIP client, mail, play podcasts etc and I get a couple of days between charges.
ReplyDeleteI now have a larger batterie for my G1 and it now keeps alive nearly two days and longer than my iPhone today, although I have Twidroid running the whole day. It's a matter of time till we'll see better batteries and an improved Android system, and then Android still will have background processes. We are talking about the version one of Android. Please compare Java's first version to where it is now.
ReplyDeleteOliver
It must be the case that the applications you chose are poorly written.
ReplyDeleteI can guarantee you that the iPhone has "background processes" whether or not you see them. So does S60, Android and any other non-trivial system. In all modern operating systems, if a background process isn't doing anything, it won't cause measurable power consumption.
The processes you tested were most likely polling something or keeping some of the phone's hardware powered up.
So you damn all background apps on the basis of meebo and twidroid? Nice sample size :-)
ReplyDeleteBackground apps work perfectly well on Symbian without seriously killing battery life, so it's certainly do-able.
The difference is that I can buy a bigger battery. That's where the G1 got it right.
ReplyDeleteBackground processes != High network usage
ReplyDeleteYour article fails.
My Symbian series 60 phones have had background processes for a long time. I don't see any battery drain or anyone complaining about battery drain on nokia phones. If background processes are disallowed I don't understand how you would use your phone in real world. Sometimes I wrote small notes (like MAC addresses in the lab, phone numbers, ID numbers for satellite TV and what not in the notes section). I then have to read it out someone while talking to them on the phone. With my Series 60 phone I can switch to standby screen and go to notes and read it out all the while making a call. I can be composing a message and copy and paste from the notes, or office documents. All this wouldn't be possible with background processes. A phone without background process support would be unusable for me. I would say stop trying to cure stupidity.
ReplyDelete@Anonymous
ReplyDeleteSeveral of the Apple applications (phone, SMS, mail) run in the background. If you are on a phone call, you can switch to other applications and still keep the line open.
Nokia/Symbian: I talked to my father about this (the only person I know who uses a Nokia phone), and he says that his phone can go around 3 days without a charge even with similar background processes running. So obviously, Nokia has figured it out. I'm also willing to bet that his phone's battery is more powerful than the one in the G1. It's also the case that the only apps he uses are the ones built into the phone.
ReplyDeleteiPhone: iPhone OS only allows Apple's processes to be backgrounded. I'm not sure how Mail works, but SMS and Phone are certainly interrupt driven. Doesn't that make a significant difference?
I also realize that running 2 apps on android for a couple of days and concluding that background apps are doomed to fail isn't a bright idea. That's not what I intended to convey. However, I do believe that there is a valid concern here. It's going to take some effort to get things going right, and apparently meebo (and I think the people over at meebo are pretty good software engineers) couldn't do it.
Background processes != High network usage - good point. Didn't think of that.
I'm not saying background processes are all bad. The ones that were mentioned in the comments (copy pasting from notes when on a phone call, etc) aren't intended to run forever. You won't be copy pasting notes when talking to someone for more than 10 minutes (or maybe you will, but compared to the battery drainage caused by the phone call itself, this won't be significant). Also, copy pasting etc, isn't going to take much processing power. Something like meebo however, has to run all the time. This seems like a different ball game to me...
-Sir Lapog Kahn.
The problem isn't background processes, it's processes that continually do stuff, especially go out over the network to poll for updates ("pull"). The solution, as you mentioned, is to push. Less network traffic and (hopefully) more time in some sort of sleep mode -> less energy used.
ReplyDeleteThere are reasons to allow background processes (makes it easier to keep state when switching back and forth) and reasons against (more memory used), but when well designed, background processes should make little difference to your battery life.
The problem with a push model is that something needs to do the pushing, so either you set up your own batch of servers to support pushing bits to the device (a major headache), or whatever service you're using has to already provide it. The benefit is that you can see changes "as they happen" (though you might still want to batch somewhat for heavy traffic services).
For pull you "just" need to figure out a good trade-off between being out of date and draining the battery.
I use a Nokia 5800, and what I've seen so far is that the WiFi seems to drain the battery a lot faster than anything else.. I've used the phone to TV/OUT an entire 2 hr movie, and even that didn't hit the battery as much..
ReplyDeleteMaybe some sort of standard library support for applications that want to check for periodic updates would be good. This way, you could set up an interval for the whole system, and allow applications to specify multiples of that interval to check for updates. This way, the system could wake up at the same time for all programs that want to do periodic updates, so the system would only wake up once per interval, instead of number of applications that receive updates times per interval.
ReplyDelete@Dharampal: I agree that WiFi is a major knock out. The key to having WiFi on cell phones (I think) is to minimize its use to a bare minimum. WiFi has severe impact even on much more powerful laptop batteries... Surely it has to hit cell phones much worse.
ReplyDeletePlatform support for processes that run periodically seems like a really good idea. That would ensure that the network devices go on only as long as they need to, without paying the overhead of turning them on/off several times... Maybe this is actually built in somehow, and I'm not aware of it?
I have to agree that it's not that it's background processes themselves but what you do with them.
ReplyDeleteI spoke to an Engineer at Apple a couple of weeks ago at a local iPhone developer event (I'm a G1 owner but interested in working on iPhone apps too) and he said the worst thing for the battery is leaving a constant connection open, or using a connection too much. 3G and WiFi are a big drain on the battery, more than processes themselves.
The best thing to do is when making a connection is to grab the biggest chunk of data you can then kill the connection, and don't have your app doing it ever 5 minutes - at most you should need to do something every 30mins to 1 hour.
Also constant GPS use will kill the battery too - try to limit to at least 60 seconds or 100 meters between finding locations, and time out the GPS after 30 seconds if it can't get a lock.
I don't even think Apple got it right. I am lucky if my iPhone battery lasts 8 hours on a battery charge merely sitting on my desk. And for this I had to give up on background processes? Sheesh!
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteThere is an interesting presentation about saving battery life on Android [1]. Although the problem seems last relie on developers it should be a problem of battery/hardware manufacturers.
ReplyDelete[1] http://code.google.com/intl/es-ES/events/io/2009/sessions/CodingLifeBatteryLife.html
This is nice post!! thanks for sharing with us. Its really helpful for me and this link
ReplyDeletehttp://mindstick.com/Blog/254/Background%20Processing%20in%20Android
also beneficial for me.