Raj Advani

We’ve been working a lot recently with the Android NDK. The NDK allows you to write native code for an Android device, allowing you to bypass the Dalvik VM and write directly to the platform. Now, we already have a functioning version of our app written in Java, so why did we put in the effort to port it over? Speed, of course. For those facing a similar decision, here are three things we’ve learned:

1) The Dalvik VM is slow for CPU heavy applications. Slow is a relative term. For your average “tables and text” application, it’s more than fast enough. But if you want to write applications with heavy CPU usage, then you’re much better off with the NDK. Specifically, we found that the Dalvik VM really suffered when running highly recursive algorithms: the method call overhead was unacceptable. Now, you could eliminate a lot of this method overhead via public fields and manually inlined code — but if you’re going to go that far, you may as well write the thing in C++. Note that this applies even to the newest crop of devices (Nexus S) with the latest operating system (Gingerbread).

2) Garbage collection kills frame-rates. Again, not for tables and text applications. But if you’re writing a game or anything with a tight, optimized render-loop, you must avoid generating any garbage. Unfortunately the Android SDK spills metric tons of it: Android internal classes aren’t written with optimization in mind, they’re written for ease of use. The IO classes freely allocate and discard byte arrays and can’t be re-used, and the NIO classes — which are as optimal as the SDK gets — are almost as bad. So even if you write your app efficiently, merely using basic SDK classes will produce significant garbage, eventually triggering the Garbage Collector and pausing your app, producing stutter. Using the NDK avoids this problem.

3) NDK libraries are extremely limited. This is gradually improving, especially with NDKr5, but for now you’re fairly constrained in what you can do. You get the standard C libraries and support for STL. But if you want to do something high tech, like, say, send an HTTP request, you have to learn your BSD sockets and write 100 lines of code. Or you could download the Android source and compile libcurl, which is perhaps even more of a pain. That said, there is one other alternative: JNI. For advanced functionality, JNI enables you to uplink to Java, do things in the SDK, then return the results back to the NDK. We do this a lot, and it works quite well — except, of course, it generates a lot of garbage.