Android NDK 是在SDK前面又加上了“原生”二字，即Native Development Kit，因此又被Google称为“NDK”。 众所周知，Android程序运行在Dalvik虚拟机中，NDK允许用户使用类似C / C++之类的原生代码语言执行部分程序。 [b]NDK包括了：[/b] 从C / C++生成原生代码库所需要的工具和build files。 将一致的原生库嵌入可以在Android设备上部署的应用程序包文件（application packages files ，即.apk文件）中。 支持所有未来Android平台的一些列原生系统头文件和库  一、NDK产生的背景 　　Android平台从诞生起，就已经支持C、C++开发。众所周知，Android的SDK基于Java实现，这意味着基于Android SDK进行开发的第三方应用都必须使用Java语言。但这并不等同于“第三方应用只能使用Java”。在Android SDK首次发布时，Google就宣称其虚拟机Dalvik支持JNI编程方式，也就是第三方应用完全可以通过JNI调用自己的C动态库，即在Android平台上，“Java+C”的编程方式是一直都可以实现的。 　　不过，Google也表示，使用原生SDK编程相比Dalvik虚拟机也有一些劣势，Android SDK文档里，找不到任何JNI方面的帮助。即使第三方应用开发者使用JNI完成了自己的C动态链接库（so）开发，但是so如何和应用程序一起打包成apk并发布？这里面也存在技术障碍。比如程序更加复杂，兼容性难以保障，无法访问Framework API，Debug难度更大等。开发者需要自行斟酌使用。 　　于是NDK就应运而生了。NDK全称是Native Development Kit。 　　NDK的发布，使“Java+C”的开发方式终于转正，成为官方支持的开发方式。NDK将是Android平台支持C开发的开端。 二、为什么使用NDK 　　1.代码的保护。由于apk的java层代码很容易被反编译，而C/C++库反汇难度较大。 　　2.可以方便地使用现存的开源库。大部分现存的开源库都是用C/C++代码编写的。 　　3.提高程序的执行效率。将要求高性能的应用逻辑使用C开发，从而提高应用程序的执行效率。 　　4.便于移植。用C/C++写得库可以方便在其他的嵌入式平台上再次使用。 三、NDK简介       [b]1.NDK是一系列工具的集合[/b]        NDK提供了一系列的工具，帮助开发者快速开发C（或C++）的动态库，并能自动将so和java应用一起打包成apk。这些工具对开发者的帮助是巨大的。 NDK集成了交叉编译器，并提供了相应的mk文件隔离CPU、平台、ABI等差异，开发人员只需要简单修改mk文件（指出“哪些文件需要编译”、“编译特性要求”等），就可以创建出so。 NDK可以自动地将so和Java应用一起打包，极大地减轻了开发人员的打包工作。       [b] 2.NDK提供了一份稳定、功能有限的API头文件声明[/b]        Google明确声明该API是稳定的，在后续所有版本中都稳定支持当前发布的API。从该版本的NDK中看出，这些API支持的功能非常有限，包含有：C标准库（libc）、标准数学库（libm）、压缩库（libz）、Log库（liblog）。 四、NDK开发环境的搭建 [b]1.下载安装Android NDK[/b] 　　地址：braincol@ubuntu:~$ cd workspace/android/NDK/hello-jni/ 　　ls查看工程文件　　 braincol@ubuntu:~/workspace/android/NDK/hello-jni$ ls AndroidManifest.xml  assets  bin  default.properties  gen  res  src 　　可以看到目前仅仅有几个标准的android应用程序的文件（夹）。 　　首先我们在工程目录下建立一个jni文件夹： braincol@ubuntu:~/workspace/android/NDK/hello-jni$ mkdir jni braincol@ubuntu:~/workspace/android/NDK/hello-jni$ ls AndroidManifest.xml  assets  bin  default.properties  gen  jni  res  src 　　下面就可以生成相应的.h文件了： braincol@ubuntu:~/workspace/android/NDK/hello-jni$ javah -classpath bin -d jni com.example.hellojni.HelloJni 　　-classpath bin：表示类的路劲 　　-d jni: 表示生成的头文件存放的目录 　　com.example.hellojni.HelloJni 则是完整类名 　　这一步的成功要建立在已经在 bin/com/example/hellojni/  目录下生成了 HelloJni.class的基础之上。现在可以看到jni目录下多了个.h文件： braincol@ubuntu:~/workspace/android/NDK/hello-jni$ cd jni/ braincol@ubuntu:~/workspace/android/NDK/hello-jni/jni$ ls com_example_hellojni_HelloJni.h 　　我们来看看com_example_hellojni_HelloJni.h的内容： 　　com_example_hellojni_HelloJni.h : 　　上面代码中的JNIEXPORT 和 JNICALL 是jni的宏，在android的jni中不需要，当然写上去也不会有错。从上面的源码中可以看出这个函数名那是相当的长啊。。。。 不过还是很有规律的， 完全按照：java_pacakege_class_mathod 形式来命名。 　　也就是说： 　　Hello.java中 stringFromJNI() 方法对应于 C/C++中的 Java_com_example_hellojni_HelloJni_stringFromJNI() 方法 　　HelloJni.java中的 unimplementedStringFromJNI() 方法对应于 C/C++中的 Java_com_example_hellojni_HelloJni_unimplementedStringFromJNI() 方法 　　注意下其中的注释： 　　Signature: ()Ljava/lang/String; 　　()Ljava/lang/String;()表示函数的参数为空（这里为空是指除了JNIEnv *, jobject 这两个参数之外没有其他参数，JNIEnv*, jobject是所有jni函数必有的两个参数，分别表示jni环境和对应的java类（或对象）本身），Ljava/lang/String; 表示函数的返回值是java的String对象。 b. 编写相应的.c文件： 　　hello-jni.c : 　　这里只是实现了Java_com_example_hellojni_HelloJni_stringFromJNI方法，而 Java_com_example_hellojni_HelloJni_unimplementedStringFromJNI 方法并没有实现，因为在HelloJni.java中只调用了stringFromJNI()方法，所以unimplementedStringFromJNI()方法没有实现也没关系，不过建议最好还是把所有java中定义的本地方法都实现了，写个空函数也行啊。。。有总比没有好。 　　Java_com_example_hellojni_HelloJni_stringFromJNI() 函数只是简单的返回了一个内容为 "Hello from JNI !" 的jstring对象（对应于java中的String对象）。hello-jni.c文件已经编写好了，现在可以把com_example_hellojni_HelloJni.h文件给删了，当然留着也行，只是我还是习惯把不需要的文件给清理干净了。 3)编译hello-jni.c 生成相应的库 a 编写Android.mk文件 　　在jni目录下（即hello-jni.c 同级目录下）新建一个Android.mk文件，Android.mk 文件是Android 的 makefile文件，内容如下： 　　这个Androd.mk文件很短，下面我们来逐行解释下： 　　　　LOCAL_PATH := $(call my-dir) 　　一个Android.mk 文件首先必须定义好LOCAL_PATH变量。它用于在开发树中查找源文件。在这个例子中，宏函数'my-dir', 由编译系统提供，用于返回当前路径（即包含Android.mk file文件的目录）。 　　　　include $( CLEAR_VARS) 　　CLEAR_VARS由编译系统提供，指定让GNU MAKEFILE为你清除许多LOCAL_XXX变量（例如 LOCAL_MODULE, LOCAL_SRC_FILES, LOCAL_STATIC_LIBRARIES, 等等...), 除LOCAL_PATH 。这是必要的，因为所有的编译控制文件都在同一个GNU MAKE执行环境中，所有的变量都是全局的。 　　　　LOCAL_MODULE := hello-jni 　　编译的目标对象，LOCAL_MODULE变量必须定义，以标识你在Android.mk文件中描述的每个模块。名称必须是唯一的，而且不包含任何空格。 注意：编译系统会自动产生合适的前缀和后缀，换句话说，一个被命名为'hello-jni'的共享库模块，将会生成'libhello-jni.so'文件。 　　重要注意事项：如果你把库命名为‘libhello-jni'，编译系统将不会添加任何的lib前缀，也会生成 'libhello-jni.so'，这是为了支持来源于Android平台的源代码的Android.mk文件，如果你确实需要这么做的话。 　　　　LOCAL_SRC_FILES := hello-jni.c 　　LOCAL_SRC_FILES变量必须包含将要编译打包进模块中的C或C++源代码文件。注意，你不用在这里列出头文件和包含文件，因为编译系统将会自动为你找出依赖型的文件；仅仅列出直接传递给编译器的源代码文件就好。 　　注意，默认的C++源码文件的扩展名是'.cpp'. 指定一个不同的扩展名也是可能的，只要定义LOCAL_DEFAULT_CPP_EXTENSION变量，不要忘记开始的小圆点（也就是'.cxx',而不是'cxx'） 　　　　include $(BUILD_SHARED_LIBRARY) 　　BUILD_SHARED_LIBRARY表示编译生成共享库，是编译系统提供的变量，指向一个GNU Makefile脚本，负责收集自从上次调用'include $(CLEAR_VARS)'以来，定义在LOCAL_XXX变量中的所有信息，并且决定编译什么，如何正确地去做。还有 BUILD_STATIC_LIBRARY变量表示生成静态库：lib$(LOCAL_MODULE).a， BUILD_EXECUTABLE 表示生成可执行文件。 b. 生成.so共享库文件 　　Andro文件已经编写好了，现在可以用android NDK开发包中的 ndk-build脚本生成对应的.so共享库了，方法如下： 　　　　braincol@ubuntu:~/workspace/android/NDK/hello-jni/jni$ cd .. 　　　　braincol@ubuntu:~/workspace/android/NDK/hello-jni$ ls 　　　　AndroidManifest.xml  assets  bin  default.properties  gen  jni  libs  obj  res  src 　　　　braincol@ubuntu:~/workspace/android/NDK/hello-jni$ ndk-build 　　　　Gdbserver      : [arm-linux-androideabi-4.4.3] libs/armeabi/gdbserver 　　　　Gdbsetup       : libs/armeabi/gdb.setup 　　　　Install        : libhello-jni.so => libs/armeabi/libhello-jni.so 　　可以看到已经正确的生成了libhello-jni.so共享库了， 我们去 libs/armeabi/ 目录下看看： 　　　　braincol@ubuntu:~/workspace/android/NDK/hello-jni$ cd libs/ 　　　　braincol@ubuntu:~/workspace/android/NDK/hello-jni/libs$ ls 　　　　armeabi 　　　　braincol@ubuntu:~/workspace/android/NDK/hello-jni/libs$ cd armeabi/ 　　　　braincol@ubuntu:~/workspace/android/NDK/hello-jni/libs/armeabi$ ls 　　　　gdbserver  gdb.setup  libhello-jni.so 4)在eclipse重新编译HelloJni工程，生成apk 　　eclipse中刷新下HelloJni工程，重新编译生成apk，libhello-jni.so共享库会一起打包在apk文件内。在模拟器中看看运行结果。