正如代碼中注釋的那樣，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層需要把Java函數名稱（包括包名）中的“.”換成“_”。也就是通過這種方式，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::樣例文件** ~~~ /* DO NOT EDIT THIS FILE - it is machinegenerated */ #include <jni.h> //必須包含這個頭文件，否則編譯通不過 /* Header for class android_media_MediaScanner*/ #ifndef _Included_android_media_MediaScanner #define _Included_android_media_MediaScanner #ifdef __cplusplus extern "C" { #endif ...... 略去一部分注釋內容 //processFile的JNI函數 JNIEXPORT void JNICALLJava_android_media_MediaScanner_processFile (JNIEnv *, jobject, jstring,jstring, jobject); ......//略去一部分注釋內容 //native_init對應的JNI函數 JNIEXPORT void JNICALLJava_android_media_MediaScanner_native_1init (JNIEnv*, jclass); #ifdef __cplusplus } #endif #endif ~~~ 從上面代碼中可以發現，native_init和processFile的JNI層函數被聲明成： ~~~ //Java層函數名中如果有一個”_”的話，轉換成JNI后就變成了”_l”。 JNIEXPORT void JNICALLJava_android_media_MediaScanner_native_1init JNIEXPORT void JNICALLJava_android_media_MediaScanner_processFile ~~~ 需解釋一下，靜態方法中native函數是如何找到對應的JNI函數的。其實，過程非常簡單： - **當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的結構，其定義如下： ~~~ typedef struct { //Java中native函數的名字，不用攜帶包的路徑。例如“native_init“。 constchar* name; //Java函數的簽名信息，用字符串表示，是參數類型和返回值類型的組合。 const char* signature; void* fnPtr; //JNI層對應函數的函數指針，注意它是void*類型。 } JNINativeMethod; ~~~ 應該如何使用這個結構體呢？來看MediaScanner JNI層是如何做的，代碼如下所示： **android_media_MediaScanner.cpp** ~~~ //定義一個JNINativeMethod數組，其成員就是MS中所有native函數的一一對應關系。 static JNINativeMethod gMethods[] = { ...... { "processFile" //Java中native函數的函數名。 //processFile的簽名信息，簽名信息的知識，后面再做介紹。 "(Ljava/lang/String;Ljava/lang/String;Landroid/media/MediaScannerClient;)V", (void*)android_media_MediaScanner_processFile //JNI層對應函數指針。 }, ...... { "native_init", "()V", (void *)android_media_MediaScanner_native_init }, ...... }; //注冊JNINativeMethod數組 int register_android_media_MediaScanner(JNIEnv*env) { //調用AndroidRuntime的registerNativeMethods函數，第二個參數表明是Java中的哪個類 returnAndroidRuntime::registerNativeMethods(env, "android/media/MediaScanner", gMethods, NELEM(gMethods)); } ~~~ AndroidRunTime類提供了一個registerNativeMethods函數來完成注冊工作，下面看registerNativeMethods的實現，代碼如下： **AndroidRunTime.cpp** ~~~ int AndroidRuntime::registerNativeMethods(JNIEnv*env, constchar* className, const JNINativeMethod* gMethods, int numMethods) { //調用jniRegisterNativeMethods函數完成注冊 returnjniRegisterNativeMethods(env, className, gMethods, numMethods); } ~~~ 其中jniRegisterNativeMethods是Android平臺中，為了方便JNI使用而提供的一個幫助函數，其代碼如下所示： **JNIHelp.c** ~~~ int jniRegisterNativeMethods(JNIEnv* env, constchar* className, constJNINativeMethod* gMethods, int numMethods) { jclassclazz; clazz= (*env)->FindClass(env, className); ...... //實際上是調用JNIEnv的RegisterNatives函數完成注冊的 if((*env)->RegisterNatives(env, clazz, gMethods, numMethods) < 0) { return -1; } return0; } ~~~ wow，好像很麻煩啊！其實動態注冊的工作，只用兩個函數就能完成。總結如下： ~~~ env指向一個JNIEnv結構體，它非常重要，后面會討論它。classname為對應的Java類名，由于 JNINativeMethod中使用的函數名并非全路徑名，所以要指明是哪個類。 */ jclass clazz = (*env)->FindClass(env, className); //調用JNIEnv的RegisterNatives函數，注冊關聯關系。 (*env)->RegisterNatives(env, clazz, gMethods,numMethods); ~~~ 所以，在自己的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** ~~~ jint JNI_OnLoad(JavaVM* vm, void* reserved) { //該函數的第一個參數類型為JavaVM,這可是虛擬機在JNI層的代表喔，每個Java進程只有一個 //這樣的JavaVM JNIEnv* env = NULL; jintresult = -1; if(vm->GetEnv((void**) &env, JNI_VERSION_1_4) != JNI_OK) { gotobail; } ...... //動態注冊MediaScanner的JNI函數。 if(register_android_media_MediaScanner(env) < 0) { goto bail; } ...... returnJNI_VERSION_1_4;//必須返回這個值，否則會報錯。 } ~~~ JNI函數注冊的內容介紹完了。下面來關注JNI技術中其他的幾個重要部分。 * * * * * **注意** ：JNI層代碼中一般要包含jni.h這個頭文件。Android源碼中提供了一個幫助頭文件JNIHelp.h，它內部其實就包含了jni.h，所以我們在自己的代碼中直接包含這個JNIHelp.h即可。 * * * * *