背景

UE Android lib集成过程，使用普通Activity+SurfaceView的方式加载UElib，在退出游戏Activity时，出现nativeOnInputQueueDestroyed引擎的崩溃
在这里插入图片描述

原因

InputQueue处理流程

onDestroy()
onInputQueueDestroy()
这两个里面都可以在native层处理inputQueue，主要是 AInputQueue_detachLooper取消looper绑定
然后是在native的ondestroy中设置android_app为空（这里会把inputqueue也置为空）
onDetachedFromWindow中兜底将inputqueue设置为空

上面这个流程导致UE改造中出现了问题：

android层post onInputQueueDestroy消息到主线程，导致onInputQueueDestroy执行在onDetachedFromWindow之后，从而导致AInputQueue_detachLooper执行时出现“pthread_mutex_lock called on a destroyed mutex (0xf698788c)”错误，也就是inputqueue对象为空导致
android层post onInputQueueDestroy消息到子线程，由于主线程和子线程时序没有保证，导致偶尔出现上面的问题，inputqueue先被置为NULL，然后执行了AInputQueue_detachLooper。

解决方案

方案一

直接主线程手动调用nativeOnInputQueueDestroyed接口。
由于里面没有走AInputQueue_detachLooper()，会走在onDetachedFromWindow前面，避免出现崩溃。对于GameThread线程为子线程的场景，可能会出现其他地方释放inputqueue，目前没有找到，有一定的风险，但是简单。

方案二

仿照NativeActivity的胶水层，在处理线程同步时，采用锁同步机制

//NDK胶水层代码
//android_app_set_input方法发运行在UIThread
static void android_app_set_input(struct android_app* android_app, AInputQueue* inputQueue) {
    pthread_mutex_lock(&android_app->mutex);//加锁
    android_app->pendingInputQueue = inputQueue;
    android_app_write_cmd(android_app, APP_CMD_INPUT_CHANGED);//APP_CMD_INPUT_CHANGED消息写到GameThread
    while (android_app->inputQueue != android_app->pendingInputQueue) {//等待，直到APP_CMD_INPUT_CHANGED被消费掉，detachlooper操作在消息处理时被执行
        pthread_cond_wait(&android_app->cond, &android_app->mutex);
    }
    pthread_mutex_unlock(&android_app->mutex);//解除锁，UIThread继续执行
}