Android Native 代碼開發學習筆記

JNI，全稱Java Native Interface，是用於讓運行在JVM中的Java代碼和運行在JVM外的Native代碼（主要是C或者C++）溝通的橋樑。代碼編寫者即可以使用 JNI從Java的程序中調用Native代碼，又可以從Native程序中調用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如何調用對方。在 Android中，有兩種方式可以調用JNI，一種是Google release的專門針對Android Native開發的工具包，叫做NDK。去Android網站上下載該工具包後，就可以通過閱讀裏面的文檔來setup一個新的包含Native代碼的工程，創建自己的Android.mk文件，編譯等等；另一種是完整的源碼編譯環境，也就是通過git從官方網站獲取完全的Android源代碼平臺。這個平臺中提供有基於make的編譯系統。更多細節請參考這裏。不管選擇以上兩種方法的哪一個，都必須編寫自己的Android.mk文件，有關該文件的編寫請參考相關文檔。

下面通過一個簡單的使用例子來講解JNI。Android給C和C++提供的是兩套不同的Native API，本文僅以C++舉例說明。假設這麼一個需求，Java代碼需要打印一個字符串，而該字符串需要Native代碼計算生成。對應的JNI流程是這樣的：

1. 在準備打印字符串的Android類中，添加兩段代碼。

第一段是：

private native String getPrintStr();

這一行代碼的目的是告訴JNI，這個Java文件中有這麼一個函數，該函數是在Native代碼中執行的，Native代碼會返回一個字符串供Java代碼來輸出。

第二段是：

try {
    System.loadLibrary(“LIBNAME”);
}catch (UnsatisfiedLinkError ule) {
    Log.e(TAG, “Could not load native library”);
}

這兩行代碼是告訴JNI，你需要找的所有Native函數都在libLIBNAME.so這個動態庫中。注意JNI會自動補全 lib和so給LIBNAME，你只需要提供LIBNAME給loadLibrary就行了。在最後執行的時候，JNI會先找到這個動態庫，然後找裏面的 OnLoad函數，具體註冊流程由OnLoad函數接管。

關於如何確定這個LIBNAME，和如何定義OnLoad函數，下面就會講。

2. 上面的第一步是告訴JNI，java代碼需要和Native代碼交互，同時把在哪裏找，找什麼都通知了。接下來的事情就由Native端接管。如果把上面的getPrintString函數申明比作原型，那麼本地代碼中的具體函數定義就應該和該原型匹配，JNI才能知道具體在哪裏執行代碼。具體來說，應該有一個對應的Native函數，有和Java中定義的函數同樣的參數列表以及返回值。另外，還需要有某種機制讓JNI將兩者相互映射，方便參數和返回值的傳遞。在老版的JNI中，這是通過醜陋的命名匹配實現的，比如說在Java中定義的函數名是getPrintStr, 該函數屬於package java.come.android.xxx，那麼中對應Native代碼中的函數名就應該是 Java_com_android_xxx_getPrintStr。這樣給開發人員帶來了很多不便。可以用javah命令來生成對應Java code中定義函數的Native code版本header文件，從中得知傳統的匹配方法是如何做的。具體過程如下：

通過SDK的方式編譯Java代碼。
找到Eclipse的工程目錄，進入bin目錄下。這裏是編譯出的java文件所對應的class文件所在。
假設包括Native函數調用的java文件屬於com.android.xxx package，名字叫test.java，那麼在bin下執行javah -jni com.android.xxx.test

執行完後，可以看到一個新生成的header文件，名字爲com_android_xxx_test.h。打開後會發現已經有一個函數申明，函數名爲java_com_android_xxx_test_getPrintStr。這個名字就包括了該函數所對應Java版本所在的包，文件以及名稱。這就是JNI傳統的確定名字的方法。

值得注意的是，header文件中不僅包含了基於函數名的映射信息，還包含了另一個重要信息，就是signature。一個函數的signature是一個字符串，描述了這個函數的參數和返回值。其中”()” 中的字符表示參數，後面的則代表返回值。例如”()V” 就表示void Func(); “(II)V” 表示 void Func(int, int); 數組則以”["開始，用兩個字符表示。

具體的每一個字符的對應關係如下：

字符	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函數的參數是class，則以"L"開頭，以";"結尾，中間是用"/" 隔開的包及類名。而其對應的C函數名的參數則爲jobject。一個例外是String類，其對應的類爲jstring。舉例：

Ljava/lang/String; String jstring

Ljava/net/Socket; Socket jobject

如果JAVA函數位於一個嵌入類，則用$作爲類名間的分隔符。例如 "(Ljava/lang/String;Landroid/os/FileUtils$FileStatus;)Z"

這個signature非常重要，是下面要介紹的新版命名匹配方法的關鍵點之一。所以，即使傳統的命名匹配已經不再使用，javah這一步操作還是必須的，因爲可以從中得到Java代碼中需要Native執行的函數的簽名，以供後面使用。

3. 在新版（版本號大於1.4）的JNI中，Android提供了另一個機制來解決命名匹配問題，那就是JNI_OnLoad。正如前面所述，每一次JNI執行Native代碼，都是通過調用JNI_OnLoad實現的。下面的代碼是針對本例的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;

}

分析這個函數。首先，OnLoad通過GetEnv函數獲取JNI的環境對象，然後通過register_Test來註冊Native函數。register_Test的實現如下：

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這個參數一同送到registerNativeMethods這個函數中註冊。這個函數是基於 JNI_OnLoad的命名匹配方式的重點。

在JNI中，代碼編寫者通過函數signature名和映射表的配合，來告訴JNI_OnLoad，你要找的函數在 Native代碼中是如何定義的（signature），以及在哪定義的（映射表）。關於signature的生成和含義，在上面已經介紹。而映射表，是 Android使用的一種用於映射Java和C/C++函數的數組，這個數組的類型是JNINativeMethod，定義爲：

typedef struct {
const char* name;
const char* signature;
void* fnPtr;
} JNINativeMethod;

其中，第一個變量是Java代碼中的函數名稱。第二個變量是該函數對應的Native signature。第三個變量是該函數對應的Native函數的函數指針。例如，在上面register_Test的函數實現中，傳給 registerNativeMethods的參數TestMethods就是映射表，定義如下：

static JNINativeMethod TestMethods[] = {
    {“getPrintStr”, “()Ljava/lang/String”, (void*)test_getPrintStr}
};

其中getPrintStr是在Java代碼中定義的函數的名稱，()Ljava/lang/String是簽名，因爲該函數無參數傳入，並返回一個String。test_getPrintStr則是我們即將在Native code中定義的函數名稱。該映射表和前面定義的類名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目標類，然後註冊Native函數，然後返回狀態。

可以看出，通過映射表方式，Java code中的函數名不須再和Native code中的函數名呆板對應。只需要將函數註冊進映射表中，Native code的函數編寫就有了很大的靈活性。雖說和前一種傳統的匹配方法比，這種方式並沒有效率上的改進，因爲兩者本質上都是從JNI load開始做函數映射。但是這一種register的方法極大降低了兩邊的耦合性，所以實際使用中會受歡迎得多。比如說，由於映射表是一個<名稱，函數指針>對照表，在程序執行時，可多次調用registerNativeMethods()函數來更換本地函數指針，而達到彈性抽換本地函數的目的。

4. 接下來本應介紹test_getPrintStr。但在此之前，簡單介紹Android.mk，也就是編譯NDK所需要的Makefile，從而完成JNI信息鏈的講解。Android.mk可以基於模版修改，裏面重要的變量包括：

LOCAL_C_INCLUDES：包含的頭文件。這裏需要包含JNI的頭文件。
LOCAL_SRC_FILES: 包含的源文件。
LOCAL_MODULE：當前模塊的名稱，也就是第一步中我們提到的LIBNAME。注意這個需要加上lib前綴，但不需要加.so後綴，也就是說應該是libLIBNAME。
LOCAL_SHARED_LIBRARIES：當前模塊需要依賴的共享庫。
LOCAL_PRELINK_MODULE：該模塊是否被啓動就加載。該項設置依具體程序的特性而定。

5. 至此，JNI作爲橋樑所需要的所有信息均已就緒。JNI知道在調用Java代碼中的getPrintStr函數時，需要執行Native代碼。於是通過 System.loadLibrary所加載的libLIBNAME.so找到OnLoad入口。在OnLoad中，JNI發現了函數映射表，發現 getPrintStr對應的Native函數是test_getPrintStr。於是JNI將參數（如果有的話）傳遞給 test_getPrintStr並執行，再將返回值（如果有的話）傳回Java中的getPrintStr。

6. 用於最後測試的test_getPrintStr函數實現如下：

const jstring testStr = env->NewStringUTF(“hello, world”);
return testStr;

然後在Java代碼中打印出返回的字符串即可。這個網頁詳細介紹了env可以調用的所有方法。

7. 關於測試時使用Log。調用JNI進行Native Code的開發有兩種環境，完整源碼環境以及NDK。兩種環境對應的Log輸出方式也並不相同，差異則主要體現在需要包含的頭文件中。如果是在完整源碼編譯環境下，只要include <utils/Log.h>頭文件（位於Android-src/system/core/include/cutils），就可以使用對應的LOGI、LOGD等方法了，當然LOG_TAG，LOG_NDEBUG等宏值需要自定義。如果是在NDK環境下編譯，則需要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文件中對類庫的應用在兩種環境下也不相同。如果是NDK環境下，需要包括

LOCAL_LDLIBS := -llog

而在完整源碼環境下，則需要包括

LOCAL_SHARED_LIBRARIES := libutils libcutils

8. 如果希望知道如何在Native中訪問Java類的私有域和方法，請參考這篇文章

原文轉自：http://www.kunli.info/2011/08/21/android-native-code-study-note/

Android Native 代碼開發學習筆記

認知提升的方法

C#開源的兩款功能強大的錄屏神器

螞蟻面試：Springcloud核心組件的底層原理，你知道多少？

前端 Vue yarn.lock文件：詳解和使用指南

Android Native 代碼開發學習筆記

在線安裝eclipse中html/jsp/xml editor插件（非常可靠），eclipseeditor

appcompat v21: material design for pre-Lollipop devices!

AlertDialog自定義樣式

社會化登陸-第三方SDK

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結