Android JNI – Llamar AttachCurrentThread sin DetachCurrentThread
He estado leyendo sobre cosas de JNI y no puedo imaginar qué sucede si un hilo comienza -> llamadas AttachCurrentThread () -> hacer algunas llamadas de JNI -> salida del hilo.
Idealmente, deberíamos llamar a DetachCurrentThread () antes de las salidas de hilo, sin embargo, ¿cuáles son las implicaciones si la aplicación no hace eso? ¿Causaría pérdida de memoria o cualquier otro problema?
- Env-> FindClass función devuelve null
- Error de UnsatisfiedLink: Método nativo no encontrado findLibrary devuelto null
- Pasar una cadena al código C en Android NDK
- Recuperar android.os.Build ... propiedades del sistema mediante la aplicación puramente nativa de Android
- Asignación simple que viene con valor incorrecto
- Javah Error android.app.Activity not found
- Cómo obtener un contexto de una actividad nativa
- Escriba a stdout en JNI Android? Sin <android / log.h>
- JNI: Llamar a GetStaticMethodID explotar
- No se pudo cargar la aplicación Android SDK
- Implementar MIDI con Delphi en Android
- Ejecutar código en el subproceso principal / UI en Cocos2dx
- Unsatisfiedlinkerror en android (eclipse)
No llamar a DetachCurrentThread()
definitivamente causará una pérdida de memoria; Otras consecuencias son específicas de JVM y probablemente irrelevantes para aplicaciones de Android, donde la JVM se cierra cuando el proceso termina . Hay bastantes envolturas de C ++ que ayudan a manejar el hilo Attach / Detach, vea por ejemplo: http://w01fe.com/blog/2009/05/c-callbacks-into-java-via-jni-made-easyier
Actualización: 1000 gracias a fadden para el enlace de abrir los ojos; En Dalvik, un hilo que sale sin llamar a DetachCurrentThread()
, trae toda la máquina virtual y el proceso de bloqueo.
Aquí está el logcat del emulador oficial, mi código basado en la muestra 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 añadida 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 !"); }