在JNI中我們可以通過JNIEnv的FindClass方法查找到j(luò)ava的類然后進(jìn)行類似反射的調(diào)用乳蓄。
如果通過java代碼調(diào)用的Jni函數(shù),此時c的函數(shù)與Java運(yùn)行在同一個線程中薪者。無論是在主線程還是java啟動的子線程中FindClass都能正常工作。
native子線程加載不了自定義的Class
但如果是通過pthread_create之類的方法在native層創(chuàng)建了子線程,則在這個子線程中FindClass方法查不到我們Apk中定義的class。會返回0并且在Java層拋出ClassNotFoundException:
Process: me.linjw.demo.jni, PID: 2759
java.lang.ClassNotFoundException: Didn't find class "me.linjw.demo.jni.MainActivity" on path: DexPathList[[directory "."],nativeLibraryDirectories=[/system/lib64, /vendor/lib64, /system/lib64, /vendor/lib64]]
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:125)
at java.lang.ClassLoader.loadClass(ClassLoader.java:379)
at java.lang.ClassLoader.loadClass(ClassLoader.java:312)
我們可以通過JNIEnv的ExceptionClear方法清除java層出現(xiàn)的Exception,然后對返回的jclass進(jìn)行判空處理防止應(yīng)用崩潰:
jclass clazz = env->FindClass(className);
if(clazz != 0) {
...
}
env->ExceptionClear();
從上面的異常日志可以看到這里是通過BaseDexClassLoader而不是應(yīng)用層常見的PathClassLoader去加載class的伟端。我們從官方的JNI tips文檔里面可以得到回答:
This usually does what you want. You can get into trouble if you create a thread yourself (perhaps by calling pthread_create and then attaching it with AttachCurrentThread). Now there are no stack frames from your application. If you call FindClass from this thread, the JavaVM will start in the "system" class loader instead of the one associated with your application, so attempts to find app-specific classes will fail.
實(shí)際上JNIEnv從也是通過classloader去加載類的,如果一個Jni的方法是由java調(diào)用下來的那么它將沿用java層的classloader,這個classloader是在loadLibrary的時候設(shè)置進(jìn)去的:
public final class System {
...
public static void loadLibrary(String libname) {
Runtime.getRuntime().loadLibrary0(Reflection.getCallerClass(), libname);
}
...
}
public class Runtime {
...
void loadLibrary0(Class<?> fromClass, String libname) {
ClassLoader classLoader = ClassLoader.getClassLoader(fromClass);
loadLibrary0(classLoader, fromClass, libname);
}
...
private synchronized void loadLibrary0(ClassLoader loader, Class<?> callerClass, String libname) {
...
String error = nativeLoad(filename, loader, callerClass);
...
}
...
}
但如果是native創(chuàng)建的子線程那么它默認(rèn)是和java虛擬機(jī)沒有關(guān)聯(lián)的,所以也就沒有JNIEnv和對應(yīng)的classloader却舀。例如我們通過JavaVM的GetEnv方法是不能獲取到JNIEnv的:
jint result = javaVM->GetEnv((void **) &env, JNI_VERSION_1_4);
// result 等于JNI_EDETACHED(-2)
我們需要手動調(diào)用JavaVM的AttachCurrentThread方法將將native線程和java虛擬機(jī)相關(guān)聯(lián)。在關(guān)聯(lián)上java虛擬機(jī)的時候獲取到的classloader實(shí)際上是系統(tǒng)classloader,也就是這里的BaseDexClassLoader而不是我們應(yīng)用的PathClassLoader肺稀。
因此它并不能加載我們在apk里面定義的MainActivity等類,但是如果是一些系統(tǒng)的類比如java.lang.String、android.util.Log应民、android.app.Activity是可以加載到的:
3332 3359 D JniDemo : java/lang/String : 9
3332 3359 D JniDemo : android/util/Log : 17
3332 3359 D JniDemo : android/app/Activity : 37
3332 3359 D JniDemo : me/linjw/demo/jni/MainActivity : 0
解決方法
正常情況下我們都推薦在java層創(chuàng)建子線程去調(diào)用jni方法實(shí)現(xiàn)并發(fā)话原。但是有些特殊的情況可能的確需要在native中創(chuàng)建子線程訪問java代碼。
有的同學(xué)可能會說既然在native子線程中加載不到這個類,那么我們能不能在java線程中先加載出來在native子線程中使用呢?
答案是可以的,但是如果直接將jclass保存到全局引用會出現(xiàn)異常:
06-11 16:50:16.656 3507 3507 F DEBUG : Abort message: 'java_vm_ext.cc:534] JNI DETECTED ERROR IN APPLICATION: use of deleted local reference 0x75'
我之前寫過一篇JNI內(nèi)存管理的筆記有講到相關(guān)的知識點(diǎn),在java線程中FindClass得到的jclass是局部引用,局部引用在退出jni函數(shù)回到j(luò)ava代碼的時候就被回收了瑞妇。我們需要創(chuàng)建全局引用或者弱全局引用去保存:
clazzMainActivity = (jclass) env->NewGlobalRef(clazz);
之后我們就能在子線程中使用這個jclass通過類似反射的操作調(diào)用java代碼了:
jfieldID field = env->GetStaticFieldID(clazzMainActivity, "DATA_IN_JAVA", "I");
int data = env->GetStaticIntField(clazzMainActivity, field);
LOGD("data in threadFunc : %d", data);
// 日志如下
// 3427 3427 D JniDemo : data : 123
完整Demo代碼已上傳Github
