JNI原理及常用方法概述

1.1 JNI(Java Native Interface)

提供一种Java字节码调用C/C&＃43;&＃43;的解决方案&＃xff0c;JNI描述的是一种技术。

• 引用类型不能直接在 Native 层使用&＃xff0c;需要根据 JNI 函数进行类型的转化后&＃xff0c;才能使用;
• 多维数组&＃xff08;含二维数组&＃xff09;都是引用类型&＃xff0c;需要使用 jobjectArray 类型存取其值&＃xff1b;
  例如&＃xff0c;二维整型数组就是指向一位数组的数组&＃xff0c;其声明使用方式如下&＃xff1a;

//获得一维数组的类引用&＃xff0c;即jintArray类型 jclass intArrayClass &＃61; env->FindClass("[I"); //构造一个指向jintArray类一维数组的对象数组&＃xff0c;该对象数组初始大小为length&＃xff0c;类型为 jsizejobjectArray obejctIntArray &＃61; env->NewObjectArray(length ,intArrayClass , NULL);


1.4.3 JNI函数签名信息

由于Java支持函数重载&＃xff0c;因此仅仅根据函数名是没法找到对应的JNI函数。为了解决这个问题&＃xff0c;JNI将参数类型和返回值类型作为函数的签名信息。

1. JNI规范定义的函数签名信息格式&＃xff1a;
   (参数1类型字符…)返回值类型字符

2. 函数签名例子:

   

3. JNI常用的数据类型及对应字符:

   

1.4.4 JNIEnv介绍

1. JNIEnv概念 :
   JNIEnv是一个线程相关的结构体, 该结构体代表了 Java 在本线程的运行环境。通过JNIEnv可以调用到一系列JNI系统函数。
2. JNIEnv线程相关性&＃xff1a;
   每个线程中都有一个 JNIEnv 指针。JNIEnv只在其所在线程有效, 它不能在线程之间进行传递。

注意&＃xff1a;在C&＃43;&＃43;创建的子线程中获取JNIEnv&＃xff0c;要通过调用JavaVM的AttachCurrentThread函数获得。在子线程退出时&＃xff0c;要调用JavaVM的DetachCurrentThread函数来释放对应的资源&＃xff0c;否则会出错。

1. JNIEnv 作用&＃xff1a;
   • 访问Java成员变量和成员方法&＃xff1b;
   • 调用Java构造方法创建Java对象等。

1.5 JNI编译

1.5.1 ndkBuild

使用ndk-build编译生成so文件

1.5.2 Cmake编译

CMake 则是一个跨平台的编译工具&＃xff0c;它并不会直接编译出对象&＃xff0c;而是根据自定义的语言规则&＃xff08;CMakeLists.txt&＃xff09;生成 对应 makefile 或 project 文件&＃xff0c;然后再调用底层的编译&＃xff0c; 在Android Studio 2.2 之后支持Cmake编译。

• add_library 指令

  语法&＃xff1a;add_library(libname [SHARED | STATIC | MODULE] [EXCLUDE_FROM_ALL] [source])

  将一组源文件 source 编译出一个库文件&＃xff0c;并保存为 libname.so (lib 前缀是生成文件时 CMake自动添加上去的)。其中有三种库文件类型&＃xff0c;不写的话&＃xff0c;默认为 STATIC;

  • SHARED: 表示动态库&＃xff0c;可以在(Java)代码中使用 System.loadLibrary(name) 动态调用&＃xff1b;
  • STATIC: 表示静态库&＃xff0c;集成到代码中会在编译时调用&＃xff1b;
  • MODULE: 只有在使用 dyId 的系统有效&＃xff0c;如果不支持 dyId&＃xff0c;则被当作 SHARED 对待&＃xff1b;
  • EXCLUDE_FROM_ALL: 表示这个库不被默认构建&＃xff0c;除非其他组件依赖或手工构建;

#将compress.c 编译成 libcompress.so 的共享库
add_library(compress SHARED compress.c)


• target_link_libraries 指令
  语法&＃xff1a;target_link_libraries(target library library2…)
  这个指令可以用来为 target 添加需要的链接的共享库&＃xff0c;同样也可以用于为自己编写的共享库添加共享库链接。如&＃xff1a;

#指定 compress 工程需要用到 libjpeg 库和 log 库
target_link_libraries(compress libjpeg ${log-lib})


• find_library 指令
  语法&＃xff1a;find_library( name1 path1 path2 …)
  VAR 变量表示找到的库全路径&＃xff0c;包含库文件名 。例如&＃xff1a;

find_library(libX X11 /usr/lib)
find_library(log-lib log) #路径为空&＃xff0c;应该是查找系统环境变量路径


Android NDK 开发&＃xff1a;CMake 使用

1.5.3 Abi架构

ABI&＃xff08;Application binary interface&＃xff09;应用程序二进制接口。不同的CPU 与指令集的每种组合都有定义的 ABI (应用程序二进制接口)&＃xff0c;一段程序只有遵循这个接口规范才能在该 CPU 上运行&＃xff0c;所以同样的程序代码为了兼容多个不同的CPU&＃xff0c;需要为不同的 ABI 构建不同的库文件。当然对于CPU来说&＃xff0c;不同的架构并不意味着一定互不兼容。

• armeabi设备只兼容armeabi&＃xff1b;
• armeabi-v7a设备兼容armeabi-v7a、armeabi&＃xff1b;
• arm64-v8a设备兼容arm64-v8a、armeabi-v7a、armeabi&＃xff1b;
• X86设备兼容X86、armeabi&＃xff1b;
• X86_64设备兼容X86_64、X86、armeabi&＃xff1b;
• mips64设备兼容mips64、mips&＃xff1b;
• mips只兼容mips&＃xff1b;

根据以上的兼容总结&＃xff0c;我们还可以得到一些规律&＃xff1a;

• armeabi的SO文件基本上可以说是万金油&＃xff0c;它能运行在除了mips和mips64的设备上&＃xff0c;但在非armeabi设备上运行性能还是有所损耗&＃xff1b;
• 64位的CPU架构总能向下兼容其对应的32位指令集&＃xff0c;如&＃xff1a;x86_64兼容X86&＃xff0c;arm64-v8a兼容armeabi-v7a&＃xff0c;mips64兼容mips&＃xff1b;

1.5.4 Jni技术实现原理

我们知道cpu只认得 “0101101” 类似这种符号&＃xff0c; C、C&＃43;&＃43; 这些代码最终都得通过编译、汇编成二进制代码&＃xff0c;cpu才能识别。而Java比C、C&＃43;&＃43;又多了一层虚拟机&＃xff0c;过程也复杂许多。Java代码经过编译成class文件、虚拟机装载等步骤最终在虚拟机中执行。class文件里面就是一个结构复杂的表&＃xff0c;而最终告诉虚拟机怎么执行的就靠里面的字节码说明。

Java虚拟机在执行的时候&＃xff0c;可以采用解释执行和编译执行的方式执行&＃xff0c;但最终都是转化为机器码执行。

Java虚拟机运行时的数据区&＃xff0c;包括方法区、虚拟机栈、堆、程序计数器、本地方法栈。

问题来了&＃xff0c;按我目前的理解&＃xff0c;如果是解释执行&＃xff0c;那么方法区中应该存的是字节码&＃xff0c;那执行的时候&＃xff0c;通过JNI 动态装载的c、c&＃43;&＃43;库&＃xff0c;放哪去&＃xff1f;怎么执行&＃xff1f;这个问题&＃xff0c;搜索了许多标题写着”JNI实现原理”的文章&＃xff0c;都是抄来抄去&＃xff0c;并没去探究如何实现的&＃xff0c;只是讲了java如何使用JNI。好吧&＃xff0c;就从如何使用JNI开始。

1.6 JNI的简单实现

参考文章&＃xff1a;《Java JNI简单实现》、《JAVA基础之理解JNI原理》

假设当前的目录结构如下&＃xff1a;

-
| - maniu| Test.java

1.首先编写java文件

Test.java

package maniu;
public class Test{static{System.loadLibrary("bridge");}public native int nativeAdd(int x,int y);public static void main(String[] args){Test obj &＃61; new Test();System.out.printf("%d\n",obj.nativeAdd(2012,3));}
}


代码很简单&＃xff0c;这里声明了nativeAdd(int x,inty)的方法&＃xff0c;执行的时候简单的打出执行的结果。另外这里调用API加载名称叫bridge的库&＃xff0c;接下来就来实现这个库。

2.生成JNI调用需要的头文件

javac maniu/Test.java
javah -jni maniu.Test

现在目录结构是这样的&＃xff1a;

-
| - maniu| Test.java| Test.class
| - maniu_Test.h

maniu_Test.h头文件内容如下&＃xff1a;

/* DO NOT EDIT THIS FILE - it is machine generated */
#include
/* Header for class maniu_Test */#ifndef _Included_maniu_Test
#define _Included_maniu_Test
#ifdef __cplusplus
extern "C" {
#endif
/** Class: maniu_Test* Method: nativeAdd* Signature: (II)I*/
JNIEXPORT jint JNICALL Java_maniu_Test_nativeAdd(JNIEnv *, jobject, jint, jint);#ifdef __cplusplus
}
#endif

1.6.1 生成的代码阅读

经常会见到__cplusplus关键字&＃xff0c;比如下面的代码&＃xff1a;

#ifdef __cplusplus
extern "C" {
#endif
JNIEXPORT jint JNICALL Java_maniu_Test_nativeAdd(JNIEnv *, jobject, jint, jint);
#ifdef __cplusplus
}
#endif


这里面&＃xff0c;两种关键字&＃xff0c;都是为了实现C&＃43;&＃43;与C兼容的&＃xff0c;extern “C”是用来在C&＃43;&＃43;程序中声明或定义一个C的符号&＃xff0c;比如&＃xff1a;

extern “C” {int func(int);int var;}


上面的代码&＃xff0c;C&＃43;&＃43;编译器会将在extern “C”的大括号内部的代码当做C语言来处理。

由于C和C&＃43;&＃43;毕竟是不同的&＃xff0c;为了实现某个程序在C和C&＃43;&＃43;中都是兼容的&＃xff0c;如果定义两套头文件&＃xff0c;未免太过麻烦&＃xff0c;所以就有了__cplusplus的出现&＃xff0c;这个是在C&＃43;&＃43;中特有的&＃xff0c;__cplusplus其实就是C&＃43;&＃43;&＃xff0c;也就有了上面第一段代码的使用&＃xff0c;如果这段代码是在C&＃43;&＃43;文件中出现&＃xff0c;那么经过编译后&＃xff0c;该段代码就变成了&＃xff1a;

/**********C&＃43;&＃43;文件中条件编译后结果***************/
extern "C" {
JNIEXPORT jint JNICALL Java_maniu_Test_nativeAdd(JNIEnv *, jobject, jint, jint);
}


而在C文件中&＃xff0c;经过条件编译&＃xff0c;该段代码变成了&＃xff1a;

/**********C文件中条件编译后结果*************/
JNIEXPORT jint JNICALL Java_maniu_Test_nativeAdd(JNIEnv *, jobject, jint, jint);


3.native方法的实现
这里新增bridge.c文件来实现之前声明的native方法&＃xff0c;目录结构如下&＃xff1a;

-
| - maniu| Test.java| Test.class
| - maniu_Test.h
| - bridge.c

bridge.c的内容如下&＃xff1a;

#include "maniu_Test.h"JNIEXPORT jint JNICALL Java_maniu_Test_nativeAdd
(JNIEnv * env, jobject obj, jint x, jint y){return x&＃43;y;
}


这里的实现只是简单的把两个参数相加&＃xff0c;然后返回。

4.生成动态链接库

gcc -shared -o dll_demo.dll bridge.c

最后需要注意一点的是 -o 选项&＃xff0c;我们在java代码中调用的是System.loadLibrary("xxx"),那么生成的动态链接库的名称就必须是libxxx.so的形式&＃xff08;这里指Linux环境&＃xff09;&＃xff0c;否则在执行java代码的时候&＃xff0c;就会报 java.lang.UnsatisfiedLinkError: no XXX in java.library.path 的错误&＃xff01;也就是说找不到这个库&＃xff0c;我在这里被坑了一小段时间。
好了&＃xff0c;现在的目录结构如下&＃xff1a;

-
| - maniu| Test.java| Test.class
| - maniu_Test.h
| - bridge.c
| - libbridge.so

5.执行代码验证结果

java -Djava.library.path&＃61;. maniu.Test
2015

ok&＃xff0c;Java 使用JNI的最简单的例子就完成了。

---

1.6.2 JNI实现原理

那么&＃xff0c;我们的问题还没解决&＃xff0c;刚刚生成的动态链接库”libbridge.so”是怎么装进内存的&＃xff1f;native方法怎么调用&＃xff1f;跟普通的方法调用有什么区别吗&＃xff1f;

我们把Test.java改改&＃xff0c;增加普通的方法”int add(int x,int y)”

Test.java

package maniu;
public class Test{static{System.loadLibrary("bridge");}public native int nativeAdd(int x,int y);public int add(int x,int y){return x&＃43;y;}public static void main(String[] args){Test obj &＃61; new Test();System.out.printf("%d\n",obj.nativeAdd(2012,3));System.out.printf("%d\n",obj.add(2012,3));}
}


我们把它编译成class文件&＃xff0c;再看看class文件中&＃xff0c;native方法和普通方法有何区别&＃xff1a;

javac maniu/Test.java
javap -verbose maniu.Test

解析后&＃xff0c;”nativeAdd”和”add”两个方法的结果如下&＃xff1a;

public native int nativeAdd(int, int);flags: ACC_PUBLIC, ACC_NATIVEpublic int add(int, int);flags: ACC_PUBLICCode:stack&＃61;2, locals&＃61;3, args_size&＃61;30: iload_1 1: iload_2 2: iadd 3: ireturn LineNumberTable:line 8: 0

可见&＃xff0c;普通的“add”方法是直接把字节码放到code属性表中&＃xff0c;而native方法&＃xff0c;与普通的方法通过一个标志“ACC_NATIVE”区分开来。java在执行普通的方法调用的时候&＃xff0c;可以通过找方法表&＃xff0c;再找到相应的code属性表&＃xff0c;最终解释执行代码&＃xff0c;那么&＃xff0c;对于native方法&＃xff0c;在class文件中&＃xff0c;并没有体现native代码在哪里&＃xff0c;只有一个“ACC_NATIVE”的标识&＃xff0c;那么在执行的时候改怎么找到动态链接库的代码呢&＃xff1f;

只能从System.loadLibrary()入手了&＃xff01;