Friday, June 11, 2010

Android NDK

I can’t understand why people don't want to try their hands on NDK. If you are good to c,c++ and basic of java then it is also easy as the SDK. 
Android SDK is great for application development, but what about the native code if you need to access? The native code is usually done in C,c++. While you were able to access native code via Java Native Interface (JNI) all along, the process was rather hard. You would've typically had to compile everything on your host computer for the target architecture, requiring you to have the entire toolchain on your development machine. 
  • Lets familiear with NDK
Android release NDK for developing native application after release of SDK.

Android NDK (Native Development Kit) simplifies working with native code. It includes the entire toolchain needed to build for your target platform basically ARM. It is designed to help you create that shared library.

  • When to use NDK
You only need to use the NDK if your application is truly processor bound. That is, you have algorithms that are using all of the processor within the DalvikVM and would benefit from running natively.
Another reason to use the NDK is for ease of porting. If you’ve got loads of C,C++ code for your existing application, using the NDK could speed up your project’s development process as well as help keep changes synchronized between your Android and non-Android projects.
There are cases where NDK will be really helpful for your app, NDK has a rather limited API that’s mostly focused on several performance-critical areas, such as:
  • OpenGL, including support for some newer versions that the (Java) SDK supports
  • Math (some, but not all, calculation-intensive algorithms might benefit from being done on the native layer)
  • 2D graphicspixelbuffer support (only starting with 2.2)
  • libcit’s there for compatibility and perhaps to allow you to port existing native code 
While NDK supports both C and C++, C++ support is rather limited. For example, exceptions are not supported and there are some known bugs in static constructor/destructor invocations. Also, most of the time when you will use NDK as it was intended – for moving the most performance-critical parts of code to the native layer – you are not likely to need much OOP abstraction and other design goodies. What I’m trying to say is that NDK code is more likely to be written in C rather than C++.
  • Be Careful
As it was mentioned above, and as you probably understand better now, NDK is not a monster and is quite easy to use in your app. However, every time you want to use NDK, please think twice and perform investigation to see how much you could actually gain from using it. Mixing C/C++ with Java is generally a bad idea from the code quality point of view, and Dalvik VM is getting faster and faster so you can avoid the NDK in many cases.
Don’t assume you’ll increase your application’s performance just because you’re using native code. The Java<->Native C exchanges add some overhead, so it’s only really worthwhile if you’ve got some intensive processing to do.
Also, be sure to read the NDK docs and learn JNI thoroughly to make sure you use NDK correctly and safely.