|
JNI，全稱Java Native Interface，是用于讓運行在JVM中的Java代碼和運行在JVM外的Native代碼（主要是C或者C++）溝通的橋梁。代碼編寫者即可以使用JNI從Java的程序中調(diào)用Native代碼，又可以從Native程序中調(diào)用Java代碼。這樣，編程人員可以將低階的代碼邏輯包裝到高階的程序框架中，獲得高性能高效率的同時保證了代碼框架的高抽象性。 在Android中，僅有以下類庫是允許在JNI中使用的： libc (C library) headers libm (math library) headers JNI interface headers libz (Zlib compression) headers liblog (Android logging) header OpenGL ES 1.1 (3D graphics library) headers (since 1.6) A Minimal set of headers for C++ support JNI本身僅僅是一個把兩者融合的工具，作為編程者需要做的，就是在Java代碼和Native代碼中按照固定的格式告訴JNI如何調(diào)用對方。在Android中，有兩種方式可以調(diào)用JNI，一種是Google release的專門針對Android Native開發(fā)的工具包，叫做NDK。去Android網(wǎng)站上下載該工具包后，就可以通過閱讀里面的文檔來setup一個新的包含Native代碼的工程，創(chuàng)建自己的Android.mk文件，編譯等等；另一種是完整的源碼編譯環(huán)境 ，也就是通過git從官方網(wǎng)站獲取完全的Android源代碼平臺。這個平臺中提供有基于make的編譯系統(tǒng)。更多細(xì)節(jié)請參考這里。不管選擇以上兩種方法的哪一個，都必須編寫自己的Android.mk文件，有關(guān)該文件的編寫請參考相關(guān)文檔。 下面通過一個簡單的使用例子來講解JNI。Android給C和C++提供的是兩套不同的Native API，本文僅以C++舉例說明。假設(shè)這么一個需求，Java代碼需要打印一個字符串，而該字符串需要Native代碼計算生成。對應(yīng)的JNI流程是這樣的： 1. 在準(zhǔn)備打印字符串的Android類中，添加兩段代碼。 第一段是： private native String getPrintStr(); 這一行代碼的目的是告訴JNI，這個Java文件中有這么一個函數(shù)，該函數(shù)是在Native代碼中執(zhí)行的，Native代碼會返回一個字符串供Java代碼來輸出。 第二段是： try {System.loadLibrary(“LIBNAME” } catch (UnsatisfiedLinkError ule) {Log.e(TAG, “Could not load native library”);} 這兩行代碼是告訴JNI，你需要找的所有Native函數(shù)都在libLIBNAME.so這個動態(tài)庫中。注意JNI會自動補全lib和so給LIBNAME，你只需要提供LIBNAME給loadLibrary就行了。在最后執(zhí)行的時候，JNI會先找到這個動態(tài)庫，然后找里面的OnLoad函數(shù)，具體注冊流程由OnLoad函數(shù)接管。 關(guān)于如何確定這個LIBNAME，和如何定義OnLoad函數(shù)，下面就會講。 2. 上面的第一步是告訴JNI，java代碼需要和Native代碼交互，同時把在哪里找，找什么都通知了。接下來的事情就由Native端接管。如果把上面的getPrintString函數(shù)申明比作原型，那么本地代碼中的具體函數(shù)定義就應(yīng)該和該原型匹配，JNI才能知道具體在哪里執(zhí)行代碼。具體來說，應(yīng)該有一個對應(yīng)的Native函數(shù)，有和Java中定義的函數(shù)同樣的參數(shù)列表以及返回值。另外，還需要有某種機制讓JNI將兩者相互映射，方便參數(shù)和返回值的傳遞。在老版的JNI中，這是通過丑陋的命名匹配實現(xiàn)的，比如說在Java中定義的函數(shù)名是getPrintStr, 該函數(shù)屬于package java.come.android.xxx，那么中對應(yīng)Native代碼中的函數(shù)名就應(yīng)該是Java_com_android_xxx_getPrintStr。這樣給開發(fā)人員帶來了很多不便?？梢杂胘avah命令來生成對應(yīng)Java code中定義函數(shù)的Native code版本header文件，從中得知傳統(tǒng)的匹配方法是如何做的。具體過程如下： 通過SDK的方式編譯Java代碼。 找到Eclipse的工程目錄，進入bin目錄下。這里是編譯出的java文件所對應(yīng)的class文件所在。 假設(shè)包括Native函數(shù)調(diào)用的java文件屬于com.android.xxx package，名字叫test.java，那么在bin下執(zhí)行javah -jni com.android.xxx.test 執(zhí)行完后，可以看到一個新生成的header文件，名字為com_android_xxx_test.h。打開后會發(fā)現(xiàn)已經(jīng)有一個函數(shù)申明，函數(shù)名為java_com_android_xxx_test_getPrintStr。這個名字就包括了該函數(shù)所對應(yīng)Java版本所在的包，文件以及名稱。這就是JNI傳統(tǒng)的確定名字的方法。 值得注意的是，header文件中不僅包含了基于函數(shù)名的映射信息，還包含了另一個重要信息，就是signature。一個函數(shù)的signature是一個字符串，描述了這個函數(shù)的參數(shù)和返回值。其中”()” 中的字符表示參數(shù)，后面的則代表返回值。例如”()V” 就表示void Func(); “(II)V” 表示 void Func(int, int); 數(shù)組則以”["開始，用兩個字符表示。 具體的每一個字符的對應(yīng)關(guān)系如下： 字符 Java類型 C類型 V void void I jint int Z jboolean boolean J jlong long D jdouble double F jfloat float B jbyte byte C jchar char S jshort short 上面的都是基本類型。如果Java函數(shù)的參數(shù)是class，則以"L"開頭，以";"結(jié)尾，中間是用"/" 隔開的包及類名。而其對應(yīng)的C函數(shù)名的參數(shù)則為jobject。 一個例外是String類，其對應(yīng)的類為jstring。舉例： Ljava/lang/String; String jstring Ljava/net/Socket; Socket jobject 如果JAVA函數(shù)位于一個嵌入類，則用$作為類名間的分隔符。例如 "(Ljava/lang/String;Landroid/os/FileUtils$FileStatus;)Z" 這個signature非常重要，是下面要介紹的新版命名匹配方法的關(guān)鍵點之一。所以，即使傳統(tǒng)的命名匹配已經(jīng)不再使用，javah這一步操作還是必須的，因為可以從中得到Java代碼中需要Native執(zhí)行的函數(shù)的簽名，以供后面使用。 3. 在新版（版本號大于1.4）的JNI中，Android提供了另一個機制來解決命名匹配問題，那就是JNI_OnLoad。正如前面所述，每一次JNI執(zhí)行Native代碼，都是通過調(diào)用JNI_OnLoad實現(xiàn)的。下面的代碼是針對本例的OnLoad代碼： /* Returns the JNI version on success, -1 on failure. jint JNI_OnLoad(JavaVM* vm, void* reserved) { JNIEnv* env = NULL; jint result = -1; if (vm->GetEnv((void**) &env, JNI_VERSION_1_4) != JNI_OK) { LOGE("ERROR: GetEnv failed"); goto bail; } assert(env != NULL); if (!register_Test(env)) { LOGE("ERROR: Test native registration failed"); goto bail; } /* success -- return valid version number */ result = JNI_VERSION_1_4; bail: return result; } 分析這個函數(shù)。首先，OnLoad通過GetEnv函數(shù)獲取JNI的環(huán)境對象，然后通過register_Test來注冊Native函數(shù)。register_Test的實現(xiàn)如下： int register_Test(JNIEnv *env) { const char* const ClassPathName ＝ "com/android/xxx/test"; return registerNativeMethods(env, ClassPathName, TestMethods, sizeof(TestMethods) / sizeof(TestMethods[0])); } 在這里，ClassPathName是Java類的全名，包括package的全名。只是用 “/” 代替 ”.” 。然后我們把類名以及TestMethods這個參數(shù)一同送到registerNativeMethods這個函數(shù)中注冊。這個函數(shù)是基于JNI_OnLoad的命名匹配方式的重點。 在JNI中，代碼編寫者通過函數(shù)signature名和映射表的配合，來告訴JNI_OnLoad，你要找的函數(shù)在Native代碼中是如何定義的（signature），以及在哪定義的（映射表）。關(guān)于signature的生成和含義，在上面已經(jīng)介紹。而映射表，是Android使用的一種用于映射Java和C/C++函數(shù)的數(shù)組，這個數(shù)組的類型是JNINativeMethod，定義為： typedef struct { const char* name; const char* signature; void* fnPtr; } JNINativeMethod; 其中，第一個變量是Java代碼中的函數(shù)名稱。第二個變量是該函數(shù)對應(yīng)的Native signature。第三個變量是該函數(shù)對應(yīng)的Native函數(shù)的函數(shù)指針。例如，在上面register_Test的函數(shù)實現(xiàn)中，傳給registerNativeMethods的參數(shù)TestMethods就是映射表，定義如下： static JNINativeMethod TestMethods[] = { {“getPrintStr”, “()Ljava/lang/String”, (void*)test_getPrintStr} }; 其中g(shù)etPrintStr是在Java代碼中定義的函數(shù)的名稱，()Ljava/lang/String是簽名，因為該函數(shù)無參數(shù)傳入，并返回一個String。test_getPrintStr則是我們即將在Native code中定義的函數(shù)名稱。該映射表和前面定義的類名ClassPathName一起傳入registerNativeMethods： static int registerNativeMethods(JNIEnv* env, const char* className, JNINativeMethod* Methods, int numMethods) { jclass clazz; clazz = env->FindClass(className); if (clazz == NULL) { LOGE(“Native registration unable to find class ‘%s’”, className); return JNI_FALSE； } if (env->RegisterNatives(clazz, gMethods, numMethods) < 0) { LOGE(“RegisterNatives failed for ‘%s’”, className); return JNI_FALSE; } return JNI_TRUE; } 在這里，先load目標(biāo)類，然后注冊Native函數(shù)，然后返回狀態(tài)。 可以看出，通過映射表方式，Java code中的函數(shù)名不須再和Native code中的函數(shù)名呆板對應(yīng)。只需要將函數(shù)注冊進映射表中，Native code的函數(shù)編寫就有了很大的靈活性。雖說和前一種傳統(tǒng)的匹配方法比，這種方式并沒有效率上的改進，因為兩者本質(zhì)上都是從JNI load開始做函數(shù)映射。但是這一種register的方法極大降低了兩邊的耦合性，所以實際使用中會受歡迎得多。比如說，由于映射表是一個<名稱，函數(shù)指針>對照表，在程序執(zhí)行時，可多次調(diào)用registerNativeMethods()函數(shù)來更換本地函數(shù)指針，而達(dá)到彈性抽換本地函數(shù)的目的。 4. 接下來本應(yīng)介紹test_getPrintStr。但在此之前，簡單介紹Android.mk，也就是編譯NDK所需要的Makefile，從而完成JNI信息鏈的講解。Android.mk可以基于模版修改，里面重要的變量包括： LOCAL_C_INCLUDES：包含的頭文件。這里需要包含JNI的頭文件。 LOCAL_SRC_FILES: 包含的源文件。 LOCAL_MODULE：當(dāng)前模塊的名稱，也就是第一步中我們提到的LIBNAME。注意這個需要加上lib前綴，但不需要加.so后綴，也就是說應(yīng)該是libLIBNAME。 LOCAL_SHARED_LIBRARIES：當(dāng)前模塊需要依賴的共享庫。 LOCAL_PRELINK_MODULE：該模塊是否被啟動就加載。該項設(shè)置依具體程序的特性而定。 5. 至此，JNI作為橋梁所需要的所有信息均已就緒。JNI知道在調(diào)用Java代碼中的getPrintStr函數(shù)時，需要執(zhí)行Native代碼。于是通過System.loadLibrary所加載的libLIBNAME.so找到OnLoad入口。在OnLoad中，JNI發(fā)現(xiàn)了函數(shù)映射表，發(fā)現(xiàn)getPrintStr對應(yīng)的Native函數(shù)是test_getPrintStr。于是JNI將參數(shù)（如果有的話）傳遞給test_getPrintStr并執(zhí)行，再將返回值（如果有的話）傳回Java中的getPrintStr。 6. 用于最后測試的test_getPrintStr函數(shù)實現(xiàn)如下： const jstring testStr = env->NewStringUTF(“hello, world”); return testStr; 然后在Java代碼中打印出返回的字符串即可。這個網(wǎng)頁詳細(xì)介紹了env可以調(diào)用的所有方法。 7. 關(guān)于測試時使用Log。調(diào)用JNI進行Native Code的開發(fā)有兩種環(huán)境，完整源碼環(huán)境以及NDK。兩種環(huán)境對應(yīng)的Log輸出方式也并不相同，差異則主要體現(xiàn)在需要包含的頭文件中。如果是在完整源碼編譯環(huán)境下，只要include <utils/Log.h>頭文件（位于Android-src/system/core/include/cutils），就可以使用對應(yīng)的LOGI、LOGD等方法了，當(dāng)然LOG_TAG，LOG_NDEBUG等宏值需要自定義。如果是在NDK環(huán)境下編譯，則需要include <android/log.h>頭文件（位于ndk/android-ndk-r4/platforms/android-8/arch-arm/usr/include/android/），另外自己定義宏映射，例如： #include <android/log.h> #ifndef LOG_TAG #define LOG_TAG “MY_LOG_TAG” #endif #define LOGD(…) __android_log_print(ANDROID_LOG_DEBUG,LOG_TAG,__VA_ARGS__) #define LOGI(…) __android_log_print(ANDROID_LOG_INFO,LOG_TAG,__VA_ARGS__) #define LOGW(…) __android_log_print(ANDROID_LOG_WARN,LOG_TAG,__VA_ARGS__) #define LOGE(…) __android_log_print(ANDROID_LOG_ERROR,LOG_TAG,__VA_ARGS__) #define LOGF(…) __android_log_print(ANDROID_LOG_FATAL,LOG_TAG,__VA_ARGS__) 另外，在Android.mk文件中對類庫的應(yīng)用在兩種環(huán)境下也不相同。如果是NDK環(huán)境下，需要包括 LOCAL_LDLIBS := -llog 而在完整源碼環(huán)境下，則需要包括 LOCAL_SHARED_LIBRARIES := libutils libcutils 8. 如果希望知道如何在Native中訪問Java類的私有域和方法，請參考這篇文章 |
|
|
