Sustainability and mobiles

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.

However, with the rise of “good” JavaScript there has been an invasion of developers and more importantly, developer attitudes that try to make the web into a desktop app. From the user perspective, this is good, but what these developers are doing is applying programming techniques and strategies suitable to desktops onto the web, where a client/server mix is better. If the client is “too heavy,” as is likely with many of the new JS frameworks, you’re almost guaranteed to drain that battery life.

One can wonder if this is a case of code “lock-in.” As discussed in the last couple of posts, “lock-in” happens when early decisions in development of software dynasties create limits in future software. In this case, software ideas formed at the Windows 3.1 stage are now invading the web, using JavaScript as an equivalent of the old 1980s PC languages. The addition of “modern” programming techniques has been good for the web, but it is possible that client-side apps are going too far – and mobile apps which “store state on the client” may be the canary in the mine warning us of declining sustainability.

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!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s