一Java Native Interface
我们知道cpu只认得“0101101”类似这种符号,C、C++这些代码最终都得通过编译、汇编成二进制代码,cpu才能识别。而Java比C、C++又多了一层虚拟机,过程也复杂许多。Java代码经过编译成class文件、虚拟机装载等步骤最终在虚拟机中执行。class文件里面就是一个结构复杂的表,而最终告诉虚拟机怎么执行的就靠里面的字节码说明。
Java虚拟机在执行的时候,可以采用解释执行和编译执行的方式执行,但最终都是转化为机器码执行。
Java虚拟机运行时的数据区,包括方法区、虚拟机栈、堆、程序计数器、本地方法栈。
问题来了,按我们目前的理解,如果是解释执行,那么方法区中应该存的是字节码,那执行的时候,通过JNI动态装载的c、c++库,怎么加载进来的?
二 java native 关键字起的作用
- 有一个java类,有一个native方法和非native方法
public class FileUtils {
static {
System.loadLibrary("native-lib");
}
public static native void diff(String path,String pattern_Path,int file_number );
public static void diff2(String path,String pattern_Path,int file_number ){}
}
- javac 生产class文件,(可拖动到AS中去查看)
javac FileUtils.java
- javap查看
javap -s -p -v FileUtils.class
打印结果:
多了一个 **ACC_NATIVE:**标志
- 普通的“add”方法是直接把字节码放到code属性表中,而native方法,与普通的方法通过一个标志“ACC_NATIVE”区分开来。
- java在执行普通的方法调用的时候,可以通过找方法表,再找到相应的code属性表,最终解释执行代码
- 那么,对于native方法,在class文件中,并没有体现native代码在哪里,只有一个“ACC_NATIVE”的标识,那么在执行的时候改怎么找到动态链接库的代码呢?
三. System.loadLibrary()
---->Runtime.loadLibrary0
--->分两步:
----->1. 找到so库文件
两种方案:
1. ClassLoader
通过打印,知道实际的ClassLoder是PathClassLoader
----->findLibrary
---->this.pathList = new DexPathList(this, dexPath, libraryPath, optimizedDirectory);
---->DexPathList.java
---->findLibrary
---->分析构造函数
解释路径
2. ClassLoader为空
----->getLibPaths()
----->System.mapLibraryName //根据库类型 添加libxxx.so 还是xxx.dll
----->2. 加载so库文件
----->Runtime.java
---->doLoad(filename, loader);
----->//libcore/ojluni/src/main/native/Runtime.c
--->Runtime_nativeLoad
预留动态注册:
jniRegisterNativeMethods
JVM_NativeLoad
---->//art/runtime/openjdkjvm/OpenjdkJvm.cc
---->LoadNativeLibrary()
---->sym = library->FindSymbol("JNI_OnLoad", nullptr);//在我们要加载so库中查找JNI_OnLoad方法,如果没有系统就认为是静态注册方式进行的,直接返回true,代表so库加载成功,如果找到JNI_OnLoad就会调用JNI_OnLoad方法,JNI_OnLoad方法中一般存放的是方法注册的函数,所以如果采用动态注册就必须要实现JNI_OnLoad方法,否则调用java中申明的native方法时会抛出异常,下面有JNI_OnLoad的实现
----->JNI_OnLoadFn jni_on_load = reinterpret_cast<JNI_OnLoadFn>(sym);
----->IsBadJniVersion(version)
------>version != JNI_VERSION_1_2 && version != JNI_VERSION_1_4 && version != JNI_VERSION_1_6;
四 关键方法
synchronized void loadLibrary0(ClassLoader loader, String libname) {
if (libname.indexOf((int)File.separatorChar) != -1) {
throw new UnsatisfiedLinkError(
"Directory separator should not appear in library name: " + libname);
}//判断传入的库名称是否合法,比如我们的库是libxxx.so,我们只需要传入xxx就可以了
String libraryName = libname;
if (loader != null) {//如果类加载器不为空
String filename = loader.findLibrary(libraryName);//查找是否存在我们需要的库文件
if (filename == null) {
// It's not necessarily true that the ClassLoader used
// System.mapLibraryName, but the default setup does, and it's
// misleading to say we didn't find "libMyLibrary.so" when we
// actually searched for "liblibMyLibrary.so.so".
throw new UnsatisfiedLinkError(loader + " couldn't find \"" +
System.mapLibraryName(libraryName) + "\"");
}//不存在库文件则抛出异常
String error = doLoad(filename, loader);//如果库文件存在,就加载
if (error != null) {
throw new UnsatisfiedLinkError(error);
}//加载库文件失败,抛出异常
return;
}
JNIEXPORT jstring JNICALL
Runtime_nativeLoad(JNIEnv* env, jclass ignored, jstring javaFilename,
jobject javaLoader, jstring javaLibrarySearchPath)
{
return JVM_NativeLoad(env, javaFilename, javaLoader, javaLibrarySearchPath);//调用JVM_NativeLoad方法
}//nativeLoad方法在本地的实现
void register_java_lang_Runtime(JNIEnv* env) {
jniRegisterNativeMethods(env, "java/lang/Runtime", gMethods, NELEM(gMethods));
}//注册gMethods中的方法,这个函数是直接由虚拟机调用
typedef struct {
const char* name; /*Java 中函数的名字*/
const char* signature; /*描述了函数的参数和返回值*/
void* fnPtr; /*函数指针,指向 C 函数*/
} JNINativeMethod;