Android NDK 是在SDK前面又加上了“原生”二字，即Native Development Kit，因此又被Google称为“NDK”。众所周知，Android程序运行在Dalvik虚拟机中，NDK允许用户使用类似C / C++之类的原生代码语言执行部分程序。NDK包括：

从C / C++生成原生代码库所需要的工具和build files；
将一致的原生库嵌入可以在Android设备上部署的应用程序包文件（application packages files ，即.apk文件）中；
支持所有未来Android平台的一系列原生系统头文件和库。
为何要用到NDK？概括来说主要分为以下几种情况：

代码保护，由于APK的Java层代码很容易被反编译，而C/C++库反汇难度较大；
在NDK中调用第三方C/C++库，因为大部分的开源库都是用C/C++代码编写的；
便于移植，用C/C++写的库可以方便地在其他的嵌入式平台上再次使用。
Android JNI与NDK的关系

Java Native Interface（JNI）标准是Java平台的一部分，它允许Java代码和其他语言写的代码进行交互。JNI是本地编程接口，它使得在Java虚拟机（VM）内部运行的Java代码能够与用其它编程语言（如C、C++和汇编语言）编写的应用程序和库进行交互操作。

简单来说，可以认为NDK就是能够方便快捷开发.so文件的工具。JNI的过程比较复杂，生成.so需要大量操作，而NDK的作用则是简化了这个过程
         如何发现并解决NDK错误？

利用Android NDK开发本地应用时，几乎所有的程序员都遇到过程序崩溃的问题，但它的崩溃会在logcat中打印一堆看起来类似天书的堆栈信息，让人举足无措。单靠添加一行行的打印信息来定位错误代码做在的行数，无疑是一件令人崩溃的事情。在网上搜索“Android NDK崩溃”，可以搜索到很多文章来介绍如何通过Android提供的工具来查找和定位NDK的错误，但大都晦涩难懂。下面以一个实际的例子来说明，如何通过两种不同的方法，来定位错误的函数名和代码行。
           第一种方法：ndk-stack

这个命令行工具包含在NDK工具的安装目录，和ndk-build及其他常用的一些NDK命令放在一起，比如在我的电脑上，其位置是/android-ndk-r9d/ndk-stack。根据Google官方文档，NDK从r6版本开始提供ndk-stack命令，如果你用的之前的版本，建议还是尽快升级至最新的版本。使用ndk –stack命令也有两种方式
        第二种方法：使用addr2line和objdump命令

这个方法适用于那些不满足于上述ndk-stack的简单用法，而喜欢刨根问底的程序员们，这两个方法可以揭示ndk-stack命令的工作原理是什么，尽管用起来稍微麻烦一点，但可以稍稍满足一下程序员的好奇心。

先简单说一下这两个命令，在绝大部分的Linux发行版本中都能找到他们，如果你的操作系统是Linux，而你测试手机使用的是Intel x86系列，那么你使用系统中自带的命令就可以了。然而，如果仅仅是这样，那么绝大多数人要绝望了，因为恰恰大部分开发者使用的是Windows，而手机很有可能是armeabi系列。
             Testin崩溃分析如何帮开发者发现NDK错误

以上提到的方法，只适合在开发测试期间，如果你的应用或游戏已经上线，而用户经常反馈说崩溃、闪退，指望用户帮你收集信息定位问题几乎是不可能的。这个时候，我们就需要用其他的手段来捕获崩溃信息。

目前业界已经有一些公司推出了崩溃信息收集的服务，通过嵌入SDK，在程序发生崩溃时收集堆栈信息，发送到云服务平台，从而帮助开发者定位错误信息。在这方面，国内的Testin和国外的crittercism都可以提供类似服务。

Testin从1.4版本开始支持NDK的崩溃分析，其最新版本已升级到1.7。当程序发生NDK错误时，其内嵌的SDK会收集程序在用户手机上发生崩溃时的堆栈信息（主要就是上面我们通过logcat日志获取到的函数指针）、设备信息、线程信息等，SDK将这些信息上报至Testin云服务平台，在平台进行唯一性的处理、并可以自定义时段进行详尽的统计分析，从多维度展示程序崩溃的信息和严重程度；最新版本还支持用户自定义场景，方便开发者定位问题所在。

从用户手机上报的堆栈信息，Testin为NDK崩溃提供了符号化的功能，只要将我们编译过程中产生的包含符号表的so文件上传，就可以自动将函数指针地址定位到函数名称和代码行数。符号化之后，看起来就和我们前面在本地测试的结果是一样的了，一目了然。而且使用这个功能还有一个好处：这些包含符号表的so文件，在每次开发者编译之后都会改变，很有可能我们发布之后就已经变了，因为开发者会修改程序。在这样的情况下，即使我们拿到了崩溃时的堆栈信息，那也无法再进行符号化了。我们可以将这些文件上传到Testin进行符号化的工作，Testin会为我们保存和管理不同版本的so文件，确保信息不会丢失。

               Android NDK 是在SDK前面又加上了“原生”二字，即Native Development Kit，因此又被Google称为“NDK”。众所周知，Android程序运行在Dalvik虚拟机中，NDK允许用户使用类似C / C++之类的原生代码语言执行部分程序。NDK包括：

从C / C++生成原生代码库所需要的工具和build files；
将一致的原生库嵌入可以在Android设备上部署的应用程序包文件（application packages files ，即.apk文件）中；
支持所有未来Android平台的一系列原生系统头文件和库。
为何要用到NDK？概括来说主要分为以下几种情况：

代码保护，由于APK的Java层代码很容易被反编译，而C/C++库反汇难度较大；
在NDK中调用第三方C/C++库，因为大部分的开源库都是用C/C++代码编写的；
便于移植，用C/C++写的库可以方便地在其他的嵌入式平台上再次使用。
Android JNI与NDK的关系

Java Native Interface（JNI）标准是Java平台的一部分，它允许Java代码和其他语言写的代码进行交互。JNI是本地编程接口，它使得在Java虚拟机（VM）内部运行的Java代码能够与用其它编程语言（如C、C++和汇编语言）编写的应用程序和库进行交互操作。

简单来说，可以认为NDK就是能够方便快捷开发.so文件的工具。JNI的过程比较复杂，生成.so需要大量操作，而NDK的作用则是简化了这个过程
         如何发现并解决NDK错误？

利用Android NDK开发本地应用时，几乎所有的程序员都遇到过程序崩溃的问题，但它的崩溃会在logcat中打印一堆看起来类似天书的堆栈信息，让人举足无措。单靠添加一行行的打印信息来定位错误代码做在的行数，无疑是一件令人崩溃的事情。在网上搜索“Android NDK崩溃”，可以搜索到很多文章来介绍如何通过Android提供的工具来查找和定位NDK的错误，但大都晦涩难懂。下面以一个实际的例子来说明，如何通过两种不同的方法，来定位错误的函数名和代码行。
           第一种方法：ndk-stack

这个命令行工具包含在NDK工具的安装目录，和ndk-build及其他常用的一些NDK命令放在一起，比如在我的电脑上，其位置是/android-ndk-r9d/ndk-stack。根据Google官方文档，NDK从r6版本开始提供ndk-stack命令，如果你用的之前的版本，建议还是尽快升级至最新的版本。使用ndk –stack命令也有两种方式
        第二种方法：使用addr2line和objdump命令

这个方法适用于那些不满足于上述ndk-stack的简单用法，而喜欢刨根问底的程序员们，这两个方法可以揭示ndk-stack命令的工作原理是什么，尽管用起来稍微麻烦一点，但可以稍稍满足一下程序员的好奇心。

先简单说一下这两个命令，在绝大部分的Linux发行版本中都能找到他们，如果你的操作系统是Linux，而你测试手机使用的是Intel x86系列，那么你使用系统中自带的命令就可以了。然而，如果仅仅是这样，那么绝大多数人要绝望了，因为恰恰大部分开发者使用的是Windows，而手机很有可能是armeabi系列。
             Testin崩溃分析如何帮开发者发现NDK错误

以上提到的方法，只适合在开发测试期间，如果你的应用或游戏已经上线，而用户经常反馈说崩溃、闪退，指望用户帮你收集信息定位问题几乎是不可能的。这个时候，我们就需要用其他的手段来捕获崩溃信息。

目前业界已经有一些公司推出了崩溃信息收集的服务，通过嵌入SDK，在程序发生崩溃时收集堆栈信息，发送到云服务平台，从而帮助开发者定位错误信息。在这方面，国内的Testin和国外的crittercism都可以提供类似服务。

Testin从1.4版本开始支持NDK的崩溃分析，其最新版本已升级到1.7。当程序发生NDK错误时，其内嵌的SDK会收集程序在用户手机上发生崩溃时的堆栈信息（主要就是上面我们通过logcat日志获取到的函数指针）、设备信息、线程信息等，SDK将这些信息上报至Testin云服务平台，在平台进行唯一性的处理、并可以自定义时段进行详尽的统计分析，从多维度展示程序崩溃的信息和严重程度；最新版本还支持用户自定义场景，方便开发者定位问题所在。

从用户手机上报的堆栈信息，Testin为NDK崩溃提供了符号化的功能，只要将我们编译过程中产生的包含符号表的so文件上传，就可以自动将函数指针地址定位到函数名称和代码行数。符号化之后，看起来就和我们前面在本地测试的结果是一样的了，一目了然。而且使用这个功能还有一个好处：这些包含符号表的so文件，在每次开发者编译之后都会改变，很有可能我们发布之后就已经变了，因为开发者会修改程序。在这样的情况下，即使我们拿到了崩溃时的堆栈信息，那也无法再进行符号化了。我们可以将这些文件上传到Testin进行符号化的工作，Testin会为我们保存和管理不同版本的so文件，确保信息不会丢失。