189 8069 5689
NDK是一系列工具的集合。它提供了一系列的工具，帮助开发者快速开发C（或C++）的动态库，并能自动将so和java应用一起打包成apk(AndroidPackage的缩写，Android安装包)。这些工具对开发者的帮助是巨大的。它集成了交叉编译器，并提供了相应的mk文件隔离CPU、平台、ABI等差异，开发人员只需要简单修改mk文件（指出“哪些文件需要编译”、“编译特性要求”等），就可以创建出so。它可以自动地将so和Java应用一起打包，极大地减轻了开发人员的打包工作。
成都创新互联公司专注为客户提供全方位的互联网综合服务，包含不限于网站制作、成都网站建设、白银区网络推广、微信小程序开发、白银区网络营销、白银区企业策划、白银区品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等，从售前售中售后，我们都将竭诚为您服务，您的肯定，是我们最大的嘉奖；成都创新互联公司为所有大学生创业者提供白银区建站搭建服务，24小时服务热线：028-86922220，官方网址：www.cdcxhl.com
NDK提供了一份稳定、功能有限的API头文件声明，Google明确声明该API是稳定的，在后续所有版本中都稳定支持当前发布的API。从该版本的NDK中看出，这些API支持的功能非常有限，包含有：C标准库（libc）、标准数学库（libm）、压缩库（libz）、Log库（liblog）。
1，首先，来看看在hello-jni程序的代码中做了什么（有关如何创建或导入工程，此处略），下面代码中：在JNI_OnLoad()的函数中，即so加载时，调用willCrash()函数，而在willCrash()函数中， std::string的这种赋值方法会产生一个空指针错误。这样，在hello-jni程序加载时就会闪退。记一下这两个行数：在61行调用了willCrash()函数；在69行发生了崩溃。
2、看看发生崩溃（闪退）时系统打印的logcat日志：
只要细心的查看，再配合Google 提供的工具，完全可以快速地准确定位出错的代码位置，这个工作我们称之为“符号化”。需要注意的是，如果要对NDK错误进行符号化的工作，需要保留编译过程中产生的包含符号表的so文件，这些文件一般保存在$PROJECT_PATH/obj/local/目录下。
3 方法：ndk-stack
这个命令行工具包含在NDK工具的安装目录，和ndk-build及其他常用的一些NDK命令放在一起，比如在我的电脑上，其位置是/android-ndk-r9d/ndk-stack。根据Google官方文档，NDK从r6版本开始提供ndk-stack命令，如果你用的之前的版本，建议还是尽快升级至最新的版本。使用ndk –stack命令也有两种方式
实时分析日志
在运行程序的同时，使用adb获取logcat日志，并通过管道符输出给ndk-stack，同时需要指定包含符号表的so文件位置；如果你的程序包含了多种CPU架构，在这里需求根据错误发生时的手机CPU类型，选择不同的CPU架构目录，如：
当崩溃发生时，会得到如下的信息：
重点看一下#03和#04，这两行都是在我们自己生成的libhello-jni.so中的报错信息，因此会发现如下关键信息：
回想一下之前代码，在JNI_OnLoad()函数中（第61行），调用了willCrash()函数；在willCrash()函数中（第69行），制造了一个错误。
4 先获取日志再分析
这种方法其实和上面的方法没有什么大的区别，仅仅是logcat日志获取的方式不同。可以在程序运行的过程中将logcat日志保存到一个文件，甚至可以在崩溃发生时，快速的将logcat日志保存起来，然后再进行分析，比上面的方法稍微灵活一点，而且日志可以留待以后继续分析。
这里使用的是如下函数：
其中参数如下：
src1：第一张源图像
alpha：第一张图像占的比重
src2：第二张源图像
beta：第二张图像占的比重
gamma：该值越大图像越白，大于等于255时图像全白
dst：合成的目标图像
这里要注意的是两张融合的图像大小要调整为一致，不一致的话会出现错误
NDK:Android NDK 是在SDK前面又加上了“原生”二字，即Native Development Kit，因此又被Google称为“NDK”。
NDK全称：Native Development Kit。
NDK是一系列工具的集合。
* NDK提供了一系列的工具，帮助开发者快速开发C（或C++）的动态库，并能自动将so和java应用一起打包成apk。这些工具对开发者的帮助是巨大的。
* NDK集成了交叉编译器，并提供了相应的mk文件隔离CPU、平台、ABI等差异，开发人员只需要简单修改mk文件（指出“哪些文件需要编译”、“编译特性要求”等），就可以创建出so。
* NDK可以自动地将so和Java应用一起打包，极大地减轻了开发人员的打包工作。
其实：
NDK就是能够方便快捷开发.so文件的工具。JNI的过程比较复杂，生成.so需要大量操作，而NDK就是简化了这个过程。
Android SDK:
SDK （software development kit）软件开发工具包。被软件开发工程师用于为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件的开发工具的集合。因此！Android SDk 指的既是Android专属的软件开发工具包
JNI:
Java Native Interface (JNI)标准是java平台的一部分，它允许Java代码和其他语言写的代码进行交互。JNI 是本地编程接口，它使得在 Java 虚拟机 (VM) 内部运行的 Java 代码能够与用其它编程语言(如 C、C++ 和汇编语言)编写的应用程序和库进行交互操作
当然一般需要进行如下操作流程：
1) 编写java程序：这里以HelloWorld为例。为了实现在 java代码中调用c函数printf。
代码1：
class HelloWorld {
public native void testHelloWorld();
static {
System.loadLibrary("hello");
}
public static void main(String[] args) {
new HelloWorld().testHelloWorld();
}
}
声明native方法：如果你想将一个方法做为一个本地方法的话，那么你就必须声明改方法为native的，并且不能实现。
Load动态库：System.loadLibrary("hello");
这里一般是以static块进行加载的。同时需要注意的是System.loadLibrary()的参数“hello”是动态库的名字。
2) 编译
javac HelloWorld.java
3) 生成扩展名为h的头文件 javah ?
JNIEXPORT void JNICALL Java_HelloWorld_testHelloWorld (JNIEnv *, jobject);
这个h文件相当于我们在java里面的接口，这里声明了一个 Java_HelloWorld_testHelloWorld (JNIEnv *, jobject)方法，然后在我们 的本地方法里面实现这个方法，也就是说我们在编写C/C++程序的时候所使用的方法名必须和这里的一致）。
4) 编写本地方法实现和由javah命令生成的头文件里面声明的方法名相同的方法
代码2：
#include "jni.h"
#include "HelloWorld.h"
#include other headers
JNIEXPORT void JNICALL Java_HelloWorld_testHelloWorld(JNIEnv *env, jobject obj)
{
printf("Hello world!/n");
return;
}
注意代码2中的第1行，需要将jni.h（该文件可以在%JAVA_HOME%/include文件夹下面找到）文件引入，因为在程序中的JNIEnv、 jobject等类型都是在该头文件中定义的；另外在第2行需要将HelloWorld.h头文件引入。然后保存为 HelloWorldImpl.c就ok了。
5) 生成动态库
这里以在Windows中为例，需要生成dll文件。在保存HelloWorldImpl.c文件夹下面，使用VC的编译器cl成。 cl -I%java_home%/include -I%java_home%/include/win32 -LD HelloWorldImp.c -Fehello.dll 注意：生成的dll文件名在选项-Fe后面配置，这里是hello，因为在HelloWorld.java文件中我们loadLibary的时候使用的名字是hello。
另外需要将-I%java_home%/include -I%java_home%/include/win32参数加上，因为在第四步里面编写本地方法的时候引入了jni.h文件。
很多朋友在开发 Android JNI的的时候，会遇到findlibrary returned null的错误，因为某种原因，so没有打包到apk中。下面浅析下引起该错误的原因以及平台兼容性问题。
一、没有将so打包到apk中的原因。
当你发现到findlibrary returned null的错误时，其实最直接的解决办法就是解压apk，看看apk中的x86、armeabi、armeabi-v7a文件夹中是否有对应的so，此时你可能在对应的文件夹下发现少了so，然后再去查原因即可。
一般有两方面的原因:
1.apk中有对应平台的文件夹，但是文件夹里却没有对应的so。
举个例子，apk中lib下面一旦出现x86文件夹，程序运行的时候就会去加载x86对应的库，但是如果此时x86文件夹没有将so放进来，则会遇到报错。
2.第三方对平台的兼容策略与自己不一致。
可能第三方选择了只支持armeabi（假设某支付sdk），但是我们的游戏在Application.mk中配置了APP_ABI := all，如此，我们的游戏打包出 了所有平台的so，但是第三方却只有armeabi文件夹对应的so，造成程序运行异常，这种情况在开发期间最常见，一些小公司由于测试人员不足或者测试设备不足，上线后才发现这个问题也不奇怪。
二、对于平台的支持，我们应该如何选择。
armeabi-v7a确实是可以兼容armeabi的，而v7a的CPU支持硬件浮点运算，目前绝大对数设备已经是v7a了，所以为了性能上的更优，就不要为了兼容放到armeabi。 x86是可以兼容armeabi平台运行的，无论是armeabi-v7a还是armeabi，同时带来的也是性能上的损耗，另外需要指出的是，打包出的x86的so，总会比armeabi平台的体积更小，对于性能有洁癖的童鞋们，还是建议在打包so的时候支持x86。具体会有怎样的性能损耗，作者还不能说的非常清楚，可以访问下intel官方在csdn的博客。 总结一下在项目中的表现就是: