Android NDK – NativeActivity vs JNI lib

Hace dos años desarrollé un marco de Realidad Aumentada en android-7 (Eclair) . Dado que la aplicación de AR es la tarea de computación intensiva, he desarrollado una biblioteca JNI c + + utilizada por una actividad de Java para procesar y registrar el entorno virtual. Las lecturas de sensores adquiridas en Java se pasan a la biblioteca de subrayado c ++ para calcular el registro del entorno virtual. Los objetos tridimensionales son representados por una función de dibujo nativa llamada desde GLSurfaceView . Esto resulta en una gran cantidad de llamadas JNI.

Ahora me gustaría portar la aplicación a android-15 (Ice Cream Sandwich) . A partir de android-9 (Gingerbread) Android permite utilizar NativeActivity .

Me gustaría entender cuál es la mejor manera de desarrollar una aplicación de AR. Como cada llamada de JNI introduce una sobrecarga, sería mucho mejor evitarlas. ¿Es posible usar NativeActivity? No encontré una guía exaustiva que explique cómo funciona NativeActivity, pero al leer este documento parece que resulta en muchas llamadas JNI de todos modos. ¿Existe algún documento de arquitectura que explique cómo funciona NativeActivity? ¿Es NativeActivity sólo un "JNI wrapper" para evitar el código java? Con respecto a las interpretaciones, ¿hay ventajas usando NativeActivity en lugar de una biblioteca JNI como lo hice antes?

Muchas gracias.

NativeActivity no dará un impulso de rendimiento a su marco. Todavía utiliza JNI para comunicarse con el sistema, sólo bajo la cubierta.

Además, hay buenas razones para no usarlo. Si entiendo su propósito correctamente, desea que otras aplicaciones aprovechen su código. Al obligarlos a utilizar NativeActivity reducir seriamente su libertad, y requieren que luchan con un entorno menos familiar. Existe una serie de limitaciones con NativeActivity, por ejemplo, no puede cargar más de una biblioteca JNI.

Finalmente, sugeriría una dirección completamente diferente si buscas la optimización de tu framework AR: puedes usar la nueva API setPreviewTexture () .

Por lo que yo entiendo que todavía están obligados a JNI también cuando se utiliza NativeActivity. Esta clase puede utilizarse como punto de partida y encapsula algunas funcionalidades para su conveniencia, pero la tecnología subyacente para acceder al código nativo no ha cambiado y sigue siendo JNI. Así que en mi opinión sólo puede hacer algunos puntos de referencia para comprobar si NativeActivity es más eficiente por alguna razón (puede ser que los chicos de Google no conocen algunos hacks que lo hacen más rápido que su solución).