I studied Android JNI, but there are a few points I don't understand

[[437215]]

This article is reprinted from the WeChat public account "Program Cat Adult", the author is Program Cat Adult. Please contact Program Cat Adult's public account to reprint this article.

Differences between Java threads and Native (OS) threads

Connection: Java threads are actually an encapsulation of an OS thread, and are essentially OS threads. [Previous versions of Java threads are not OS threads, but user-mode threads (Green Threads) constructed by the JVM, which cannot fully utilize the CPU. Later, they have been changed to use OS threads. ] [Reference https://mp.weixin.qq.com/s/Gxqnf5vjyaI8eSYejm7zeQ]

the difference:

Java threads can directly get JNIEnv, while OS threads need to attach to JVM before they can get JNIEnv. [My personal understanding is that the difference lies in whether JVM is attached]

 jint AttachCurrentThread(JavaVM *vm, void **p_env, void *thr_args);

The Java thread can FindClass successfully, but the OS thread fails to FindClass because the ClassLoaders of the two are different. The ClassLoader held by the OS thread after AttachCurrentThread is the system's ClassLoader. If you want to FindClass successfully, you need to obtain a copy of the current library's ClassLoader during JNI_Onload and save it, and use this ClassLoader to operate the next time you FindClass.

 static jobject g_class_loader = NULL ;
 static jmethodID g_find_class_method = NULL ;
 void on_load() {
    JNIEnv *env = get_jni_env();
 if (!env) {
 return ;
 }
    jclass capture_class = (*env)->FindClass(env, "com/captureandroid/BMMCaptureEngine" );
    jclass class_class = (*env)->GetObjectClass(env, capture_class);
    jclass class_loader_class = (*env)->FindClass(env, "java/lang/ClassLoader" );
    jmethodID class_loader_mid = (*env)->GetMethodID(env, class_class, "getClassLoader" , "()Ljava/lang/ClassLoader;" );
    jobject local_class_loader = (*env)->CallObjectMethod(env, capture_class, class_loader_mid);
    g_class_loader = (*env)->NewGlobalRef(env, local_class_loader);
 g_find_class_method =
        (*env)->GetMethodID(env, class_loader_class, "findClass" , "(Ljava/lang/String;)Ljava/lang/Class;" );
 } 
 
 jclass find_class(const char * name ) {
    JNIEnv *env = bmm_util_get_jni_env();
 if (!env) {
 return   NULL ;
 }
    jclass ret = (*env)->FindClass(env, name );
    jthrowable exception = (*env)->ExceptionOccurred(env);
 if (exception) {
        (*env)->ExceptionClear(env);
        jstring name_str = (*env)->NewStringUTF(env, name );
        ret = (jclass)(*env)->CallObjectMethod(env, g_class_loader, g_find_class_method, name_str);
        (*env)->DeleteLocalRef(env, name_str);
 }
 return ret;
 }

What does JNI do?

Here is a passage from the official document https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html#wp16696 translated by someone else:

The most important design goal of JNI is to provide binary compatibility between JVMs on different operating systems, so that a native library can run on JVMs of different systems without recompiling. To achieve this, JNI cannot care about the internal implementation of JVM when designing, because the internal implementation mechanism of JVM is constantly changing, and we must keep the JNI interface stable. The second design goal of JNI is efficiency. We may see that sometimes we may need to sacrifice a little efficiency to meet the first goal, so we need to make some choices between platform independence and efficiency. Finally, JNI must be a complete system. It must provide enough JVM functions for native programs to complete some useful tasks. JNI cannot only target a specific JVM, but also provide a series of standard interfaces so that programmers can load their native code libraries into different JVMs. Sometimes, calling the interface implemented under a specific JVM can provide efficiency, but in more cases, we need to use more general interfaces to solve the problem.

JNIEnv and JavaVM

It's a function pointer.

The following figure is the pointer structure of JNIEnv:

JNIEnv is actually an interface pointer pointing to local thread data, which contains a pointer to the function interface. Each interface function has a predefined offset position in this table, similar to the C++ virtual function table.

The code is as follows:

 typedef const struct JNINativeInterface *JNIEnv; 
 
 struct JNINativeInterface {
 void* reserved0;
 void* reserved1;
 void* reserved2;
 void* reserved3; 
 
    jint (*GetVersion)(JNIEnv *); 
 
    jclass (*DefineClass)(JNIEnv*, const char *, jobject, const jbyte*,
                        jsize);
    jclass (*FindClass)(JNIEnv*, const char *);
    jobject (*AllocObject)(JNIEnv*, jclass);
    jobject (*NewObject)(JNIEnv*, jclass, jmethodID, ...);
    jobject (*NewObjectV)(JNIEnv*, jclass, jmethodID, va_list);
    jobject (*NewObjectA)(JNIEnv*, jclass, jmethodID, const jvalue*);
 ...
 };
 JavaVM-like
 struct JNIInvokeInterface {
 void* reserved0;
 void* reserved1;
 void* reserved2; 
 
    jint (*DestroyJavaVM)(JavaVM*);
    jint (*AttachCurrentThread)(JavaVM*, JNIEnv**, void*);
    jint (*DetachCurrentThread)(JavaVM*);
    jint (*GetEnv)(JavaVM*, void**, jint);
    jint (*AttachCurrentThreadAsDaemon)(JavaVM*, JNIEnv**, void*);
 }; 
 
 typedef const struct JNIInvokeInterface* JavaVM;

Knowledge point 1: Why use function tables instead of hard-coding certain function items?

The JNI namespace can be separated from the native code, and a virtual machine can provide multiple versions of JNI function tables for different scenarios. For example, a virtual machine can support two types of JNI function tables:

One is for debugging, doing more error checking.

One for publishing, which does less error checking and is more efficient.

Knowledge point 2: JNIEnv is thread-local, which means it is only valid in the current thread. Native methods cannot pass JNIenv from the current thread to another thread. JNIEnv cannot be used across threads [as for why JNIEnv is designed to be thread-local, I don't understand].

Knowledge point 3: Although threads do not share JNIEnv, they share JavaVM, and then the JNIEnv of the current thread can be obtained through GetEnv.

jint GetEnv(JavaVM *vm, void **env, jint version);

Knowledge point 4: Native methods receive JNI interface pointers as parameters. The virtual machine ensures that the same JNIEnv is passed to Native methods in the same thread. If different threads call Native methods, the JNIEnv passed to them is different. However, the function table indirectly pointed to by JNIEnv is shared among multiple threads.

Knowledge point 5: Why does calling a native method in C language require passing JNIEnv as a parameter, but not in C++?

 // C language
 jstring model_path = (*env)->NewStringUTF(env, path);
 // C++
 jstring model_path = env->NewStringUTF(path);

The JNIEnv listed above is in C language form. Java also encapsulates a layer of JNIEnv for C++. The simplified version of the code is:

 struct _JNIEnv {
    /* do not rename this; it does not seem to be entirely opaque */
    const struct JNINativeInterface* functions; 
 
 #if defined(__cplusplus) 
 
 jint GetVersion()
 { return functions->GetVersion(this); } 
 
    jclass FindClass(const char * name )
 { return functions->FindClass(this, name ); }
 #endif
 }

In fact, it is essentially an interface in the form of a C language call.

How to pass data in JNI

I won't go into detail here, but basically, basic types like int and float are copied, while objects and byte arrays use references. So it actually takes little time to transfer byte stream data from the Java layer to the Native layer, and no copying will occur [but if the Native layer wants to use and hold this data, it has to make a copy itself].

There are also some knowledge points such as GlobalReference, LocalReference and why to Delete LocalReference. These are relatively basic and will not be introduced here. I guess everyone understands them.

Recommended Reading

https://www.cnblogs.com/kexinxin/p/11689641.html

NDK official documentation

https://developer.android.com/ndk/guides

References

http://luori366.github.io/JNI_doc/jni_design_theory.html

https://www.cnblogs.com/kexinxin/p/11689641.html

https://developer.android.com/ndk/guides