Tag Archives: g1

Benchmarking Protobuf vs JSON parsing in Android

I have a bit of an addiction to benchmarking. It must be because I’m a PC gamer (yes we still exist). Actually it’s probably more of an addiction to tweaking every last ounce of performance out of something. Recently I learned how to get to the protocol buffers version of the Google Reader API. Protocol buffers is a Google’s own binary message format that they open sourced a while ago. The messages have no field information in them so they are potentially smaller and faster to download and parse than JSON. After some guess work to parse the messages properly I set up my G1 (Android 1.6) to alternately download JSON and protocol buffers versions of the unread counts list of my Google Reader account on Wifi. It turns out that as long as jackson is used to parse the JSON there is hardly any difference. Protocol buffers took an average of 127 milliseconds to download and parse an unread count (there is one count for every feed or tag with unread items in Reader). JSON took 133 milliseconds. I think this is because JSON responses are gzipped so they are fairly compact anyway and also jackson is screamingly fast as a parser. As protocol buffers messages are binary there is no need for the Reader API to gzip them (although some fields in them are plain text strings). I used the “Lite” version of the protocol buffers jar file which is supposed to better for mobile devices.

For now I don’t think its worth the risk to migrate to protocol buffers. These benchmarks aren’t comparable to my previous ones which hit a different part of the Google Reader API. I might revisit downloading headlines with protocol buffers at a later date. The larger size of the headlines responses might show more of a performance difference between to the two message types.

On Android Fragmentation

During development of the SMS Bot Widget I encountered some issues with running it on the different versions of Android. The SMS API changed in Android 1.6 and the contacts one changed in Android 2.0. Coding for 1.6 and then attempting to run it on 2.1 meant that some nasty bugs cropped up such as not all contacts appearing in the configuration screen. In order to make the code run on everything from 1.5 up I had to use reflection.

Catering for multiple OS versions is part of the problem with fragmentation of Android but at least it can be worked around. If APIs change or new features get added, applications can still be written to run on old versions whilst utilising the latest functionality. It takes more effort but its worth it in order to have such a rapidly evolving platform. There have been 6 new versions since the T-mobile G1 was launched in the US in October 2007. As a developer I like getting my hands on new toys to play with.

However, as an Android phone buyer fragmentation is confusing and frustrating. New devices are being announced all the time running anything from Android 1.5 to 2.1 with different custom UIs. Customers can’t be sure when or if they will get updates for a device in the future. Also devices get released so quickly, that even a few months after release they’re outdated. I suppose these are the prices we pay for choice and rapid progress.

Benchmarking JSON vs XML Parsing in Android revisited

In my previous post on this I mentioned that parsing the Google Reader XML (Atom) feed with SAX was faster than parsing the JSON stream with json-simple. However, this is no longer the case thanks to jackson which is used in the Reader Widgets from version 2.3.
On my HTC G1 running Android 1.6 (donut) it takes an average of 157 millisecs to parse and store a single headline. For SAX it takes 207 millisecs. This means about a 24% overall speed improvement in processing headlines from V2.2 to V2.3. Also, as mentioned before, the amount of data downloaded is also about 25% less for JSON.

It has always annoyed me that the large widget wasn’t using the JSON stream for headlines and now that it is I’m much happier!
Big thanks to Tatu over at Codehaus for handling invalid JSON strings that cropped up in my Google Reader stream (jackson 1.4.)

Dear Santa…

… I’m not asking for anything for this Christmas but for next year I want the perfect Android phone to be released. Maybe a keyboardless Droid, maybe the Nexus One, Two or Three (or six?) but with the following:

  • 3.7 inch 854×480 screen
  • Decent camera with:
    • Flash (xenon if possible)
    • Physical button that can be half pressed for focus
    • 720p video recording
  • Running stock Android 2.x
  • Physical buttons on the front for home/back etc
  • Trackball
  • Decent amount of on board memory (1Gb+) for apps
  • 802.11n Wi-fi if possible

Although my next phone will probably be a stock Android 2.x device, I’ll still install the HTC Hero keyboard on it.

Senseless Sense

Don’t get me wrong I love my HTC Hero and it’s Sense UI. I just don’t like the fact I have to wait longer for Android updates compared to other phones. I’m sure when Eclair comes to the Hero it will be great but I just can’t stand missing out on all the new apps that have come out for 1.6 and above like Google Goggles and the new Maps. I can try them out on my G1 with Donut but I’m not lugging that around with me too.

By the way, I just updated my Hero to Modaco 3.0 and it feels a bit faster.

I think my next phone will be a stock Android 2.x device, perhaps the Nexus One that’s been causing such a storm. That way I can get updates much faster.

Reader Widgets and Android 1.6

I have installed the official Android 1.6 (aka Donut) ADP build on my G1. I’ve done some initial testing and found that both Reader Widget Small and Reader Widget Pro work on it. I have also uploaded screen shots for both to the market (only visible in the 1.6 version of the market). PubCrawler still works too. Now where is my Android 1.6 build for my Hero, HTC? :)