NDK应用的onDestroy清理 - 如何DetachCurrentThread [英] NDK app onDestroy cleanup - how to DetachCurrentThread

查看:683
本文介绍了NDK应用的onDestroy清理 - 如何DetachCurrentThread的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

所以,如果我们重视我们必须把它完成后,后脱离线程,对吧?

So if we attach we must detach thread after after it finish, right?

JNIEnv* get_jni_env()
{
JNIEnv* res;
JAVA_VM->GetEnv((void**) &res, JNI_VERSION_1_6);//Using cached JavaVM
JAVA_VM->AttachCurrentThread(&res, NULL);
return res;
}

我把从 @覆盖下一个本地方法保护了我的Activity类的无效的onDestroy()

 void free_jni_manager()
 {
   JNIEnv* env = get_jni_env();
   ... //Here i delete global refs (jclass)
  //JAVA_VM->DetachCurrentThread();
 }

错误:拆卸螺纹插值帧(数= 16) - 主线程仍在运行,我们尝试将其卸下

ERROR: detaching thread with interp frames (count=16) - main thread still running and we try to detach it.

即使我们采取使用JNIEnv的(例如调用Java方法),把所有功能DetachCurrentThread会导致同样的错误。

Even if we take any function that use JNIEnv (for example calling java methods), putting DetachCurrentThread will cause same error.

DetachCurrentThread 完美的作品,如果所用的 pthread的功能

DetachCurrentThread works flawlessly if used in pthread function

static void* thread_func(void* arg)
{
 get_jni_env(); // attach new thread
 //Do thread stuff
 JAVA_VM->DetachCurrentThread();//thread done detached it with ok
 return NULL;
}

我们需要分离主线程,然后我们用JNI做的,还有呢?或随后的活动将被破坏,它会释放本身的JavaVM?我们需要做电DestroyJavaVM()(只是在做崩溃,如果使用的onDestroy),如何自由缓存的JavaVM或垃圾清洁剂会处理呢?

Do we need detach main thread then we done with JNI, there do it? Or then activity will be destroyed, it will freed itself with JavaVM? Do we need do call DestroyJavaVM() (just doing crash if use onDestroy), how free cached JavaVM or garbage cleaner will handle this?

P.S。有什么好处使用的 AttachCurrentThreadAsDaemon()

P.S. What benefits of using AttachCurrentThreadAsDaemon()

推荐答案

Activity.onDestroy()方法被称为UI线程。为什么你想从UI线程分离Java虚拟机?该线程由系统管理,您应该既不重视,也不分离Java虚拟机从/到它。

The Activity.onDestroy() method is called on the UI thread. Why are you trying to detach the Java VM from the UI thread? That thread is managed by the system, you should neither attach nor detach the Java VM from/to it.

的JNIEnv * 可用来作为第一个参数每一个本地方法。为什么你需要 get_jni_env()摆在首位?

The JNIEnv* is available to every native method as the first parameter. Why do you need get_jni_env() in the first place?

如果你需要对工人线程JNIEnv的,那么你需要连接和分离(OR产卵从Java线程,它很容易)

If you need a JNIEnv on worker threads, then you need to attach and detach (OR spawn a thread from Java; it's quite easy).

编辑:如果它是一个重复的附件,你不需要分离。这不是一个裁判计数系统。 AttachCurrentThread 记录为

If it's a repeat attachment, you don't need to detach. It's not a ref-counted system. AttachCurrentThread is documented as

试图连接已经连接的线程是一个空操作。

Trying to attach a thread that is already attached is a no-op.

相对于需要匹配安装/拆卸呼叫。

As opposed to requiring matched attach/detach calls.

这篇关于NDK应用的onDestroy清理 - 如何DetachCurrentThread的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆