Android Optimization

Since the Android platform uses the Java programming language and, at a high level, seems to support a large portion of the language, it is easy to forget that one is still developing for an embedded device. I am, by no means, an expert -- in fact, this is my first foray into the world of embedded programming but there is no harm in outlining the little bit I've learned if it has a slight chance at helping someone else. This is the first platform on which I've really had to think of "micro" level optimizations (rather than macro, algorithmic optimization). It definitely adds another dimension to the analysis one must undertake when attempting to solve a problem.

To understand the best way in which to write Android programs, one first must understand a bit about the virtual machine at the heart of the system: The Dalvik VM. I won't go into details about the internals of the VM, but suffice it to say that the fact that it is made to run on devices with limited memory and CPUs, the compiler makes some choices in bytecode generation that differ from those that would be made by Sun's compiler.

In starting development on my Android project, I came across this page on the developer resources site. While the page listed a number of things that I would not have even thought of -- the way in which enhanced for loops, for example, result in the implicit allocation of an Iterator -- I was glad that the first bullet point was "Optimize Judiciously." This advice is probably the most important on the page. They even goes as far as including one of my favorite quotes on the subject:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
—Donald E. Knuth

The dangers of premature optimization are by no means limited to the realm of embedded programming (though they may be even more precarious since some of the optimizations done in this space may seem odd to developers accustomed to working in the desktop world) and I've seen them derail or over-complicate a number of projects in the past. Maintainability and understandability are just as important as correctness when writing software.

Pontificating aside, here is the process I am taking with respect to optimization:

1. Devise the most efficient algorithm for the logic I'm performing: this is no different than I would do on any other platform (just because you have more resources doesn't mean your software should use all of them).

2. Make the "easy" optimizations the first time around: this includes things like declaring variables using concrete classes rather than interfaces, only using the enhanced for loop when an iterator would be needed anyway, etc

3. Make the code as simple and clean as possible: again, this is no different than any other platform

4. Refactor often: this is probably the most important step. At this point, I've refactored so much of the application that I've basically rewritten it twice over. After each refactoring round, the code is cleaner, more efficient and more maintainable. I have paid special attention to the view portion of the code as small changes there can have a huge impact on performance.

There is nothing novel about the approach outlined above. My only point in calling it out is that the sequence is important. I don't start the refactoring phase until I'm sure that the algorithm is correct and the code implementing the logic is as simple as it can be. This helps keep things maintainable. I also endeavor to keep my layers and object dependencies clean. Performance "optimization" is not an license to throw away decades of solid software design principles. Keeping the components well-defined an clean may seem like you're leaving a few more CPU cycles of performance gain on the table but, in the long run, one is probably still better off with quality code that (so long as it performs well enough -- and what "enough" is varies depending on the application) versus spaghetti code that uses the fewest possible CPU cycles.

Android Development

I have recently started programming for the Android platform. This post is the first in what I plan to be a series discussing my experience writing code for this environment. That being said, I'll jump right into it.

We chose the Android platform for our application because it offered a lot of capabilities that we could take advantage of right out of the box (camera for video/image capture, GPS for location-awareness, Wi-Fi and Bluetooth for fast data transfer, etc). The free/open nature of the platform was also appealing. At this point, I've implemented the core use cases for all those features and am now concentrating on improving the user experience, bug fixes, and overall polishing. So far, I have no regrets as I have not yet come across a use case I could not implement in a fairly straightforward manner.

At the risk of sounding like a Google Fanboy, I have to say that I really do enjoy working on the Android platform. The core reason is that Google really put a lot of thought/effort into the SDK and development tools. For Eclipse users, there is an Android Development Tools plug-in that makes building and debugging applications as simple as a single click. Additionally, since Android has gone through a fairly rapid evolution and there is a wide variety of devices running a number of different versions of the OS, the emulator provided with the SDK makes it simple to test different device configurations running differing platform versions. While emulators are great for initial debugging, there is no substitute for running on an actual device. Since the platform is designed to be open, deploying one's applications to a real device is as simple as turning on an option in the phone's settings menu, plugging it into your PC and clicking a button in Eclipse. Again, none of these things are groundbreaking, but having full IDE support makes it much easier to concentrate on the details of the application rather than the nuances of packaging.

That last point applies to a lot more than just Android. Whether it is IDE plug-ins or a life-cycle management tool like Maven, comprehensive tooling makes getting up and running on a project easy. I cannot overstate how much of a difference Maven has made on other projects, especially those with complex builds and many dependencies. That being said, I am planning on trying to integrate Maven with my Android builds using this plug-in shortly (for reasons I'll outline in a subsequent post).