2012-06-19 8 views
6

Necesito trabajar con activos en mi carpeta de activos desde el código C/C++. ¿Es seguro para almacenar en caché puntero a AAssetManager así ...:Android NDK - usando AssetManager en el código nativo

AAssetManager* assetMgr = NULL; 

void Java_com_example_createAssetManager(JNIEnv* env, jclass clazz, jobject assetManager) 
{ 
    AAssetManager* mgr = AAssetManager_fromJava(env, assetManager); 
    assert(NULL != mgr); 
    assetMgr = mgr;  
} 

... y luego usarlo cuando lo necesito? Se llama al createAssetManager desde el método de onCreate de Java de la actividad principal (subproceso de la interfaz de usuario), pero el uso en C/C++ es cuando se procesa nativamente la representación y la marca del juego desde métodos nativos en la implementación de GLSurfaceView.

1) ¿apunta el puntero assetMgr a objeto válido durante toda la vida útil de la aplicación? ¿Es suficiente crearlo también como variable estática en el lado de Java (en la clase de Actividad) para que el recolector de basura no lo destruya?

2) ¿Existe algún peligro de que tenga problemas con los hilos?

Gracias, Tom Atom

+0

Err en el lado seguro y no caché. 'AAssetManager_fromJava()' es muy rápido. –

+0

Gracias por su respuesta. La razón por la que quería guardarlo en caché era porque no sé cómo obtener el puntero sin tener "jobject assetManager" en la llamada al método. Entonces, ¿tengo que agregar este parámetro en cada llamada desde Java a C/C++ solo para el caso en que lo necesite durante el tic? ¿O hay alguna forma de cómo puedo consultar Java para el objeto a tiempo cuando lo necesito (pregunte Java para AssetManager, luego llame a AAssetManager_fromJava, luego úselo ...) –

Respuesta

3

Una forma marginalmente más seguro para almacenar en caché el gestor de activos serían para almacenar una referencia global al objeto Java que subyace en el lado C junto con el puntero del AAssetManager en caché. Al menos con eso sabría que el objeto Java detrás/alrededor del objeto C no será basura.

Para hacer eso, llame al .

Y acceder al administrador de activos a través del límite de subprocesos sería bastante loco, en mi humilde opinión. Esa es una restricción de diseño muy fuerte: a menos que se documente explícitamente, la seguridad de subprocesos nunca puede asumirse por defecto.

2

He escrito un módulo NDK, Assetbridge, que también podría serle útil. Exporta los contenidos de los activos/carpetas de su proyecto (archivos y directorios) a un directorio temporal, y luego establece una variable de entorno para esa ruta, por lo que su código nativo puede chdir() para el directorio temporal y puede usar el viejo estándar archivo de biblioteca IO rutinas.

Cuestiones relacionadas