Android NativeActivity

Question

El Android NDK acaba de ser ampliado significativamente para incluir soporte para la escritura de aplicaciones Android totalmente en código nativo C/C++. Ahora se pueden capturar eventos de entrada en el teclado y en la pantalla táctil usando código nativo, y también implementar el ciclo de vida de la aplicación en C/C++ usando la nueva clase NativeActivity.

Dadas todas las capacidades nativas ampliadas, ¿valdría la pena omitir por completo Java y escribir la aplicación de Android en código nativo?

Answer 1

El NDK no es nativo per se. En gran medida es un contenedor JNI alrededor del SDK de Android. El uso de NativeActivity le brinda una manera conveniente de lidiar con ciertos eventos del ciclo de vida de la aplicación, y agrega su propio código nativo en la parte superior. ALooper, AInputQueue, etc. son todos los contenedores JNI de las contrapartes de Java SDK, algunos con código adicional que es privado e inaccesible para aplicaciones reales.

En lo que respecta al desarrollo de Android, no existe la posibilidad de escribir una aplicación completamente en C++ nativo; siempre (en cada caso de aplicación real que se me ocurra) siempre debe usar la API de Android: s, que en gran medida puro Java. Ya sea que uses estos a través de envoltorios proporcionados por el NDK o envoltorios que creas tú mismo realmente no cambia esto.

Por lo tanto, para responder a su pregunta: No, no valdría la pena, porque terminaría escribiendo envoltorios JNI para llamadas SDK en lugar de escribir envoltorios JNI a sus propios métodos Java que hacen lo mismo, con menos código , código más simple y código más rápido. Por ejemplo, mostrar un diálogo usando "C++ puro" implica muchas llamadas JNI. Simplemente llamando a un método Java a través de JNI que haga lo mismo, obtendrá un código más rápido (una llamada JNI) y, posiblemente, un código que sea más fácil de mantener.

Para entender completamente lo que puede hacer, realmente debe examinar el código fuente de Android. Comience con native_app_glue.c, que está disponible en el NDK, luego continúe con la implementación del sistema operativo de AActivity, ALooper, AInputQueue, etc. Google Code Search es de gran ayuda en esto. :-)

Si es fácil de hacer en Java e incluye muchas llamadas, llame a un método a través de JNI que lo hace todo, en lugar de escribir todo el código adicional para hacerlo con múltiples llamadas JNI. Conservar tanto de su código C++ existente como razonables.

Answer 2

No si solo está haciendo una aplicación estándar. El SDK de Java es más completo que su homólogo nativo en este momento, por lo que todavía estaría haciendo las cosas más difíciles para usted.

Si no está haciendo algo que requiera el NDK (léase: sensible al rendimiento en tiempo real), entonces quédese con Java.

Answer 3

Solo algo de reflexión, pero si tiene una aplicación en iOS y Android, es posible compartir el código C/C++. Obviamente, el iOS Obj-C y el código específico de la plataforma no funcionarían en ningún otro lado. (Ídem para las cosas específicas de Android). Pero es posible que puedas tener algún código compartido que sea neutro en la plataforma.

Answer 4

Si puede, quédese con las aplicaciones de estilo java hasta que las versiones de Android que admiten actividades nativas constituyan una fracción significativa de la base instalada.

Para cosas que antes eran difíciles de hacer, en particular puertos de código existente, esto probablemente sea de gran ayuda.

Aún no está del todo claro qué ha cambiado frente a simplemente escribir su propia envoltura delgada de Java. Por ejemplo, ¿todavía hay una copia del dalvik VM dando vueltas?