Android NDK Learning Notes (a) Why use the NDK?

What is the NDK?

The NDK is the abbreviation for Native Development Kit, the local development kit. The ndk,android allows developers to use native code languages, such as C + +, to complete some (or all) of the functionality of the app. Note: Some places also translate native into "native" for reasons of translation.

The NDK is a supplement to the SDK that can help you do these things:

• Generate a JNI-compatible shared library that can run on ARM cpu,android 1.5 (and above) platforms.

• Place the generated shared library in the appropriate location in the application project path so that it can be automatically added to your final (and signed) APK package.

• In subsequent NDK releases, we wanted to provide tools to assist in debugging local code through a remote GDB connection and as much source/symbol information as possible.

In addition, the NDK offers:

• A collection of cross-tool chains (compilers, linker, etc) that can generate native arm binaries on Linux, OS X, and Windows (Cygwin is required on windows).

• A collection of System API header files that are guaranteed backwards compatibility and stable support.

• A build system that allows developers to write only very short build files to describe which files need to be compiled and how to compile. The build system takes care of the cumbersome differences between the Toolchain, Android platform, CPU, and Abi. In addition, subsequent updates to the NDK will add support for more toolchain, platforms, and system interfaces without changing the developer's build files.

Understanding the NDK correctly

The NDK is a toolkit, but there is a lot of misunderstanding around this toolkit. As beginners, we should have a clear understanding of these misunderstandings, to avoid falling into various "pits."

• Misunderstanding one: Android does not support C + + development before the NDK releases

As we all know, the Android SDK is based on Java implementations, which means that third-party apps that are developed based on the Android SDK must use the Java language. But this is not the same as "third-party apps can only use Java." When the Android SDK was first released, Google announced that its virtual machine Dalvik supported JNI programming, which means that third-party applications could call their own C dynamic library through JNI, i.e., on Android, the "java+c" programming is always possible.

Of course, there is a root cause of this misunderstanding: in the Android SDK documentation, no JNI help can be found. Even if third-party application developers use JNI to complete their own C dynamic-link library (SO) development, how so is packaged with the app as an APK and released? There are also technical barriers in this. Some developers install the cross compiler to create so, and through the assets way, implement bundle so release. But this approach can only be opportunistic, and unofficial support. So, before the NDK comes out, we call the "java+c" development Model A grey pattern, that is, the official does not declare "support this way", nor does it declare "does not support this way".

• Misunderstanding two: With the NDK, you can use C to develop applications completely

Prior to NDKR5, the NDK did not provide various system event processing support or APIs for application lifecycle maintenance and application UI, making it almost impossible to make a complete application. However, since the release of the NDK R5, you have been allowed to develop applications or games entirely in C + + and no longer need to write any Java code.

• Myth Three: Using NDK development can greatly improve performance

The industry's long-standing discrimination against Java has led many to dismiss Java code as a fanatical cult of C + + code, which is that the program written by C + + must run faster than Java. However, experience has shown that poor performance is often attributed to chaotic data structures and slow algorithms, rather than the programming language itself. In fact, excluding the necessary consumption of virtual machines, Java code is no slower and sometimes faster than the C + + +. Google's official documentation also shows that using native code on Android usually does not result in significant performance gains, but it always increases the complexity of the application. In general, you should use the NDK only when it is necessary for your application, rather than simply because you prefer to use C + + programming .

• Myth Four: Developing apps with the ndk don't worry about decompile

Many people know that Java code can be easily de-compiled, so the business logic that needs to be kept secret is implemented in so. This is not a problem in itself, but many people exaggerate it, thinking that as long as you put the native code into the shared library, you can rest assured that you don't have to worry about decompile. In fact, the search for "decompile so Files" on Baidu and Google can produce hundreds of thousands of results. If simply for the sake of code security, fully consider the SDK provided by the Code obfuscation tool, details can be self-access to the relevant information, this is not to repeat. Bottom line: TheNDK doesn't guarantee code security!

The NDK's scope of application

Google has recommended some CPU-intensive tasks that you might consider using the NDK for these tasks:

• Game engine

• Signal Processing

• Physical simulation

Finally, Google reminds developers: When you think about whether you need to use the NDK, think about your needs first and check to see if the features you need are available in the Android Framework API .

This article is from the "Flying Cat" blog, be sure to keep this source http://flyingcat2013.blog.51cto.com/7061638/1416178