JNI de Android: llamada AttachCurrentThread sin DetachCurrentThread

android-ndk java-native-interface

Question

He estado leyendo sobre cosas de JNI y parece que no entiendo qué sucede si se inicia un hilo -> calls AttachCurrentThread () -> realiza algunas llamadas JNI -> exit de hilo.

Idealmente, deberíamos llamar a DetachCurrentThread () antes de que el hilo salga, sin embargo, ¿cuáles son las implicaciones si la aplicación no hace eso? ¿Causaría pérdida de memoria o cualquier otro problema?

Answer 1

No llamar a DetachCurrentThread() definitivamente causará una pérdida de memoria; otras consecuencias son específicas de JVM y probablemente irrelevantes para las aplicaciones de Android, donde la JVM se apaga cuando el proceso finaliza . Existen bastantes wrappers de C ++ que ayudan a administrar el enlace Attach / Detach, ver por ejemplo: http://w01fe.com/blog/2009/05/c-callbacks-into-java-via-jni-made-easyier

Actualización: 1000 gracias a fadden por el link abre los ojos; en Dalvik, un subproceso que sale sin llamar a DetachCurrentThread() , hace que toda la máquina virtual y el proceso se caigan.

Aquí está el logcat del emulador oficial, mi código basado en el ejemplo HelloJni de NDK:

10-26 04:16:25.853: D/dalvikvm(1554): Trying to load lib /data/app-lib/com.example.hellojni-2/libhello-jni.so 0xb3d264f0
10-26 04:16:25.893: D/dalvikvm(1554): Added shared lib /data/app-lib/com.example.hellojni-2/libhello-jni.so 0xb3d264f0
10-26 04:16:25.893: D/dalvikvm(1554): No JNI_OnLoad found in /data/app-lib/com.example.hellojni-2/libhello-jni.so 0xb3d264f0, skipping init
10-26 04:16:26.463: D/gralloc_goldfish(1554): Emulator without GPU emulation detected.
10-26 04:16:31.033: D/threadFunction(1554): Attaching
10-26 04:16:31.173: D/threadFunction(1554): Not Detaching
10-26 04:16:31.183: D/dalvikvm(1554): threadid=11: thread exiting, not yet detached (count=0)
10-26 04:16:31.193: D/dalvikvm(1554): threadid=11: thread exiting, not yet detached (count=1)
10-26 04:16:31.193: E/dalvikvm(1554): threadid=11: native thread exited without detaching
10-26 04:16:31.193: E/dalvikvm(1554): VM aborting
10-26 04:16:31.213: A/libc(1554): Fatal signal 6 (SIGABRT) at 0x00000612 (code=-6), thread 1567 (xample.hellojni)

Aquí está la función relevante agregada a hello-jni.c :

static JavaVM* jvm = 0;
static jobject activity = 0; // GlobalRef

void* threadFunction(void* irrelevant)
{
    JNIEnv* env;
    usleep(5000000);

    __android_log_print(ANDROID_LOG_DEBUG, "threadFunction", "Attaching");

    (*jvm)->AttachCurrentThread(jvm, &env, NULL);

    jclass clazz = (*env)->GetObjectClass(env, activity);
    jmethodID methodID = (*env)->GetMethodID(env, clazz, "finish", "()V" );
    (*env)->CallVoidMethod(env, activity, methodID);

    __android_log_print(ANDROID_LOG_DEBUG, "threadFunction", "Not Detaching");
//    (*jvm)->DetachCurrentThread(jvm);
}

jstring
Java_com_example_hellojni_HelloJni_stringFromJNI( JNIEnv* env,
                                                  jobject thiz )
{
    (*env)->GetJavaVM(env, &jvm);
    activity = (*env)->NewGlobalRef(env, thiz);

    pthread_t hThread;
    pthread_create(&hThread, NULL, &threadFunction, NULL);
    return (*env)->NewStringUTF(env, "Hello from JNI !");
}

Una buena implementación de esta estrategia se puede encontrar en WebRTC git repo .