Mobile systems define a special area for sustainable design. While desktops are plugged into the power grid, and draw power as needed, mobiles have batteries with quickly run down (always faster than the reported values). So mobiles are an microcosmic system where sustainability is confined in an area a few inches wide.
What are the issues with mobile sustainability, specifically Web Performance (WPO)? Despite the power constraints, programmers have increasingly treated mobile dev as something more like standard software programming. Current frameworks (e.g. Phonegap) try to build a code-heavy “app” that uses huge gobs of code to maintain itself. The model is a client-side application that occasionally communicates with the server.
The problems with this approach were recently summarized on the “High Scalability” blog:
The source videos from Android Developer Reto Meier
In regular web traffic, we worry about HTTP requests. Each time our web page makes a new request to the server, there is a energy-intensive revving-up and revving-down of the network, client, and server communication system. These days, most developers and many designers are aware of this problem, and they design accordingly, using stuff like CSS sprites, Base64-encoded inline images in HTML and CSS, and consolidated scripts and stylesheets.
The problem with cellphones is even more acute. Cellular radio communications (it is just a kind of radio, not magic) don’t function like WiFi or wired network protocols. Instead, they are a sort of “super HTTP request” requiring extensive power-up and power-down sequences.
According to the High Scalability site commentary on the video, each cellphone network request jumps through the following states:
Begins in Standby mode where it draws minimum power until an app initiates a data transfer.
To send data the radio transitions to Full Power mode, a process that takes 2 seconds before performing the transfer. It will remain in full power mode for a set tail time just in case more data needs to be transferred. This avoids the ramp up time to Full Power state. State transitions themselves are a significant power drain so need to minimized.
If nothing happens in a 5 to 10 second tail state it transitions to an intermediate Low Power state where it uses less power and has a shorter transition time to Full Power.
If nothing happens for another 30-60 seconds it will drop back down to Standby.
Exact latencies and tail times vary by carrier, network, and device.
If you’re running a web app that occasionally (e.g. once every few minutes) updates via a polling, (e.g. weather, time, or other streaming data sources) you repeatedly fire up and fire down this energy-hog system – the worst-case scenario. Consolidating media and avoiding multiple requests, especially when spaced over time, is even more important to mobile development.
How can this be fixed? Some solutions reside in the design
- Design for sites which do occasional “bursty” updates instead of polling
- Don’t follow lame desktop apps and put in a “refresh” button for the user. Do refreshes intelligently
- Pre-cache likely data – it is cheaper than trying to be efficient and firing off a log of radio on/off states
- When the battery API becomes available on browsers, use battery state to decide on download strategies
Another problem with client-heavy, polling sites which resemble old desktop programs is social. Mobile programmers of ancient days (e.g. 2006) were very careful to keep their stuff lightweight, and balance the thin client with necessary server services. As has been discussed elsewhere in this blog, server bits are generally “greener” in their manufacture than client-side bits.
As a side note, it is interesting to look at “app power drain” on systems. A group at Purdue University did exactly this last year, with their eprof system. The found that free apps tend to use most of their energy in user tracking, regularly reporting their results. This makes free = battery hog in the mobile world. The researchers noted that app design could be restructured, and showed examples with savings from 20% to 65%. Apparently, this hasn’t dented the excitement about re-creating the old inefficient desktop on your mobile via mega JS frameworks!