Android JNI

轉貼 JNI 與 Android VM 之關係

JNI is the Java Native Interface. Java Native Interface (JNI) 標準是Java 平台的一部分,它允許 Java 和其他語言的 code 可以進行溝通。而 JNI 提供的通道是雙向的,即 Java 可以使用 C/C++ code 中的功能,而 C/C++ code 也可以使用到 VM 上的 Java AP 的功能.

在 Android 的應用層級類別都是用 Java 撰寫的,這些 Java 類別轉譯為 Dex 型式的Bytecode 之後,必須仰賴 Dalvik 虛擬機器 (VM: Virtual Machine) 來執行之。

在執行 Java 類別的過程中,如果 Java 類別需要與 C 組件溝通時,VM 就會去載入 C 組件,然後讓 Java 的函數順利地呼叫到 C 組件的函數。此時,VM 扮演著橋樑的角色,讓 Java 與 C 組件能透過標準的 JNI 介面而相互溝通。那麼 Java 程式又如何要求 VM 去載入所指定的 C 組件呢 ?
可使用下述指令: System.loadLibrary(*.so的檔名);

看看 Android 所提供的 MediaPlayer.java 類別:
public class MediaPlayer{    
    static {
        System.loadLibrary("media_jni");
    }
 ……
}
要求 VM 去載入 Android 的 /system/lib/libmedia_jni.so 檔案。
載入 *.so 檔之後,Java 類別與 *.so 檔就匯合起來,一起執行了。

當 VM 執行到 System.loadLibrary() 函數時,首先會去執行 C 組件裡的 JNI_OnLoad()函數。
它的用途有二:

(1) 告訴 VM 此 C 組件使用那一個 JNI 版本。如果你的 *.so 檔沒有提供 JNI_OnLoad()函數,VM 會默認該 *.so 檔是使用最老的 JNI 1.1 版本。由於新版的 JNI 做了許多擴充,如果需要使用 JNI 的新版功能,例如 JNI 1.4 的 java.nio.ByteBuffer 就必須藉由 JNI_OnLoad() 函數來告知 VM。

(2) 由於 VM 執行到 System.loadLibrary() 函數時,就會立即先呼叫 JNI_OnLoad(),所以 C 組件的開發者可以藉由 JNI_OnLoad() 來進行 C 組件內的初期值之設定(Initialization)。

當 VM 載入 libmedia_jni.so 檔案時,就呼叫 JNI_OnLoad() 函數。
接著 JNI_OnLoad() 呼叫 register_android_media_MediaPlayer() 函數。
此時就會呼叫到 AndroidRuntime::registerNativeMethods() 函數,向 VM (即AndroidRuntime) 登記 gMethods[] 表格所含的本地函數了。 簡而言之,registerNativeMethods() 函數的用途有二:
(1) 更有效率去找到函數。
(2) 可在執行期間進行抽換。由於gMethods[]是一個<名稱,函數指標>對照表,在程式執行時,
可多次呼叫 registerNativeMethods() 函數來更換本地函數之指標,而達到彈性抽換函數。

我們可以在 frameworks/base/media/jni/ 找到 sample code。
依照下面的步驟可以實現一個非常簡單的 JNI:

(1)在 development 目錄下新增目錄 hellolib,並 add hellolib.c and Android.mk。hellolib.c 的內容如下:
#include <jni.h>
#define LOG_TAG "TestLib"
#undef LOG

#include <utils/Log.h>

JNIEXPORT void JNICALL 
Java_com_test_TestHelloLib_printHello(JNIEnv * env, jobject jobj)
{
   LOGD("Hello LIB!\n");
}
注意這裡的函數名需要按照 JNI 的規範,Java_com_test_TestHelloLib_printHello 的命名對應後面在 java code中,package 名字是 com.test,class 名是 TestHelloLib,native 函數名是 printHello。
另外 log 是採用了 Android 所提供的 LOG 機制,這樣才能用 logcat 工具看到 log。

Android.mk 文件內容如下:
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_SRC_FILES:= hellolib.c
LOCAL_C_INCLUDES := $(JNI_H_INCLUDE)
LOCAL_SHARED_LIBRARIES := libutils
LOCAL_PRELINK_MODULE := false
LOCAL_MODULE := libhello
include $(BUILD_SHARED_LIBRARY)
該文件中的一些變量分別對應的含義如下:
LOCAL_SRC_FILES - 編譯的文件
LOCAL_C_INCLUDES - 需要包含的文件目錄 
LOCAL_SHARED_LIBRARIES - 鏈接時需要的 LIB
LOCAL_PRELINK_MODULE - 是否需要 Prelink 處理
LOCAL_MODULE - 編譯的目標
BUILD_SHARED_LIBRARY - 指明要編譯成動態庫

# cd $(YOUR_ANDROID) && make libhello
target Non-prelinked: libhello 
(out/target/product/generic/symbols/system/lib/libhello.so) 
target Strip: libhello 
(out/target/product/generic/obj/lib/libhello.so) 
Install: out/target/product/generic/system/lib/libhello.so 
編譯結果可得到位於 out/target/product/generic/system/lib/ 目錄的 libhello.so

(2)編寫 Java 來使用 JNI 方式呼叫 C。 修改的TestHelloLib.java文件:
package com.test; 
import android.app.Activity; 
import android.os.Bundle; 
public class TestHelloLib extends Activity { 
  /** Called when the activity is first created. */
  @Override 
  public void onCreate(Bundle savedInstanceState) {   
         super.onCreate(savedInstanceState); 
         setContentView(R.layout.main); 
         printHello(); 
  } 

  static { 
         System.loadLibrary("hello"); 
  } 

  private native void printHello(); 
} 
static { System.loadLibrary("hello"); } => 是用來 load 上面步驟中生成 libhello.so 。
這一步驟可生成 Android 開發者所熟悉的apk文件:TestHelloLib.apk。

(3)測試 TestHelloLib.apk and libhello.so。 將 libhello.so 上傳到 emulator 的 /system/lib 目錄。
運行 logcat 可以找到下面的 log 片斷:
D/dalvikvm( 174): +++ not scanning '/system/lib/libwebcore.so' 
D/dalvikvm( 174): +++ not scanning '/system/lib/libmedia_jni.so'  
D/TestLib ( 174): Hello LIB! 

About [ D/dalvikvm( 174): +++ not scanning '/system/lib/libmedia_jni.so' ] message,
this is a "DEBUG" message, not an error message.

Copy from Re: Dalvik error message (wrong cl)
This message occurs when there is an unresolved native method, and the VM has to go searching through every known shared library for a matching symbol. The class that caused the method resolution is in a different class loader from the one that loaded libmedia_jni.so, so the VM is letting you know that it's not going to search there. Native methods that are explicitly registered (e.g. during JNI_OnLoad) don't go through the dlsym() search and will never generate this message.

測試結果只要增加 JNI_OnLoad 就可以解決了^^"


參考資料:
JNI Examples for Android
OPhone 平台的 JNI
Android JNI 實例
Android-JNI

0 Responses

Say something :)