大家好，又见面了，我是你们的朋友全栈君。

NDK学习笔记：线程JNIEnv，JavaVM，JNI_OnLoad

此文章是关于NDK线程的第二篇理论知识笔记。主要有两个点，如下：

1. pthread_create（Too many arguements, expected 1） ？
2. 线程中如何获取JNIEnv？GetEnv返回NULL？
3. FindClass返回NULL ？

首先我们在主页MainActivity的代码如下：

public class MainActivity extends Activity {

    static {
        try {
            System.loadLibrary("native-lib");
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    public native void nativeThreadEnvTest();

    public static String getUuid() {
        // 提供给nativeThreadEnvTest使用
        return UUID.randomUUID().toString();
    }
    
    @Override
    protected void onCreate(Bundle savedInstanceState) ...
}

 nativeThreadEnvTest打算实现这样一个功能：for循环调用MainActivity.getUuid方法，打印出5串不同的UUID。听上去很简单，逻辑代码如下：

#include <unistd.h>
#include <pthread.h>
#include <assert.h>

void *pthread_run(void *arg) {
    JNIEnv *env = NULL;
    // get env ?
    char *name = (char *) arg;
    for (int i = 0; i < 5; ++i) {
        //char* uuid_cstr = ...
        LOGI("%s, No:%d, uuid:%s", name, i, uuid_cstr);
        sleep(1);
    }

    pthread_exit((void *) 0);
}

JNIEXPORT void JNICALL
Java_org_zzrblog_MainActivity_nativeThreadEnvTest(JNIEnv *env, jobject thiz) {
    pthread_t tid;
    pthread_create(&tid, NULL, pthread_run, (void *) "pthread1");

    //void* reval;
    //pthread_join(tid, &reval);
}

此时第一个坑点可能就会出现了：pthread_create报出错误提示 Too many arguements, expected 1（黑人三问号）

ctrl+左键，跳转到头文件pthread.h的定义，明明就是四个参数的啊？

rebuild，重启AS，各种大法都没解啊，怎么办？ 这里给出可行科学的解决方案，在头文件添加如下宏定义就OJBK了！

#ifndef _PTHREAD_H_
#define _PTHREAD_H_

#include ...
// 添加宏定义 _Nonnull
#ifndef _Nonnull
#define _Nonnull
#endif

那么我们继续功能实现，在线程执行函数pthread_run中，想要调用MainActivity.getUuid方法，必须得有env啊。那么我们怎么获取env？可能就有大兄弟立马说：在nativeThreadEnvTest传入的env时NewGlobalRef啊，这样就可以全局使用了！这好像确实是一个解决思路，好像还蛮好使的（因为兄弟你见识得太少了）。但是！BUT！However！ 严谨的说，这种做法是不可取的。为什么？引用Google官方翻译：

由于VM通常是多执行绪(Multi-threading)的执行环境。每一个执行绪在呼叫native函数时，所传递进来的JNIEnv指标值都是不同的。为了配合这种多执行绪的环境，C组件开发者在撰写native函数时，可藉由JNIEnv指标值之不同而避免执行绪的资料冲突问题，才能确保所写的native函数能安全地在Android的多执行绪VM里安全地执行。基于这个理由，当在呼叫C组件的函数时，都会将JNIEnv指标值传递到下一级函数使用。

看起来好像很抽象，似懂非懂的。但是我们必须知道：VM是多执行绪(Multi-threading) ，每个JNIEnv都是不同的！特别是在不同线程，都是独自维护各自独立的JNIEnv。  那么问题又回到最初的？怎么正确的获取线程安全的JNIEnv？ 

此时我们引入函数JNI_OnLoad 和 结构体JavaVM，在头文件 jni.h 有它的定义：

/*
 * Prototypes for functions exported by loadable shared libs.  These are
 * called by JNI, not provided by JNI.
 */
JNIEXPORT jint JNI_OnLoad(JavaVM* vm, void* reserved);
JNIEXPORT void JNI_OnUnload(JavaVM* vm, void* reserved);

从注释可知，JNI_OnLoad是由系统JNI回调的，并不由得开发者乱用，而且也不由JNI默认提供。不重写这个方法系统就默认进行配置。在虚拟机VM加载c组件的时候（so）就会调用组件加载接口JNI_OnLoad()，在JNI_OnLoad()函数里，就透过VM之指标而取得JNIEnv之指标值，并存入env指标变数里。

这里的JavaVM就是虚拟机VM在JNI中的表示，一个进程JVM中只有一个JavaVM对象，这个对象是线程共享的。换言之这个JavaVM是能全局安全使用的，而且也只能在JNI_OnLoad的回调进行强引用赋值。 有了这个JavaVM，我们再调用AttachCurrentThread 附加当前线程到虚拟机VM当中，并返回线程对应的JNIEnv，我们就能愉快的撸码了！

说到AttachCurrentThread，不能不提起JavaVM的另外一个接口 GetEnv，看上去GetEnv不就是获取env的方法吗？这么解释吧，只有先AttachCurrentThread到JavaVM，分配到了独立的JNIEnv之后，GetEnv第二个参数二级指针返回的env才有值。就是说JavaVM->GetEnv获取的是，此线程有效的env。JavaVM->AttachCurrentThread是向虚拟机分配线程独立的env。    所以一般在线程执行函数第一句是AttachCurrentThread，随后就能用GetEnv了。

理论知识介绍到这里，我们继续测试功能函数，现在代码应该是长这样的：

JavaVM *javaVM;

JNIEXPORT jint JNICALL
JNI_OnLoad(JavaVM *vm, void *reserved) {
    LOGW("%s\n", "JNI_OnLoad startup ...");
    javaVM = vm;
    JNIEnv *env = NULL;
    jint result;

    if ((*vm)->GetEnv(vm, (void **)&env, JNI_VERSION_1_6) == JNI_OK) {
        LOGI("Catch JNI_VERSION_1_6\n");
        result = JNI_VERSION_1_6;
    }
    else if ((*vm)->GetEnv(vm, (void **)&env, JNI_VERSION_1_4) == JNI_OK) {
        LOGI("Catch JNI_VERSION_1_4\n");
        result = JNI_VERSION_1_4;
    }
    else {
        LOGI("Default JNI_VERSION_1_2\n");
        result = JNI_VERSION_1_2;
    }

    assert(env != NULL);
    // 动态注册native函数 ...
    return result;
}

void *pthread_run(void *arg) {
    JNIEnv *env = NULL;
    // (*javaVM)->AttachCurrentThread(javaVM,&env,NULL)
    // (*javaVM)->GetEnv(javaVM, (void **)&env, JNI_VERSION_1_6)
    if ( (*javaVM)->AttachCurrentThread(javaVM,&env,NULL) != JNI_OK) {
        LOGE("javaVM->Env Error!\n");
        pthread_exit((void *) -1);
    }

    assert(env != NULL);
   
    // 自定义的类型 jclass
    jclass clazz = (*env)->FindClass(env, "org/zzrblog/MainActivity");
    jmethodID getUuid_mid = (*env)->GetStaticMethodID(env, clazz, "getUuid","()Ljava/lang/String;");

    char *name = (char *) arg;
    for (int i = 0; i < 5; ++i) {
        jobject uuid_jstr = (*env)->CallStaticObjectMethod(env, clazz, getUuid_mid);
        char* uuid_cstr = (char *) (*env)->GetStringUTFChars(env, uuid_jstr, NULL);
        LOGI("%s, No:%d, uuid:%s", name, i, uuid_cstr);
        sleep(1);
    }

    (*env)->ReleaseStringUTFChars(env, sys_uuid_jstr, sys_uuid_cstr);
    (*javaVM)->DetachCurrentThread(javaVM);
    pthread_exit((void *) 0);
}

我们在JNI_OnLoad函数全局引用JavaVM对象，然后就是模板代码了，告诉系统虚拟机用哪个版本的JNI。此时调用JavaVM->GetEnv获取的env是主线程的。所以我们能获取成功。

然后我们进入线程执行函数，使用AttachCurrentThread请求分配当前线程安全的env，之后我们使用FindClass / GetStaticMethodID / CallStaticObjectMethod 等JNI API进行Java层的MainActivity.getUuid 静态方法的调用。

一切看着都是那么顺利，然后运行demo瞬间报错（奸笑.jpg）一堆红通通的错误啊！

为什么会找不到 org.zzrblog.MainActivity？此问题更好的体现了JNIEnv的线程独立性问题了！如果FindClass用的是主线程env就不会报错了。如果FindClass的是系统的UUID类也不会报错了。但是现实生活没有那么多如果！问题的原因就是只有主线程的env才有包含我们自定义（自己开发）的类类型，而 AttachCurrentThread的线程安全env只加载了系统的类类型，并不包含自定义的类类型。

所以问题的原因找到了，怎么解？既然env不是线程安全，不能直接引用。那么我们可以引用其他线程共享的调用对象啊，再通过GetObjectClass获取jclass。不明白的同学看如下代码：

jobject jMainActivity;

JNIEXPORT void JNICALL
Java_org_zzrblog_MainActivity_nativeThreadEnvTest(JNIEnv *env, jobject thiz) {
    if(jMainActivity == NULL) {
        //调用对象，创建全局引用
        jMainActivity = (*env)->NewGlobalRef(env, thiz);
    }

    pthread_t tid;
    pthread_create(&tid, NULL, pthread_run, (void *) "pthread1");
    //void* reval;
    //pthread_join(tid, &reval);
}

现在知道native方法的 static 和 非static的时候，传入的第二个参数的意义和真实的用处了吧？

非static的时候，传入jobject类型的thiz，就相当于MainActivity.this了。

staic的时候，传入jcalss类型的clazz，就相当于MainActivity.class了。

POSIX-Thread的主要内容写完，下章正式进行ffmpeg的音视频同步改造。