Sí y No. El código nativo es un nombre inapropiado, y puede usarse en un contexto de varias maneras. El código nativo también puede significar “código compilado”. Similar a cómo C ++ y Objective-C, a veces se denomina código nativo. Sin embargo, el código nativo en el contexto del que creo que está hablando es un código nativo del procesador.
ART compila código (antes del tiempo) y realiza optimizaciones básicas (compilador rápido) para la CPU de destino (ARM, MIPS, X-86). Produce un archivo .OAT que está contenido dentro de un contenedor de objetos .so ELF. Los archivos ELF son archivos binarios independientes del sistema que pueden contener información ejecutable específica del procesador para que la CPU la ejecute directamente.
En ART, casi todos los archivos del dispositivo se compilan en un archivo .OAT que se asigna a la memoria, que luego el procesador ejecuta directamente. La máquina virtual Dalvik todavía está presente en ART, pero ya no ejecuta programas, como lo hizo bajo Dalvik (usando archivos ODEX), sino que mantiene el aislamiento de la aplicación del resto del sistema operativo si se ejecuta código malicioso (y otros razones demasiado largas para enumerarlas aquí).
- ¿Cómo encuentro mi teléfono móvil Android perdido?
- ¿Cuál es la importancia del desarrollo de aplicaciones de Android?
- ¿Debo aprender el desarrollo de aplicaciones de Android o concentrarme en lo académico?
- Cómo estudiar el desarrollo de Android
- ¿Cuáles son algunas de las principales diferencias del sistema operativo Android entre diferentes dispositivos?
Entonces, básicamente Google construyó un traductor binario reorientable, que puede pasar la ejecución del código real de la aplicación a la CPU real, sin perturbar la implementación actual de la máquina virtual (que puede obstaculizar el rendimiento hasta cierto punto).
Esa es una de las razones por las que los archivos .Dex tienen que transformarse en archivos .oat (archivos binarios) para que la CPU pueda ejecutar el código directamente, y no usar la VM para ejecutarlo. Los archivos DEX se crearon específicamente para la máquina virtual Dalvik y se ejecutaron con la máquina virtual.
Los archivos ejecutables Dalvik optimizados (ODEX) se produjeron utilizando dexopt en el dispositivo host. La herramienta dexopt también produjo código nativo (usando el compilador Just in Time), pero el código nativo todavía se ejecutó usando la VM, y no la CPU o el procesador real. La máquina virtual se asigna al procesador y ejecuta el código nativo utilizando las instrucciones del procesador. Creó un nivel de abstracción entre el código nativo y el hardware real de la CPU en el dispositivo host, lo que obstaculizó el rendimiento.
JNI se usa para interactuar con lenguajes basados compilados como C ++, C #, etc. dentro de la VM. Puede crear el llamado “Código nativo” utilizando el NDK de Android, pero a veces puede introducir una complejidad adicional y una sobrecarga que, en algunos casos, puede reducir el rendimiento. En la plataforma Android, codificar su aplicación en C ++ usando JNI no acelerará su aplicación ni hará que funcione mejor debido a la sobrecarga que JNI introduce en el proceso cuando la aplicación se ejecuta en el dispositivo de destino.
La mayoría de los desarrolladores usan C ++ o C # en un proyecto / aplicación Java cuando es necesario para rutinas o ejecuciones matemáticas complejas, como juegos o programas de base científica. A veces, usar JNI de esta manera, para abordar las deficiencias del uso de algoritmos basados en Java en situaciones matemáticas, a veces puede aumentar el rendimiento, y la sobrecarga adicional de JNI se convierte en un punto discutible.
Espero que aclare tu pregunta.
