Hacker News Reader

Comment by nwhitehead | Hacker News Reader

Do you have any case studies showing what the actual overhead is? I love the idea but would worry about negatively impacting the customer experience.

View on HN

CPU-wise, our SDK adds up to 2% overhead to normal UIEvent-handling. This is with frantic and constant user input - in practice the overhead is much less.

Network-wise, we batch user activity and by default make a network request every 5-10 seconds. We'll expose a config variable so devs can tune this frequency on a per-app basis.

You're keeping the WWAN/WiFi interfaces awake, which burns a significant amount of battery, just because you want to gather data from the user.

On top of that, burning 2% overhead on UIEvent handling (which also impacts battery).

What a waste for something that users don't actually want you to be doing in the first place.

Keeping network alive like this is not cool - the radio will drain the battery. It would be much better to not only allow a configuration for how often the sync happens, but also allow the app to manually trigger sync, normally at the same time as other network activity is going on so that no extra power is spent bringing the radio up and down.

This makes total sense! Manually syncing is a good idea.

We need to make sure we have reasonable defaults in place, though, and so far, we've had no issues from our beta testers.

Steady small but spaced updates is just about worst case for battery if you're on 3G. You want relatively large batch sizes so the system can turn the radios off and keep them off. Obviously doesn't matter if the main app is using the radios...

There is an excellent guide on the Android site covering this: http://developer.android.com/training/efficient-downloads/ef... (and it really applies to iPhones also)

How much does it affect battery life ?

I would imagine 2% extra CPU plus frequent network connections would add up to a lot of extra battery drain.

Reply on news.ycombinator.com