在JNI中我們可以通過JNIEnv的FindClass方法查找到java的類然後進行類似反射的調用。
如果通過java代碼調用的Jni函數,此時c的函數與Java運行在同一個線程中。無論是在主線程還是java啓動的子線程中FindClass都能正常工作。
native子線程加載不了自定義的Class
但如果是通過pthread_create之類的方法在native層創建了子線程,則在這個子線程中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層出現的Exception,然後對返回的jclass進行判空處理防止應用崩潰:
jclass clazz = env->FindClass(className);
if(clazz != 0) {
...
}
env->ExceptionClear();
從上面的異常日誌可以看到這裏是通過BaseDexClassLoader而不是應用層常見的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.
實際上JNIEnv從也是通過classloader去加載類的,如果一個Jni的方法是由java調用下來的那麼它將沿用java層的classloader,這個classloader是在loadLibrary的時候設置進去的:
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創建的子線程那麼它默認是和java虛擬機沒有關聯的,所以也就沒有JNIEnv和對應的classloader。例如我們通過JavaVM的GetEnv方法是不能獲取到JNIEnv的:
jint result = javaVM->GetEnv((void **) &env, JNI_VERSION_1_4);
// result 等於JNI_EDETACHED(-2)
我們需要手動調用JavaVM的AttachCurrentThread方法將將native線程和java虛擬機相關聯。在關聯上java虛擬機的時候獲取到的classloader實際上是系統classloader,也就是這裏的BaseDexClassLoader而不是我們應用的PathClassLoader。
因此它並不能加載我們在apk裏面定義的MainActivity等類,但是如果是一些系統的類比如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層創建子線程去調用jni方法實現併發。但是有些特殊的情況可能的確需要在native中創建子線程訪問java代碼。
有的同學可能會說既然在native子線程中加載不到這個類,那麼我們能不能在java線程中先加載出來在native子線程中使用呢?
答案是可以的,但是如果直接將jclass保存到全局引用會出現異常:
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內存管理的筆記有講到相關的知識點,在java線程中FindClass得到的jclass是局部引用,局部引用在退出jni函數回到java代碼的時候就被回收了。我們需要創建全局引用或者弱全局引用去保存:
clazzMainActivity = (jclass) env->NewGlobalRef(clazz);
之後我們就能在子線程中使用這個jclass通過類似反射的操作調用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