Screebl Power Saving Study Results Print E-mail

Recently, the Android Guys published a review of Screebl.  At the end of that review they mentioned that they planned to do an evaluation of my claim that Screebl can save power under common usage patterns.  Well, Android Guys have yet to follow through on their evaluation, but I've been meaning to do a study myself for some time now, and I've finally gotten around to it. Here are the results...

First let me describe how I went about doing my evaluation.  I tried to keep things simple, and as with any benchmarking endeavor simplifications are always controversial.  I'm not trying to sell you anything here though.  I really am just curious about what Screebl can do.  Let me know if you have issues with how I've done the evaluation.   UPDATE:  Actually, I may be trying to sell you something, depending on who you are.  Now that ADC2 is over, I'm  trying to convince hardware manufacturers to bundle Screebl technology with their products.  In any case, here's what I did:

Prepare phone for battery-drain test.

  • Fully charge my HTC Dream (T-Mobile G1) to 100%. 
  • Kill all non-essential background tasks (e.g., Facebook, gmail, sportstap, etc.).  I did this with the application Task Manager v 1.10.4.
  • Place phone in "Airplane Mode".  This makes the evaluation consistent regardless of what the cell signal strength happens to be, and also avoids the possibility of my wife calling and invalidating the test.

 

  1. Baseline Test
    • Prepare phone for battery-drain test, as described above.
    • Eliminate screen timeout.  Set the screen timeout to "never".
    • Let phone sit (with screen on) for exactly two hours.  This was accomplished by using the Stop Timer application.
    • Start the application Spare Parts and measure remaining battery power level.
  2. Screebl Test
    • Prepare phone for battery-drain test, as described above.
    • Enable the Screebl service, and place phone statically within a configured orientation range.
    • Let phone sit for exactly two hours.  Again, used the Stop Timer application to measure.
    • Record remaining batter power level as reported by Spare Parts.

My assumption was that there would be some overhead to run Screebl's background service.  This overhead would be estimated by the difference between the Screebl Test and the Baseline Test.  Put another way:  ((BaselineTest - ScreeblTest) / BaselineTest) = ScreeblOverhead. Doing an absolute battery level test like this seemed the most reasonable method of determining Screebl overhead.  I came to this conclusion because Screebl uses sensor input, and subscribing to sensors may result in new system threads being created to handle delivery of sensor values.  These system threads may not be easily attributable to Screebl in something like a profiler.  In any case, it turns out that Screebl has an overhead of somewhere between 2% and 5%.  I was surprised at how low this was.  It seems like low-frequency orientation sensor subscription is not all that battery intensive on the HTC Dream.

With this information in tow, I was able to start running some scenarios.  Let me describe my assumptions:

  • ASSUMPTION: The phone only consumes battery when the screen is on.  Now I know that this isn't true.  But as far as Screebl is concerned, Screebl is only consuming battery power when the screen is on.  When the screen turns off, Screebl suspends all background threads, and they remain dormant until the screen is turned back on.  It also makes calculations a lot easier.
  • DEFINITION:  Average User Activity Time.  This is the average amount of time that a user interacts with the phone after turning on the screen.  For example, the time that elapses between when a user unlocks the phone, checks his email, and then sets the phone down is an example of User Activity Time.
  • DEFINITION: Average Screen Timeout.  This is the average amount of time that transpires from when a user stops interacting with the phone, until the phone's screen is turned off.  The screen may be turned of automatically or manually.

The graph above depicts UserActivityTimes varying from average values of 1 minute to 10 minutes, with a fixed average ScreenTimeout.  Screebl is all about reducing the average screen timeout.  So obviously users that have fairly short average UserActivityTime, but have a high average ScreenTimeout are going to benefit greatly from Screebl.   Notice that in the top bar of the graph above, the light green portion of the total bar length (representing the screen timeout) makes up two-thirds of the total time that the screen is on.  As the graph at the top of the page indicates, the savings can be as high as 55%.

In conclusion, let me point out a few obvious things.  First, these results are likely to vary wildly on different hardware.  Vendors optimize battery usage in very different ways.  In support of this, I have recieved wildly varying anecdotal reports from users of Screebl that claim anywhere from a doubling of battery of life, to mild savings, to this sucks, I hate you, and I hope you die.  Second, I was happy to see that even if your usage pattern is such that Screebl doesn't provide huge power savings, there is not likely to be huge power loss in any scenario.  Put another way, you can enjoy the benefits of Screebl without paying dearly in power consumption.