Porting an existing NDK application to x86 for most applications should be very straightforward. There are some great tutorials along with example source code for various applications. For more intricate details, start with the great documentation that comes with the NDK package. The aforementioned sections provide a head start on using the NDK. Here is a snippet of a simple Android.mk file: The Android.mk file is used to control how and from what a module (static/shared library) is built. The Application.mk file is used to describe which native modules are needed by your application. The developer will create an Android.mk makefile for a project, and optionally, an Application.mk file. This provides developers with the convenience of native code porting all inclusive in one package.īrief Overview of NDK Internals Makefiles As of NDK r6b, the NDK can be used to build both ARM*–based and x86 ( Intel® Atom™ microarchitecture)–based native libraries. There is no "written rule" as to when the NDK should and shouldn't be used, but these points provide some general guidelines and things to look out for.ĭevelopers can grab the latest version here. Specifically, using native code in an Android* application doesn't guarantee a performance boost! Commonly, performance gains can be appreciated in cases such as when the native code involves CPU-centric operations (such as heavy – duty usage of SSE instructions), but at other times, when for example, the application at hand is simply providing a complex web interface to the user, the use of native code through JNI may hinder performance. The overhead of JNI is costly, and thus ideally, the JNI calls made in the application should be kept minimal. For a quicker overview, the Wiki page suffices (when in doubt, always cross-reference the specification for correctness). The aforementioned link is an extensive, deep dive into the specification of JNI. The interface bridging the Android* Java* code with native code precompiled by the NDK is known as the Java* Native Interface (JNI). Performance Implications and the Cost of JNI For example, if the native library involves inline assembly within C code, that code can't simply be assembled and work "as is" on the two different architectures some rewriting will be needed (see the section discussing ARM* NEON* versus Intel SSE). It may be the case that the second point mentioned may simply require just a build flag change and recompile, but sometimes it isn't that easy. Recompiling ARM* native library (libraries) to x86 (Intel® Atom™ microarchitecture) and possibly porting as needed.Compiling a native C/C++ library to be used (called by wrapper Java* code) in an Android* package.The purpose of the NDK is to aide developers as follows: While the tool can be used to reap performance benefits in some applications, some caution needs to be taken as this isn't always the case. The NDK is a great tool for combining the power of native x86 code with the graphical interface of a wrapper Android* application. Porting ARM*’s NEON instructions to Intel® SSE for Intel Atom™.Memory Alignment Implications: ARM* vs.Performance Implications and the Cost of JNI.The guide also provides tips and guidance if you run into compiler issues during the porting process. If you already have a working application and need to know how to quickly get your application recognized on the Android* Market by x86 devices, this document should provide you with the information to get started. This guide is intended to help developers port existing ARM*-based NDK applications to x86.
0 Comments
Leave a Reply. |