深入理解JNI.pptVIP

数据类型转换 为了验证刚儿说的那句话，我们还是以MediaScanner为例，看看这个类里面的processFile这个函数： //java层processFile三个参数如下 private native void processFile(String path, String mimeType, MediaScannerClient client); //JNI层对应函数，左后3个参数与processFile的参数对应 static void android_media_MediaScanner_processFile( JNIEnv *env, jobject thiz, jstring path, jstring mimeType, jobject client) 从上面这段代码可以发现： Java的String类型对应JNI层为jString类型 Java的MediaScannerClient类型在JNI层对应为jobject 这里看到，java中的processFile有3个参数，但JNI层对应的函数会有五个参数了？第一个参数JNIENV是什么？第二个参数jobject代表java层的MediaScanner对象，它表示实在哪个MediaScanner对象上调用processFile. JNIENV介绍 JNIENV是一个与线程相关的代表JNI环境的结构体，下图展示了JNIENV的内部结构 JNIEnv* 虚拟机内部数据结构 JNI内部函数指针1 JNI内部函数指针2 JNI内部函数指针3 JNI内部函数指针数组 JNI内部函数 JNI内部函数 JNI内部函数 从上图可知：JNIEnv实际提供了一些JNI系统函数，通过这些函数可以做到： 1.调用java的函数 2.操作jobect对象很多事情 其实你可以把它看作是native层调用java层的一个工具。 JNIENV介绍 JNIEnv有几个设计的原则：第一、JNIEnv指针被设计成了Thread Local Storage(TLS线程本地存储)变量，也就 是说每一个Thread, JNIEnv变量都有独立的对象。这样做的原因主要 是考虑到： 由于JVM要运行在多个平台（除了主流的Windows,Linux等平台),JNI内部实现很多要依赖到TLS， 为了减少对TLS的依赖，所有TLS based的 数据都会存放于JNIEnv中。这样相当于只依赖一个TLS based的变量JNIEnv。由于JNIEnv指针是TLS的，所以你不能把Thead#1使用的JNIEnv给Thread#2使用。 第二、JNIEnv中定义了一组函数指针，c/c++ Native程序是通过这些函数指针操纵Java数据。这样设计的好处是：你的c/c++ 程序不需要依赖任何函数库，或者DLL。由于JVM可能由不同的厂商实现，不同厂商有自己不同的JNI实现，如果要求这些厂商暴露约定好的一些头文件和库，这不是灵活的设计。而且使用函数指针表的另外一个好处是： JVM可以根据启动参数动态替换JNI实现。比如：类似于C库，JNI实现为了性能起见，并没有对调用者传入的参数进行检查。但是在调试阶段，也许这种检查是很必要的，帮助你尽早发现BUG。例如如果你使用IBM JDK，你可以指定JVM参数–Xcheck:jni，告诉JVM使用带检查的JNI实现。 JNIENV介绍 通过前面对JNIEnv设计原则讲解可以看出，JNIEnv是一个与线程相关的变量，也就是说，线程A有一个JNIEnv,线程B也有一个JNIENV，他们彼此之间相互独立。同时JNIEnv是native函数转换成JNI函数由虚拟机传进来的。 那么，现在有一种情况，当后台程序收到一个网络消息，而这个过程需要由native层主动调用java层函数时，JNIEnv从何而来？根据前面的介绍可知，我们不能再线程A里用线程B的JNIEnv结构体，也不能保存另外的一个线程JNIEnv到后台程序里。这又怎么