C、C++、Java？Java Native Interface(JNI)特輯——C反射java函數(shù)
java反射機(jī)制回顧
在上篇特輯中我們回顧了C語言的基本內(nèi)容，這次我們正式聊聊JNI。在此之前我覺得有必要回顧一下java的反射機(jī)制。
關(guān)于java反射機(jī)制的基本概念及API我就不重復(fù)了，百度講的比我好。簡單的來說，反射機(jī)制指的是程序在運(yùn)行時(shí)能夠獲取自身的信息。在java中，只要給定類的名字，?那么就可以通過反射機(jī)制來獲得類的所有信息。
為什么要用反射機(jī)制？直接創(chuàng)建對(duì)象不就可以了嗎，這就涉及到了動(dòng)態(tài)與靜態(tài)的概念：
靜態(tài)編譯：在編譯時(shí)確定類型，綁定對(duì)象,即通過。
動(dòng)態(tài)編譯：運(yùn)行時(shí)確定類型，綁定對(duì)象。動(dòng)態(tài)編譯最大限度發(fā)揮了java的靈活性，體現(xiàn)了多態(tài)的應(yīng)用，有以降低類之間的藕合性。一句話，反射機(jī)制的優(yōu)點(diǎn)就是可以實(shí)現(xiàn)動(dòng)態(tài)創(chuàng)建對(duì)象和編譯，體現(xiàn)出很大的靈活性，特別是在J2EE的開發(fā)中它的靈活性就表現(xiàn)的十分明顯。比如，一個(gè)大型的軟件，不可能一次就把把它設(shè)計(jì)的很完美，當(dāng)這個(gè)程序編譯后，發(fā)布了，當(dāng)發(fā)現(xiàn)需要更新某些功能時(shí)，我們不可能要用戶把以前的卸載，再重新安裝新的版本，假如
這樣的話，這個(gè)軟件肯定是沒有多少人用的。采用靜態(tài)的話，需要把整個(gè)程序重新編譯一次才可以實(shí)現(xiàn)功能的更新，而采用反射機(jī)制的話，它就可以不用卸載，只需要在運(yùn)行時(shí)才動(dòng)態(tài)的創(chuàng)建和編譯，就可以實(shí)現(xiàn)該功能。
它的缺點(diǎn)是對(duì)性能有影響。使用反射基本上是一種解釋操作，我們可以告訴JVM，我們希望做什么并且它滿足我們的要求。這類操作總是慢于只直接執(zhí)行相同的操作。
JNI開發(fā)流程
我們開發(fā)的宗旨是不依賴任何開發(fā)工具，所以我們eclipse創(chuàng)建安卓工程，使用命令行編譯C代碼，雖然不太方便但這是一種通用的方式，不依賴開發(fā)工具，不管是androidStudio、還是eclipse都可以使用。
我們?cè)诠こ棠夸浵聞?chuàng)建了jni文件夾，并創(chuàng)建了fork.c文件、Application.mk文件、Android.mk文件，內(nèi)容暫時(shí)不實(shí)現(xiàn)。
新建MyJni類，我們聲明了兩個(gè)本地方法getJninumber、Calljni。注意本地方法使用native關(guān)鍵字，內(nèi)容在C代碼的對(duì)應(yīng)函數(shù)中現(xiàn)。System.loadLibrary("fork");作用是加載本地.so鏈接庫(我們?cè)趈ni中的C代碼編譯后會(huì)生成.so本地代碼，這是交叉編譯的概念：在一個(gè)平臺(tái)上去編譯另一個(gè)平臺(tái)上可以執(zhí)行的本地代碼。我們的工程最終調(diào)用的并非是C文件，而是.so本地代碼)。
在MainActivity中我們?cè)贐utton的點(diǎn)擊事件中調(diào)用了我們上面聲明的native方法并接收了相應(yīng)的返回值在ToString方法中將int[]轉(zhuǎn)化為String，由于過程簡單這里不再上圖。
Android.mk解析
接下來我們單獨(dú)聊聊jni目錄下的Android.mk文件。Android.mk如果是底層開發(fā)的工程師一定再熟悉不過了，基本概念依然是留你自己百度去吧。通俗簡單的說就是告訴編譯器.c的源文件在什么地方,要生成的編譯對(duì)象的名字是什么。
LOCAL_PATH := $(call my-dir)
每個(gè)Android.mk文件必須以定義LOCAL_PATH為開始。它用于在開發(fā)tree中查找源文件。
宏my-dir?則由Build System提供。返回包含Android.mk的目錄路徑。
include $(CLEAR_VARS)
CLEAR_VARS 變量由Build System提供。并指向一個(gè)指定的GNU Makefile，由它負(fù)責(zé)清理很多LOCAL_xxx.
例如：LOCAL_MODULE, LOCAL_SRC_FILES, LOCAL_STATIC_LIBRARIES等等。但不清理LOCAL_PATH.
這個(gè)清理動(dòng)作是必須的，因?yàn)樗械木幾g控制文件由同一個(gè)GNU Make解析和執(zhí)行，其變量是全局的。所以清理后才能避免相互影響。
LOCAL_MODULE ? ?:= fork
LOCAL_MODULE模塊必須定義，以表示Android.mk中的每一個(gè)模塊。名字必須唯一且不包含空格。
Build System會(huì)自動(dòng)添加適當(dāng)?shù)那熬Y和后綴。例如，fork，要產(chǎn)生動(dòng)態(tài)庫，則生成libfork.so. 但請(qǐng)注意：如果模塊名被定為：libfork.則生成libfork.so. 不再加前綴。簡單來說就是指定了生成的動(dòng)態(tài)鏈接庫的名字。
LOCAL_SRC_FILES := fork.c
LOCAL_SRC_FILES變量必須包含將要打包如模塊的C/C++ 源碼。
不必列出頭文件，build System 會(huì)自動(dòng)幫我們找出依賴文件。
缺省的C++源碼的擴(kuò)展名為.cpp. 也可以修改，通過LOCAL_CPP_EXTENSION。
簡單來說就是指定了C的源文件叫什么名字。
include $(BUILD_SHARED_LIBRARY)
BUILD_SHARED_LIBRARY：是Build System提供的一個(gè)變量，指向一個(gè)GNU Makefile Script。它負(fù)責(zé)收集自從上次調(diào)用include $(CLEAR_VARS)后的所有LOCAL_XXX信息。并決定編譯為什么。
BUILD_STATIC_LIBRARY：編譯為靜態(tài)庫。
BUILD_SHARED_LIBRARY：編譯為動(dòng)態(tài)庫。
BUILD_EXECUTABLE：編譯為Native C可執(zhí)行程序。
Application.mk解析
Application.mk是用來描述你的應(yīng)用程序需要哪些模塊，以及這些模塊所要具有的一些特性。
Application.mk文件一般是放在$PROJECT/jni/目錄下的（$PROJECT代表你所寫程序的項(xiàng)目目錄），這樣ndk-build命令可以自動(dòng)搜索到它。當(dāng)然，Application.mk文件其實(shí)是可選的。默認(rèn)情況下，如果ndk-build命令找不到Application.mk文件的話，就會(huì)使用如下規(guī)則進(jìn)行編譯：
1）會(huì)編譯全部在Android.mk文件中列出的模塊；
2）對(duì)于所有模塊，NDK編譯系統(tǒng)會(huì)根據(jù)“armeabi” ABI來生成機(jī)器代碼，即指令集是ARMv5TE。
具體來說，Application.mk文件中，可以包含對(duì)下面幾個(gè)變量的定義：
APP_PROJECT_PATH
APP_MODULES
APP_OPTIM
APP_CFLAGS
APP_CPPFLAGS
APP_CXXFLAGS
APP_BUILD_SCRIPT
APP_ABI
這里我們只用到了APP_ABI默認(rèn)情況下，NDK編譯系統(tǒng)會(huì)根據(jù)“armeabi” ABI來生成機(jī)器代碼，即一個(gè)使用ARMv5TE指令集并且支持軟件浮點(diǎn)操作的CPU。
你可以通過定義APP_ABI變量來選擇一個(gè)不同的ABI。這里我們使用了all,表示我們選擇編譯全平臺(tái)的機(jī)器代碼，也可以有針對(duì)的寫x86則會(huì)只編譯x86平臺(tái)處理器的代碼。
編寫C代碼
我們?cè)贛yJni類中聲明了兩個(gè)本地方法，所以我們的C代碼需要新建兩個(gè)函數(shù)對(duì)應(yīng)java的本地方法。本地函數(shù)命名規(guī)則: 返回值 Java_包名_類名_本地方法名。按照此命名規(guī)則我們當(dāng)然是可以創(chuàng)建對(duì)應(yīng)的函數(shù)的，可是如果java本地方法數(shù)量過多，這時(shí)候就需要生成.h頭文件來完成函數(shù)的聲明。
首先我們進(jìn)入項(xiàng)目工程的src目錄下，輸入javah命令系統(tǒng)有相應(yīng)的提示，我們選擇-jni生成JNI樣式的標(biāo)頭文件，最后接上java本地方法所在類的全類名即可在項(xiàng)目src目錄下生成頭文件xxx.h。
在頭文件中我們發(fā)現(xiàn)，java本地方法對(duì)應(yīng)的函數(shù)名已經(jīng)幫我們生成好了，我們只需要拷貝到C文件中作為我們的函數(shù)即可。
我們來到C代碼,這是java本地方法getJninumber所對(duì)應(yīng)的函數(shù)。我們發(fā)現(xiàn)有三個(gè)值：JNIEnv*、jclass、jintArray,這都是啥呢？別急我們一個(gè)一個(gè)聊。
首先注意到我們引入了這個(gè)函數(shù)包，jni.h其實(shí)是我們android開發(fā)中NDK開發(fā)包提供的（詳細(xì)目錄android-ndk-r9d\platforms\android-19\arch-arm\usr\include\jni.h）。
我們打開jni.h源碼找到JNIEnv所定義的位置，#if defined(_cplusplus)意思是如果是C++文件則JNIEnv是_JNIEnv的自定義類型，#else否則JNIEnv?是JniNativeInterface這個(gè)結(jié)構(gòu)體的一級(jí)指針！由于我們是C代碼文件所以是后者。
回到我們的C代碼中JNIenv* env，實(shí)際上就是JniNativeInterface這個(gè)結(jié)構(gòu)體的二級(jí)指針。我們通過（*env）就可以方便的調(diào)用JniNativeInterface結(jié)構(gòu)體中定義的函數(shù)指針。
接下來我們追蹤第二個(gè)參數(shù)jclass,發(fā)現(xiàn)在源碼中jclass其實(shí)是jobject的自定義類型，jobject又是void*的自定義類型。調(diào)用本地方法的java對(duì)象就是這個(gè)jobject，在這里我們的本地方法的java對(duì)象是MyJni，所以jclass就是MyJni類的實(shí)例對(duì)象。
最后一個(gè)參數(shù)jintArray實(shí)際上和上一個(gè)類似，它是jarray的自定義類型，最終也是void*。在這里jintArray對(duì)應(yīng)我們java本地方法getJninumber傳入的int[]數(shù)組。
明白了函數(shù)的三個(gè)參數(shù)后我們要開始實(shí)現(xiàn)我們的函數(shù)邏輯，我們需要將java中傳入的int[]數(shù)組處理更改后給它作為jintArray返回。
我們通過（*env）可以直接調(diào)用結(jié)構(gòu)體中的GetArrayLength函數(shù)，函數(shù)接收J(rèn)NIEnv*和jintArray類型的參數(shù)返回?cái)?shù)組的長度,jsize實(shí)際上是int的自定義類型。
通過GetIntArrayElements函數(shù)獲取array數(shù)組的指針，最后一個(gè)參數(shù)傳布爾值標(biāo)志數(shù)組是否被復(fù)制。這里我們并不關(guān)心，所以傳NULL。
數(shù)組長度有了，指針有了，我們遍歷數(shù)組，通過指針位運(yùn)算更改了數(shù)組中每一個(gè)元素的值（+10），最終return回去。
運(yùn)行ndk-build即可開始編譯C程序，編譯完成后可在libs文件夾下看到編譯完成的.so動(dòng)態(tài)鏈接庫。（前提是你已經(jīng)配置了NDK環(huán)境變量）
在點(diǎn)擊事件中我們調(diào)用了getJninumber傳入int[]{1,2,3,4,5}數(shù)組，并接收了返回值然后吐司。完成了一次java傳入數(shù)據(jù)給C處理后返回java的操作。
C函數(shù)反射調(diào)用java方法
接下來我們聊聊下一個(gè)函數(shù)Calljni的實(shí)現(xiàn),看看他是如何實(shí)現(xiàn)回掉java方法的。
JniCallMe便是C函數(shù)Calljni需要回掉的java方法，它在MainActivity中定義。
這是我們Calljni函數(shù)的實(shí)現(xiàn)，一起來看看：
找到字節(jié)碼對(duì)象，在java中萬物皆對(duì)象Class也是對(duì)象，我們需要反射的方法在MainActivity中，所以我們需要獲取MainActivit的Class對(duì)象。當(dāng)然JniNativeInterface這個(gè)結(jié)構(gòu)體幫我們定義好了對(duì)應(yīng)的函數(shù)，我們只需要調(diào)用FindClass函數(shù)，最后一個(gè)參數(shù)是我們的Class的全路徑用斜杠隔開即可。
找到方法所在類的對(duì)象，我們的方法定義在MainActiviy中，所以我們需要獲取MainActiviy對(duì)象，注意本函數(shù)的第二個(gè)參數(shù)jclass obj并不能直接使用，因?yàn)樗莕ative方法所在類的對(duì)象即是MyJni類的對(duì)象，并不是我們要的！通過AllocObject函數(shù)，最后一個(gè)參數(shù)把第一步獲取MainActivit的Class對(duì)象傳入即可。
獲取方法對(duì)象，通過GetMethodID函數(shù)，最后兩個(gè)參數(shù)傳入方法的名稱、方法簽名（由于java的方法允許重載，GetMethodID函數(shù)需要通過方法簽名才能區(qū)分，怎么查看方法簽名？我們晚點(diǎn)聊）。
最后一步，反射java方法，CallVoidMethod函數(shù)可以幫我們做到，它是針對(duì)無返回值的java方法反射，傳入env、MainActivity對(duì)象、方法對(duì)象、還有java方法的形參...這里我們傳入int值6。
至此，函數(shù)就編寫完成，我們?cè)贐utton點(diǎn)擊事件中調(diào)用Calljni本地方法，C函數(shù)便會(huì)反射JniCallMe方法并傳入形參6完成控制臺(tái)打印。
為什么Toast會(huì)崩潰
細(xì)心的小伙伴發(fā)現(xiàn)我為啥把Toast注釋了改用控制臺(tái)輸出？
因?yàn)闀?huì)報(bào)錯(cuò)?。?！通過log我們發(fā)現(xiàn)是空指針異常，Context對(duì)象為Null?？墒俏覀兠髅魍ㄟ^MainActivity.this傳入Cantext。
原因是這樣，由于我們?cè)贑函數(shù)中第2步通過AllocObject函數(shù)獲取的MainActiviy對(duì)象其實(shí)是new出來的。Android程序與Java程序不一樣，并不是隨隨便便寫一個(gè)類，在main()方法里面就能運(yùn)行。Android是基于組件化設(shè)計(jì)的，組件的運(yùn)行需要一套完整的Android的環(huán)境的，在這個(gè)環(huán)境下Activity,Service才能運(yùn)行，而這些組件不能以new的方式創(chuàng)建實(shí)例，它需要相應(yīng)的上下文環(huán)境，也就是我們Context。可以說Context是這些Android組件運(yùn)行的一個(gè)核心類。所以我們并不能獲取到Context對(duì)象，從而導(dǎo)致了空指針異常。
方法簽名
在上面的GetMethodID函數(shù)中的最后一個(gè)參數(shù)需要傳入方法簽名，那么方法簽名應(yīng)該如何獲?。?/p>
在命令行進(jìn)入項(xiàng)目的bin\classes目錄運(yùn)行javap,會(huì)看到有幫助提示，我們輸入javap -s 方法所在的全類名 即可看到方法簽名。復(fù)制到代碼中即可。
至此本篇所聊的內(nèi)容都結(jié)束了，下篇我們來聊聊關(guān)于使用JNI調(diào)用cfork子進(jìn)程的話題。
歡迎長按下圖-識(shí)別圖中二維碼或者掃一掃，搜索微信公眾號(hào)：黃君華。關(guān)注我的公眾號(hào)：
如果你有不同意見或建議或者有好的技術(shù)文章想和大家分享歡迎投稿，可以把你的文章使用附件的形式發(fā)送到我的郵箱2908116133@qq.com
謝謝閱讀！
