深入理解JNI

本章主要内容

·? 通过一个实例，介绍JNI技术和在使用中应注意的问题。

本章涉及的源代码文件名称及位置

以下是本章分析的源代码文件名称及其位置。

·? MediaScanner.java

framework/base/media/java/src/android/media/MediaScanner.java

·? android_media_MediaScanner.cpp

framework/base/media/jni/MediaScanner.cpp

·? android_media_MediaPlayer.cpp

framework/base/media/jni/android_media_MediaPlayer.cpp

·? AndroidRunTime.cpp

framework/base/core/jni/AndroidRunTime.cpp

·? JNIHelp.c

dalvik/libnativehelper/JNIHelp.c

2.1? 概述

JNI。是Java Native Interface的缩写，中文为Java本地调用。通俗地说，JNI是一种技术。通过这样的技术能够做到以下两点：

·? Java程序中的函数能够调用Native语言写的函数，Native一般指的是C/C++编写的函数。

·? Native程序中的函数能够调用Java层的函数，也就是在C/C++程序中能够调用Java的函数。

在平台无关的Java中，为什么要创建一个和Native相关的JNI技术呢？这岂不是破坏了Java的平台无关特性吗？本人认为，JNI技术的推出可能是出于以下几个方面的考虑：

·? 承载Java世界的虚拟机是用Native语言写的。而虚拟机又执行在详细平台上，所以虚拟机本身无法做到平台无关。然而。有了JNI技术，就能够对Java层屏蔽详细的虚拟机实现上的差异了。这样，就能实现Java本身的平台无关特性。

事实上Java一直在使用JNI技术，仅仅是我们平时较少用到罢了。

·? 早在Java语言诞生前，非常多程序都是用Native语言写的，它们遍布在软件世界的各个角落。Java出世后，它受到了追捧，并迅速得到发展，但仍无法对软件世界彻底改朝换代。于是才有了折中的办法。既然已经有Native模块实现了相关功能。那么在Java中通过JNI技术直接使用它们就可以了，免得落下反复制造轮子的坏名声。另外，在一些要求效率和速度的场合还是须要Native语言參与的。

在Android平台上，JNI就是一座将Native世界和Java世界间的天堑变成通途的桥。来看图2-1，它展示了Android平台上JNI所处的位置：

图2-1? Android平台中JNI示意图

由上图可知。JNI将Java世界和Native世界紧密地联系在一起了。在Android平台上尽情使用Java开发的程序猿们不要忘了。假设没有JNI的支持，我们将寸步难行！

俗话说，百闻不如一见，就来见识一下JNI技术吧。

?

2.2 ?通过实例学习JNI

初次接触JNI，感觉最奇妙的就是。Java居然能够调用Native的函数，可它是怎么做到的呢？网上有非常多介绍JNI的资料。因为Android大量使用了JNI技术。本节就将通过源代码中的一处实例。来学习相关的知识。并了解它是怎样调用Native的函数的。

这个样例，是和MediaScanner相关的。

在本书的最后一章，会详细分析它的工作原理。这里先看和JNI相关的部分，如图2-2所看到的：

图2-2? MediaScanner和它的JNI

将图2-2与图2-1结合来看，能够知道：

·? Java世界相应的是MediaScanner。而这个MediaScanner类有一些函数是须要由Native层实现的。

·? JNI层相应的是libmedia_jni.so。

media_jni是JNI库的名字，当中。下划线前的“media”是Native层库的名字。这里就是libmedia库。

下划线后的”jni“表示它是一个JNI库。

注意。JNI库的名字能够随便取。只是Android平台基本上都採用“lib模块名_jni.so”的命名方式。

·? Native层相应的是libmedia.so。这个库完毕了实际的功能。

·? MediaScanner将通过JNI库libmedia_jni.so和Native的libmedia.so交互。

从上面的分析中还可知道：

·? JNI层必须实现为动态库的形式。这样Java虚拟机才干载入它并调用它的函数。

以下来看MediaScanner。

2.2.1 ?Java层的MediaScanner分析

来看MediaScanner（简称MS）的源代码，这里将提取出和JNI有关的部分。其代码例如以下所看到的：

[-->MediaScanner.java]

·? 上面代码中列出了两个比較重要的要点：

1. 载入JNI库

前面说过，如Java要调用Native函数。就必须通过一个位于JNI层的动态库才干做到。顾名思义，动态库就是执行时载入的库，那么是什么时候。在什么地方载入这个库呢？

这个问题没有标准答案，原则上是在调用native函数前，不论什么时候、不论什么地方载入都能够。

通行的做法是。在类的static语句中载入，通过调用System.loadLibrary方法就能够了。

这一点。在上面的代码中也见到了，我们以后就按这样的方法编写代码就可以。另外，System.loadLibrary函数的參数是动态库的名字。即media_jni。系统会自己主动依据不同的平台拓展成真实的动态库文件名称，比如在Linux系统上会拓展成libmedia_jni.so。而在Windows平台上则会拓展成media_jni.dll。

攻克了JNI库载入的问题，再来来看第二个关键点。

2.? Java的native函数和总结

从上面代码中能够发现，native_init和processFile函数前都有Java的keywordnative，它表示这两个函数将由JNI层来实现。

Java层的分析到此结束。

JNI技术也非常照应Java程序猿。仅仅要完毕以下两项工作就能够使用JNI了，它们是：

·? 载入相应的JNI库。

·? 声明由keywordnative修饰的函数。

所以对于Java程序猿来说。使用JNI技术真的是太easy了。只是JNI层可没这么轻松。以下来看MS的JNI层分析。

2.2.2 ?JNI层的MediaScanner分析

MS的JNI层代码在android_media_MediaScanner.cpp中。例如以下所看到的：

[-->android_media_MediaScanner.cpp]

上面是MS的JNI层代码。不知道读者看了以后是否会产生些疑惑？

我想，最大的疑惑可能是，怎么会知道Java层的native_init函数相应的是JNI层的android_media_MediaScanner_native_init函数呢？以下就来回答这个问题。

1.???注冊JNI函数

正如代码中凝视的那样，native_init函数相应的JNI函数是android_media_MediaScanner_native_init，但是细心的读者可能要问了，你怎么知道native_init函数相应的是这个android_media_MediaScanner_native_init。而不是其它的呢？莫非是依据函数的名字？

大家知道。native_init函数位于android.media这个包中，它的全路径名应该是android.media.MediaScanner.native_init，而JNI层函数的名字是android_media_MediaScanner_native_init。因为在Native语言中，符号“.”有着特殊的意义，所以JNI层须要把“.”换成“_”。

也就是通过这样的方式，native_init找到了自己JNI层的本家兄弟android.media.MediaScanner.native_init。

上面的问题事实上讨论的是JNI函数的注冊问题。“注冊”之意就是将Java层的native函数和JNI层相应的实现函数关联起来。有了这样的关联，调用Java层的native函数时，就能顺利转到JNI层相应的函数执行了。而JNI函数的注冊实际上有两种方法，以下分别做介绍。

（1）静态方法

我们从网上找到的与JNI有的关资料，一般都会介绍怎样使用这样的方法完毕JNI函数的注冊。这样的方法就是依据函数名来找相应的JNI函数。

这样的方法须要Java的工具程序javah參与，总体流程例如以下：

·? 先编写Java代码，然后编译生成.class文件。

·? 使用Java的工具程序javah，如javah–o output packagename.classname ，这样它会生成一个叫output.h的JNI层头文件。

当中packagename.classname是Java代码编译后的class文件，而在生成的output.h文件中。声明了相应的JNI层函数。仅仅要实现里面的函数就可以。

这个头文件的名字一般都会使用packagename_class.h的样式，比如MediaScanner相应的JNI层头文件就是android_media_MediaScanner.h。

以下。来看这样的方式生成的头文件：

[-->android_media_MediaScanner.h::样例文件]

从上面代码中能够发现。native_init和processFile的JNI层函数被声明成：

需解释一下，静态方法中native函数是怎样找到相应的JNI函数的。事实上。过程非常easy：

·? 当Java层调用native_init函数时。它会从相应的JNI库Java_android_media_MediaScanner_native_linit。假设没有。就会报错。假设找到，则会为这个native_init和Java_android_media_MediaScanner_native_linit建立一个关联关系。事实上就是保存JNI层函数的函数指针。以后再调用native_init函数时，直接使用这个函数指针就能够了，当然这项工作是由虚拟机完毕的。

从这里能够看出。静态方法就是依据函数名来建立Java函数和JNI函数之间的关联关系的，它要求JNI层函数的名字必须遵循特定的格式。

这样的方法也有几个弊端，它们是：

·? 须要编译全部声明了native函数的Java类。每一个生成的class文件都得用javah生成一个头文件。

·? javah生成的JNI层函数名特别长，书写起来非常不方便。

·? 初次调用native函数时要依据函数名字搜索相应的JNI层函数来建立关联关系，这样会影响执行效率。

有什么办法能够克服上面三种弊端吗？依据上面的介绍。Java native函数是通过函数指针来和JNI层函数建立关联关系的。

假设直接让native函数知道JNI层相应函数的函数指针。不就万事大吉了吗？这就是以下要介绍的另外一种方法：动态注冊法。

（2）动态注冊

既然Java native函数数和JNI函数是一一相应的。那么是不是会有一个结构来保存这样的关联关系呢？答案是肯定的。在JNI技术中，用来记录这样的一一相应关系的，是一个叫JNINativeMethod的结构，其定义例如以下：

应该怎样使用这个结构体呢？来看MediaScanner JNI层是怎样做的，代码例如以下所看到的：

[-->android_media_MediaScanner.cpp]

AndroidRunTime类提供了一个registerNativeMethods函数来完毕注冊工作，以下看registerNativeMethods的实现。代码例如以下：

[-->AndroidRunTime.cpp]

当中jniRegisterNativeMethods是Android平台中。为了方便JNI使用而提供的一个帮助函数，其代码例如以下所看到的：

[-->JNIHelp.c]

wow，好像非常麻烦啊！事实上动态注冊的工作。仅仅用两个函数就能完毕。总结例如以下：

所以。在自己的JNI层代码中使用这样的方法，就能够完毕动态注冊了。

这里另一个非常棘手的问题：这些动态注冊的函数在什么时候、什么地方被谁调用呢？好了，不卖关子了。直接给出该问题的答案：

·? 当Java层通过System.loadLibrary载入完JNI动态库后，紧接着会查找该库中一个叫JNI_OnLoad的函数，假设有，就调用它，而动态注冊的工作就是在这里完毕的。

所以，假设想使用动态注冊方法，就必须要实现JNI_OnLoad函数，仅仅有在这个函数中，才有机会完毕动态注冊的工作。静态注冊则没有这个要求，可我建议读者也实现这个JNI_OnLoad函数，因为有一些初始化工作是能够在这里做的。

那么。libmedia_jni.so的JNI_OnLoad函数是在哪里实现的呢？因为多媒体系统非常多地方都使用了JNI，所以码农把它放到android_media_MediaPlayer.cpp中了，代码例如以下所看到的：

[-->android_media_MediaPlayer.cpp]

JNI函数注冊的内容介绍完了。以下来关注JNI技术中其它的几个重要部分。

2. 数据类型转换

通过前面的分析，攻克了JNI函数的注冊问题。以下来研究数据类型转换的问题。

在Java中调用native函数传递的參数是Java数据类型。那么这些參数类型到了JNI层会变成什么呢？

Java数据类型分为基本数据类型和引用数据类型两种。JNI层也是差别对待这二者的。先来看基本数据类型的转换。

（1）基本类型的转换

基本类型的转换非常easy。可用表2-1表示：

表2-1? 基本数据类型转换关系表

上面列出了Java基本数据类型和JNI层数据类型相应的转换关系。非常easy。只是，应务必注意，转换成Native类型后相应数据类型的字长。比如jchar在Native语言中是16位，占两个字节。这和普通的char占一个字节的情况全然不一样。

接下来看Java引用数据类型的转换。

（2）引用数据类型的转换

引用数据类型的转换如表2-2所看到的：

表2-2? Java引用数据类型转换关系表

由上表可知：

·? 除了Java中基本数据类型的数组、Class、String和Throwable外，其余全部Java对象的数据类型在JNI中都用jobject表示。

这一点太让人吃惊了！看processFile这个函数：

从上面这段代码中能够发现：

·? Java的String类型在JNI层相应为jstring。

·? Java的MediaScannerClient类型在JNI层相应为jobject。

假设对象类型都用jobject表示，就好比是Native层的void*类型一样，对码农来说，是全然透明的。既然是透明的，那该怎样使用和操作它们呢？在回答这个问题之前。再来仔细看看上面那个android_media_MediaScanner_processFile函数。代码例如以下：

上面的代码。引出了以下几节的主角JNIEnv。

3. JNIEnv介绍

JNIEnv是一个和线程相关的，代表JNI环境的结构体。图2-3展示了JNIEnv的内部结构：

图2-3? JNIEnv内部结构简图

从上图可知。JNIEnv实际上就是提供了一些JNI系统函数。通过这些函数能够做到：

·? 调用Java的函数。

·? 操作jobject对象等非常多事情。

后面小节中将详细介绍怎么使用JNIEnv中的函数。这里，先介绍一个关于JNIEnv的重要知识点。

上面提到说JNIEnv。是一个和线程有关的变量。也就是说。线程A有一个JNIEnv，线程B有一个JNIEnv。因为线程相关，所以不能在线程B中使用线程A的JNIEnv结构体。读者可能会问，JNIEnv不都是native函数转换成JNI层函数后由虚拟机传进来的吗？使用传进来的这个JNIEnv总不会错吧？是的，在这样的情况下使用当然不会出错。

只是当后台线程收到一个网络消息，而又须要由Native层函数主动回调Java层函数时。JNIEnv是从何而来呢？依据前面的介绍可知。我们不能保存另外一个线程的JNIEnv结构体。然后把它放到后台线程中来用。这该怎样是好？

还记得前面介绍的那个JNI_OnLoad函数吗？它的第一个參数是JavaVM。它是虚拟机在JNI层的代表。代码例如以下所看到的：

正如上面代码所说，不论进程中有多少个线程。JavaVM却是独此一份，所以在不论什么地方都能够使用它。

那么。JavaVM和JNIEnv又有什么关系呢？答案例如以下：

·? 调用JavaVM的AttachCurrentThread函数，就可得到这个线程的JNIEnv结构体。

这样就能够在后台线程中回调Java函数了。

·? 另外，后台线程退出前，须要调用JavaVM的DetachCurrentThread函数来释放相应的资源。

再来看JNIEnv的作用。

4. 通过JNIEnv操作jobject

前面提到过一个问题，即Java的引用类型除了少数几个外。终于在JNI层都用jobject来表示对象的数据类型，那么该怎样操作这个jobject呢？

从另外一个角度来解释这个问题。

一个Java对象是由什么组成的？当然是它的成员变量和成员函数了。

那么，操作jobject的本质就应当是操作这些对象的成员变量和成员函数。所以应先来看与成员变量及成员函数有关的内容。

（1）jfieldID 和jmethodID的介绍

我们知道，成员变量和成员函数是由类定义的，它是类的属性，所以在JNI规则中，用jfieldID 和jmethodID 来表示Java类的成员变量和成员函数。它们通过JNIEnv的以下两个函数能够得到：

当中。jclass代表Java类，name表示成员函数或成员变量的名字，sig为这个函数和变量的签名信息。如前所看到的，成员函数和成员变量都是类的信息，这两个函数的第一个參数都是jclass。

MS中是怎么使用它们的呢？来看代码，例如以下所看到的：

[-->android_media_MediaScanner.cpp::MyMediaScannerClient构造函数]

在上面代码中，将scanFile和handleStringTag函数的jmethodID保存为MyMediaScannerClient的成员变量。为什么这里要把它们保存起来呢？这个问题涉及一个事关程序执行效率的知识点：

·? 假设每次操作jobject前都去查询jmethoID或jfieldID的话将会影响程序执行的效率。所以我们在初始化的时候。就能够取出这些ID并保存起来以供兴许使用。

取出jmethodID后。又该怎么用它呢？

（2）使用jfieldID和jmethodID

以下再看一个样例，其代码例如以下所看到的：

[-->android_media_MediaScanner.cpp::MyMediaScannerClient的scanFile]

明确了，通过JNIEnv输出的CallVoidMethod。再把jobject、jMethodID和相应參数传进去，JNI层就能够调用Java对象的函数了。

实际上JNIEnv输出了一系列相似CallVoidMethod的函数。形式例如以下：

当中type是相应Java函数的返回值类型，比如CallIntMethod、CallVoidMethod等。

上面是针对非static函数的，假设想调用Java中的static函数，则用JNIEnv输出的CallStatic<Type>Method系列函数。

如今。我们已了解了怎样通过JNIEnv操作jobject的成员函数，那么怎么通过jfieldID操作jobject的成员变量呢？这里，直接给出总体解决方式，例如以下所看到的：

通过本节的介绍。相信读者已了解jfieldID和jmethodID的作用，也知道怎样通过JNIEnv的函数来操作jobject了。尽管jobject是透明的，但有了JNIEnv的帮助，还是能轻松操作jobject背后的实际对象了。

5. jstring介绍

Java中的String也是引用类型，只是因为它的使用非常频繁。所以在JNI规范中单独创建了一个jstring类型来表示Java中的String类型。尽管jstring是一种独立的数据类型，但是它并没有提供成员函数供操作。相比而言，C++中的string类就有自己的成员函数了。

那么该怎么操作jstring呢？还是得依靠JNIEnv提供的帮助。

这里看几个有关jstring的函数：

·? 调用JNIEnv的NewString(JNIEnv *env, const jchar*unicodeChars,jsize len)，能够从Native的字符串得到一个jstring对象。事实上，能够把一个jstring对象看成是Java中String对象在JNI层的代表，也就是说。jstring就是一个Java String。但因为Java String存储的是Unicode字符串，所以NewString函数的參数也必须是Unicode字符串。

·? 调用JNIEnv的NewStringUTF将依据Native的一个UTF-8字符串得到一个jstring对象。

在实际工作中，这个函数用得最多。

·? 上面两个函数将本地字符串转换成了Java的String对象，JNIEnv还提供了GetStringChars和GetStringUTFChars函数，它们能够将Java String对象转换成本地字符串。当中GetStringChars得到一个Unicode字符串，而GetStringUTFChars得到一个UTF-8字符串。

·? 另外，假设在代码中调用了上面几个函数，在做完相关工作后。就都须要调用ReleaseStringChars或ReleaseStringUTFChars函数相应地释放资源，否则会导致JVM内存泄露。这一点和jstring的内部实现有关系，读者写代码时务必注意这个问题。

为了加深印象，来看processFile是怎么做的：

[-->android_media_MediaScanner.cpp]

6. JNI类型签名的介绍

先来看动态注冊中的一段代码：

上面代码中的JNINativeMethod已经见过了，只是当中那个非常长的字符串"(Ljava/lang/String;Ljava/lang/String;Landroid/media/MediaScannerClient;)V"是什么意思呢？

依据前面的介绍可知，它是Java中相应函数的签名信息。由參数类型和返回值类型共同组成。只是为什么须要这个签名信息呢？

·? 这个问题的答案比較简单。因为Java支持函数重载，也就是说，能够定义同名但不同參数的函数。但仅仅依据函数名。是没法找到详细函数的。

为了解决问题，JNI技术中就使用了參数类型和返回值类型的组合。作为一个函数的签名信息，有了签名信息和函数名，就能非常顺利地找到Java中的函数了。

JNI规范定义的函数签名信息看起来非常别扭，只是习惯就好了。它的格式是：

(參数1类型标示參数2类型标示...參数n类型标示)返回值类型标示。

来看processFile的样例：

函数签名不仅看起来麻烦。写起来更麻烦。略微写错一个标点就会导致注冊失败。

所以，在详细编码时，读者能够定义字符串宏，这样改起来也方便。

表2-3是常见的类型标示：

表2-3? 类型标示示意表

上面列出了一些经常使用的类型标示。请读者注意，假设Java类型是数组，则标示中会有一个“[”，另外，引用类型（除基本类型的数组外）的标示最后都有一个“;”。

再来看一个小样例，如表2-4所看到的：

表2-4? 函数签名小样例

请读者结合表2-3和表2-4左栏的内容写出相应的Java函数。

尽管函数签名信息非常easy写错。但Java提供一个叫javap的工具能帮助生成函数或变量的签名信息，它的用法例如以下：

javap –s -p xxx。当中xxx为编译后的class文件，s表示输出内部数据类型的签名信息，p表示打印全部函数和成员的签名信息，而默认仅仅会打印public成员和函数的签名信息。

有了javap。就不用死记硬背上面的类型标示了。

7. 垃圾回收

我们知道，Java中创建的对象最后是由垃圾回收器来回收和释放内存的，可它对JNI有什么影响呢？以下看一个样例：

[-->垃圾回收样例]

上面的做法肯定会有问题，因为和save_thiz相应的Java层中的MediaScanner非常有可能已经被垃圾回收了，也就是说，save_thiz保存的这个jobject可能是一个野指针，如使用它，后果会非常严重。

可能有人要问，将一个引用类型进行赋值操作，它的引用计数不会添加吗？而垃圾回收机制仅仅会保证那些没有被引用的对象才会被清理。问得对。但假设在JNI层使用以下这样的语句。是不会添加引用计数的。

那该怎么办？不必操心。JNI规范已非常好地攻克了这一问题，JNI技术一共提供了三种类型的引用。它们各自是：

·? Local Reference：本地引用。在JNI层函数中使用的非全局引用对象都是Local Reference。它包括函数调用时传入的jobject、在JNI层函数中创建的jobject。LocalReference最大的特点就是，一旦JNI层函数返回。这些jobject就可能被垃圾回收。

·? Global Reference：全局引用，这样的对象如不主动释放。就永远不会被垃圾回收。

·? Weak Global Reference：弱全局引用，一种特殊的GlobalReference。在执行过程中可能会被垃圾回收。所以在程序中使用它之前，须要调用JNIEnv的IsSameObject推断它是不是被回收了。

平时用得最多的是Local Reference和Global Reference，以下看一个实例。代码例如以下所看到的：

[-->android_media_MediaScanner.cpp::MyMediaScannerClient构造函数]

每当JNI层想要保存Java层中的某个对象时。就能够使用Global Reference，使用完后记住释放它就能够了。这一点非常easy理解。以下要讲有关LocalReference的一个问题，还是先看实例。代码例如以下所看到的：

[-->android_media_MediaScanner.cpp::MyMediaScannerClient的scanFile]

所以，没有及时回收的Local Reference也许是进程占用过多的一个原因，请务必注意这一点。

8. JNI中的异常处理

JNI中也有异常，只是它和C++、Java的异常不太一样。当调用JNIEnv的某些函数出错后，会产生一个异常，但这个异常不会中断本地函数的执行，直到从JNI层返回到Java层后，虚拟机才会抛出这个异常。

尽管在JNI层中产生的异常不会中断本地函数的执行，但一旦产生异常后，就仅仅能做一些资源清理工作了（比如释放全局引用。或者ReleaseStringChars）。假设这时调用除上面所说函数之外的其它JNIEnv函数。则会导致程序死掉。

来看一个和异常处理有关的样例，代码例如以下所看到的：

[-->android_media_MediaScanner.cpp::MyMediaScannerClient的scanFile函数]

JNI层函数能够在代码中截获和改动这些异常，JNIEnv提供了三个函数进行帮助：

·? ExceptionOccured函数，用来推断是否发生异常。

·? ExceptionClear函数。用来清理当前JNI层中发生的异常。

·? ThrowNew函数。用来向Java层抛出异常。

异常处理是JNI层代码必须关注的事情。读者在编写代码时务小心对待。

2.3 ?本章小结

本章通过一个实例介绍了JNI技术中的几个重要方面。包括：

·? JNI函数注冊的方法。

·? Java和JNI层数据类型的转换。

·? JNIEnv和jstring的用法，以及JNI中的类型签名。

·? 最后介绍了垃圾回收在JNI层中的使用，以及异常处理方面的知识。

相信掌握了上面的知识后，我们会对JNI技术有一个比較清晰的认识。

这里，还要建议读者再认真阅读一下JDK文档中的《Java Native Interface Specification》，它完整和仔细地阐述了JNI技术的各个方面，堪称深入学习JNI的权威指南。