安卓JNI精細化講解，讓你徹底了解JNI（二）：用法決議

目錄

用法決議
├── 1、JNI函式
│ ├── 1.1、extern "C"
│ ├── 1.2、JNIEXPORT、JNICALL
│ ├── 1.3、函式名
│ ├── 1.4、JNIEnv
│ ├── 1.5、jobject
├── 2、Java、JNI、C/C++基本型別映射關系
├── 3、JNI描述符（簽名）
├── 4、函式靜態注冊、動態注冊
│ ├── 4.1、動態注冊原理
│ ├── 4.2、靜態注冊原理
│ ├── 4.3、Java呼叫native的流程

當通過AndroidStudio創建了Native C++工程后，首先面對的是*.cpp檔案，對于不熟悉C/C++的開發人員而言，往往是望“類”興嘆，無從下手，為此，咱們系統的梳理一下JNI的用法，為后續Native開發做鋪墊，

1、JNI函式

#include <jni.h>
#include <string>

extern "C" JNIEXPORT jstring JNICALL
Java_com_qxc_testnativec_MainActivity_stringFromJNI(
        JNIEnv* env,
        jobject /* this */) {
    std::string hello = "Hello from C++";
    return env->NewStringUTF(hello.c_str());
}

通常，大家看到的JNI方法如上圖所示，方法結構與Java方法類似，同樣包含方法名、引數、回傳型別，只不過多了一些修飾詞、特定引數型別而已，

1.1、extern "C"

作用：避免編繹器按照C++的方式去編繹C函式

該關鍵字可以刪掉嗎？
我們不妨動手測驗一下：去掉extern “C” , 重新生成so，運行app，結果直接閃退了：

咱們反編譯so檔案看一下，原來去掉extern “C” 后，函式名字竟然被修改了：

//保留extern "C"
000000000000ea98 T 
Java_com_qxc_testnativec_MainActivity_stringFromJNI

//去掉extern "C"
000000000000eab8 T 
_Z40Java_com_qxc_testnativec_MainActivity_stringFromJNIP7_JNIEnvP8_jobject

原因是什么呢？
其實這跟C和C++的函式多載差異有關系：

1、C不支持函式的多載，編譯之后函式名不變；
2、C++支持函式的多載（這點與Java一致），編譯之后函式名會改變；

原因：在C++中，存在函式的多載問題，函式的識別方式是通過：函式名，函式的回傳型別，函式引數串列
三者組合來完成的，

所以，如果希望編譯后的函式名不變，應通知編譯器使用C的編譯方式編譯該函式（即：加上關鍵字：extern “C”），

擴展：
如果即想去掉關鍵字 extern “C”，又希望方法能被正常呼叫，真的不能實作嗎？

非也，還是有解決辦法的：“函式的動態注冊”，這個后面再介紹吧！！！

1.2、JNIEXPORT、JNICALL

作用：

JNIEXPORT 用來表示該函式是否可匯出（即：方法的可見性）
JNICALL 用來表示函式的呼叫規范（如：__stdcall）

我們通過JNIEXPORT、JNICALL關鍵字跳轉到jni.h中的定義，如下圖：

通過查看 jni.h 中的原始碼，原來JNIEXPORT、JNICALL是兩個宏定義

對于安卓開發者來說，宏可這樣理解：

├── 宏 JNIEXPORT 代表的就是右側的運算式： __attribute__ ((visibility ("default")))
├── 或者也可以說： JNIEXPORT 是右側運算式的別名

宏可表達的內容很多，如：一個具體的數值、一個規則、一段邏輯代碼等；

attribute___((visibility ("default"))) 描述的是“可見性”屬性 visibility

1、default ：表示外部可見，類似于public修飾符 (即：可以被外部呼叫)
2、hidden ：表示隱藏，類似于private修飾符 (即：只能被內部呼叫)
3、其他 ：略

如果，我們想使用hidden，隱藏我們寫的方法，可這么寫：

#include <jni.h>
#include <string>

extern "C" __attribute__ ((visibility ("hidden"))) jstring JNICALL
Java_com_qxc_testnativec_MainActivity_stringFromJNI(
        JNIEnv* env,
        jobject /* this */) {
    std::string hello = "Hello from C++";
    return env->NewStringUTF(hello.c_str());
}

重新編譯、運行，結果閃退了，
原因：函式Java_com_qxc_testnativec_MainActivity_stringFromJNI已被隱藏，而我們在java中呼叫該函式時，找不到該函式，所以拋出了例外，如下圖：

宏JNICALL 右邊是空的，說明只是個空定義，上面講了，宏JNICALL代表的是右邊定義的內容，那么，我們代碼也可直接使用右邊的內容（空）替換調JNICALL（即：去掉JNICALL關鍵字），編譯后運行，呼叫so仍然是正確的：

#include <jni.h>
#include <string>

extern "C" JNIEXPORT jstring
Java_com_qxc_testnativec_MainActivity_stringFromJNI(
        JNIEnv* env,
        jobject /* this */) {
    std::string hello = "Hello from C++";
    return env->NewStringUTF(hello.c_str());
}

JNICALL 知識擴展：

JNICALL的定義，并非所有平臺都像Linux一樣是空的，如windows平臺：
#ifndef _JAVASOFT_JNI_MD_H_  
#define _JAVASOFT_JNI_MD_H_  
#define JNIEXPORT __declspec(dllexport)  
#define JNIIMPORT __declspec(dllimport)  
#define JNICALL __stdcall  
typedef long jint;  
typedef __int64 jlong;  
typedef signed char jbyte;  
#endif

1.3、函式名

看到.cpp中的函式"Java_com_qxc_testnativec_MainActivity_stringFromJNI"，大部分開發人員都會有疑問：我們定義的native函式名stringFromJNI，為什么對應到cpp中函式名會變成這么長呢？

public native String stringFromJNI();

這跟JNI native函式的注冊方式有關

JNI Native函式有兩種注冊方式（后面會詳細介紹）：
1、靜態注冊：按照JNI介面規范的命名規則注冊；
2、動態注冊：在.cpp的JNI_OnLoad方法里注冊；

JNI介面規范的命名規則：

Java_<PackageName>_<ClassName>_<MethodName> 

當我們在Java中呼叫native方法時，JVM 也會根據這種命名規則來查找、呼叫native方法對應的 C 方法，

1.4、JNIEnv

JNIEnv 代表了Java環境，通過JNIEnv*就可以對Java端的代碼進行操作，如：
├──創建Java物件
├──呼叫Java物件的方法
├──獲取Java物件的屬性等

我們跳轉、查看JNIEnv的原始碼實作，如下圖：

JNIEnv指向_JNIEnv，而_JNIEnv是定義的一個C++結構體，里面包含了很多通過JNI介面（JNINativeInterface）物件呼叫的方法，

那么，我們通過JNIEnv操作Java端的代碼，主要使用哪些方法呢？

具體用法，后面案例再進行演示，

1.5、jobject

jobject 代表了定義native函式的Java類 或 Java類的實體：

├── 如果native函式是static，則代表類Class物件
├── 如果native函式非static，則代表類的實體物件

我們可以通過jobject訪問定義該native方法的成員方法、成員變數等，

2、Java、JNI、C/C++基本型別映射關系

上面，已經介紹了.cpp方法的基本結構、主要關鍵字，當我們定義了具體方法，寫C/C++方法實作時，會用到各種引數型別，那么，在JNI開發中，這些型別應該是怎么寫呢？
舉例：定義加、減、乘、除的方法

//加
jint addNumber(JNIEnv *env,jclass clazz,jint a,jint b){
     return a+b;
}
//減
jint subNumber(JNIEnv *env,jclass clazz,jint a,jint b){
     return a-b;
}
//乘
jint mulNumber(JNIEnv *env,jclass clazz,jint a,jint b){
     return a*b;
}
//除
jint divNumber(JNIEnv *env,jclass clazz,jint a,jint b){
     return a/b;
}

通過上面案例可以看到，幾個方法的后兩個引數、回傳值，型別都是 jint

jint 是JNI中定義的型別別名，對應的是Java、C++中的int型別

我們先原始碼跟蹤、看下jint的定義，jint 原來是 jni.h中 定義的 int32_t 的別名，如下圖：

根據 int32_t 查找，發現 int32_t 是 stdint.h中定義的 __int32_t的別名，如下圖：

再根據 __int32_t 查找，發現 __int32_t 是 stdint.h中定義的 int 的別名（這個也就是C/C++中的int型別了），如下圖：

Java 、C/C++都有一些常用的資料型別，分別是如何與JNI型別對應的呢？如下所示：

Java 、C/C++中的常用資料型別的映射關系表（通過原始碼跟蹤查找列出來的）

3、JNI描述符 (簽名)

JNI開發時，我們除了寫本地C/C++實作，還可以通過 JNIEnv *env 呼叫Java層代碼，如獲得某個欄位、獲取某個函式、執行某個函式等：

//獲得某類中定義的欄位id
jfieldID GetFieldID(jclass clazz, const char* name, const char* sig)
    { return functions->GetFieldID(this, clazz, name, sig); }

//獲得某類中定義的函式id
jmethodID GetMethodID(jclass clazz, const char* name, const char* sig)
    { return functions->GetMethodID(this, clazz, name, sig); }

上面的函式與Java的反射比較類似，引數：

clazz : 類的class物件
name : 欄位名、函式名
sig : 欄位描述符（簽名）、函式描述符（簽名）

寫過反射的開發人員對clazz、name這兩個引數應該比較熟悉，對sig稍微陌生一些，

sig 此處是指的：

1、如果是欄位，表示欄位型別的描述符
2、如果是函式，表示函式結構的描述符，即：每個引數型別描述符 + 回傳值型別描述符

舉例（ int 型別的描述符是 大寫的 I ）：

Java代碼：

public class Hello{
     public int property;
     public int fun(int param, int[] arr){
          return 100;
     }
}

JNI C/C++代碼：

JNIEXPORT void Java_Hello_test(JNIEnv* env, jobject obj){
    jclass myClazz = env->GetObjectClass(obj);
    jfieldId fieldId_prop = env -> GetFieldId(myClazz, "property", "I");
    jmethodId methodId_fun = env -> GetMethodId(myClazz, "fun", "(I[I)I");
}

由上面的示例可以看到，Java類中的欄位型別、函式定義分別對應的描述符：

int  型別 對應的是  I
fun  函式 對應的是  (I[I)I

其他型別的描述符(簽名)如下表：

4、函式靜態注冊、動態注冊

JNI開發中，我們一般定義了Java native方法，又寫了對應的C方法實作，
那么，當我們在Java代碼中呼叫Java native方法時，虛擬機是怎么知道并呼叫SO庫的對應的C方法的呢？

Java native方法與C方法的對應關系，其實是通過注冊實作的，Java native方法的注冊形式有兩種，一種是靜態注冊，另一種是動態注冊：

靜態注冊：按照JNI規范書寫函式名：java_類路徑_方法名（路徑用下劃線分隔）
動態注冊：JNI_OnLoad中指定Java Native函式與C函式的對應關系

兩種注冊方式的使用對比：

靜態注冊：

1、優缺點：
系統默認方式，使用簡單；
靈活性差（如果修改了java native函式所在類的包名或類名，需手動修改C函式名稱（頭檔案、源檔案））；

2、實作方式：
1）函式名可以根據規則手寫
2）也可使用javah命令自動生成

3、示例：
extern "C" JNIEXPORT jstring
Java_com_qxc_testnativec_MainActivity_stringFromJNI(
        JNIEnv* env,
        jobject /* this */) {
    std::string hello = "Hello from C++";
    return env->NewStringUTF(hello.c_str());
}

動態注冊：

1、優缺點：
函式名看著舒服一些，但是需要在C代碼中維護Java Native函式與C函式的對應關系；
靈活性稍高（如果修改了java native函式所在類的包名或類名，僅調整Java native函式的簽名資訊）

2、實作方式
env->RegisterNatives(clazz, gMethods, numMethods)

3、示例：
Java類定義Native函式：

package com.qxc.testpage;
public class JNITools {
    static {
        System.loadLibrary("jnidemo");
    }

    //加法
    public static native int  add(int a,int b);

    //減法
    public static native int sub(int a,int b);

    //乘法
    public static native int mul(int a,int b);

    //除法
    public static native int div(int a,int b);
}

.cpp中動態注冊：

JNIEXPORT jint JNI_OnLoad(JavaVM* vm, void* reserved){
    //列印日志
    __android_log_print(ANDROID_LOG_DEBUG,"JNITag","enter jni_onload");
    JNIEnv* env = NULL;
    jint result = -1;
    // 判斷是否正確
    if((*vm)->GetEnv(vm,(void**)&env,JNI_VERSION_1_6)!= JNI_OK){
        return result;
    }
    // 定義函式映射關系（引數1：java native函式，引數2：函式描述符，引數3：C函式）
    const JNINativeMethod method[]={
            {"add","(II)I",(void*)addNumber},
            {"sub","(II)I",(void*)subNumber},
            {"mul","(II)I",(void*)mulNumber},
            {"div","(II)I",(void*)divNumber}
    };
    //找到對應的JNITools類
    jclass jClassName=(*env)->FindClass(env,"com/qxc/testpage/JNITools");
    //開始注冊
    jint ret = (*env)->RegisterNatives(env,jClassName,method, 4);
     //如果注冊失敗，列印日志
    if (ret != JNI_OK) {
        __android_log_print(ANDROID_LOG_DEBUG, "JNITag", "jni_register Error");
        return -1;
    }
    return JNI_VERSION_1_6;
}

//加
jint addNumber(JNIEnv *env,jclass clazz,jint a,jint b){
     return a+b;
}
//減
jint subNumber(JNIEnv *env,jclass clazz,jint a,jint b){
     return a-b;
}
//乘
jint mulNumber(JNIEnv *env,jclass clazz,jint a,jint b){
     return a*b;
}
//除
jint divNumber(JNIEnv *env,jclass clazz,jint a,jint b){
     return a/b;
}

上面，帶著大家了解了兩種注冊方式的基本知識，接下來，咱們再深入了解一下動態注冊和靜態注冊的底層差異、以及實作原理，

4.1、動態注冊原理

動態注冊是Java代碼呼叫中System.loadLibray()時完成的

那么，我們先了解一下System.loadLibray加載動態庫時，底層究竟做了哪些操作：

底層原始碼：/dalvik/vm/Native.cpp

dvmLoadNativeCode() -> JNI_OnLoad()
//省略的代碼......
//將pNewEntry保存到gDvm全域變數nativeLibs中，下次可以直接通過快取獲取
SharedLib* pActualEntry = addSharedLibEntry(pNewEntry);
//省略的代碼......
//第一次加載so時，呼叫so中的JNI_OnLoad方法
vonLoad = dlsym(handle, "JNI_OnLoad");

通過System.loadLibray的流程圖，不難看出，Java中加載.so動態庫時，最侄訓呼叫so中的JNI_OnLoad方法，這也是為什么我們要在C的JNIEXPORT jint JNI_OnLoad(JavaVM vm, void* reserved)方法中注冊的原因，

接下來，咱們再深入了解一下動態注冊的具體流程：

如上圖所示：

流程1：是指執行 System.loadLibray函式；
流程2：是指底層默認呼叫so中的JNI_OnLoad函式；
流程3：是指開發人員在JNI_OnLoad中寫的注冊方法，例如： (*env)->RegisterNatives(env，.....)
流程4：需要重點講解一下：
├── 在Android中，不管是Java函式還是Java Native函式，它在虛擬機中對應的都是一個Method*物件
├── 如果是Java Native函式，那么Method*物件的nativeFunc會指向一個bridge函式dvmCallJNIMethod
├── 當呼叫Java Native函式時，就會執行該bridge函式，bridge函式的作用是呼叫該Java Native方法對應的
JNI方法，即: method.insns

流程4的主要作用，如圖所示，為Java Native函式對應的Method*物件，系結屬性，建立對應關系：
├── nativeFunc 指向函式 dvmCallJNIMethod（通常情況下）
├── insns 指向native層的C函式指標 （我們寫的C函式）

我們再從原始碼層面，重點分析一下動態注冊的流程3和流程4吧，

流程3：開發人員在JNI_OnLoad中寫的注冊方法，注冊對應的C函式

JNIEXPORT jint JNI_OnLoad(JavaVM* vm, void* reserved){
    //列印日志
    __android_log_print(ANDROID_LOG_DEBUG,"JNITag","enter jni_onload");
    JNIEnv* env = NULL;
    jint result = -1;
    // 判斷是否正確
    if((*vm)->GetEnv(vm,(void**)&env,JNI_VERSION_1_6)!= JNI_OK){
        return result;
    }
    // 定義函式映射關系（引數1：java native函式，引數2：函式描述符，引數3：C函式）
    const JNINativeMethod method[]={
            {"add","(II)I",(void*)addNumber},
            {"sub","(II)I",(void*)subNumber},
            {"mul","(II)I",(void*)mulNumber},
            {"div","(II)I",(void*)divNumber}
    };
    //找到對應的JNITools類
    jclass jClassName=(*env)->FindClass(env,"com/qxc/testpage/JNITools");
    //開始注冊
    jint ret = (*env)->RegisterNatives(env,jClassName,method, 4);
     //如果注冊失敗，列印日志
    if (ret != JNI_OK) {
        __android_log_print(ANDROID_LOG_DEBUG, "JNITag", "jni_register Error");
        return -1;
    }
    return JNI_VERSION_1_6;
}

//加
jint addNumber(JNIEnv *env,jclass clazz,jint a,jint b){
     return a+b;
}
//減
jint subNumber(JNIEnv *env,jclass clazz,jint a,jint b){
     return a-b;
}
//乘
jint mulNumber(JNIEnv *env,jclass clazz,jint a,jint b){
     return a*b;
}
//除
jint divNumber(JNIEnv *env,jclass clazz,jint a,jint b){
     return a/b;
}

C函式的定義比較簡單，共加減乘除4個函式，當動態注冊時，需呼叫函式 RegisterNatives(env,jClassName,method, 4)(該方法有不同引數的多個方法多載)，我們主要關注的引數：jclass clazz、JNINativeMethod* methods、jint nMethods

clazz 表示：定義Java Native方法的Java類；
methods 表示：Java Native方法與C方法的對應關系；
nMethods 表示：methods注冊方法的數量，一般設定成methods陣列的長度；

JNINativeMethod如何表示Java Native方法與C方法的對應關系的呢？查看其原始碼定義：

jni.h

//結構體
typedef struct {
    const char* name;   //Java 方法名稱
    const char* signature;  //Java 方法描述符(簽名)
    void*       fnPtr;  //C/C++方法實作
} JNINativeMethod;

了解了JNINativeMethod結構，那么，JNINativeMethod物件是如何與虛擬機中的Method*物件對應的呢？這個有點復雜了，咱們通過流程圖簡單描述一下吧：

如果還希望更清晰的了解底層原始碼的實作邏輯，可下載Android原始碼，自行分析一下吧，

4.2、靜態注冊原理

靜態注冊是在首次呼叫Java Native函式時完成的

如上圖所示：

流程1：Java代碼中呼叫Java Native函式；
流程2：獲得Method*物件，默認為該函式的Method*設定nativeFunc（dvmResolveNativeMethod）；
流程3：dvmResolveNativeMethod函式中按照特定名稱查找對應的C方法；
流程4：如果找到了對應的C方法，重新為該方法設定Method*屬性；

注意：當Java代碼中第二次再呼叫Java Native函式時，Method*的nativeFunc已經有值了
（即：dvmCallJNIMethod，可參考動態注冊流程內容），會直接執行Method*的nativeFunc的函式，不會在
重新執行特定名稱查找了，

4.3、Java呼叫native的流程

經過對動態注冊、靜態注冊的實作原理的梳理之后，再看Java代碼中呼叫Java native方法的流程圖，就比較簡單了：

1、如果是動態注冊的Java native函式，System.loadLibray時就已經設定好了Java native函式與C函式的對應關系，當Java代碼中呼叫Java native方法時，直接執行dvmCallJNIMethod橋函式即可（該函式中執行C函式），

2、如果是靜態注冊的Java native函式，當Java代碼中呼叫Java native方法時，默認為Method.nativeFunc賦值為dvmResolveNativeMethod，并按特定名稱查找C方法，重新賦值Method*，最終仍然是執行dvmCallJNIMethod橋函式（只不過Java代碼中第二次再呼叫靜態注冊的Java native函式時，不會再執行黃色部分的流程圖了）

標籤：Android

上一篇：安卓JNI精細化講解，讓你徹底了解JNI（一）：環境搭建與HelloWord

下一篇：安卓AlertDialog四種對話框的最科學撰寫用法