2011-08-16 16 views
120

En mi proyecto actual hago uso de varios archivos .so. Estos se encuentran en la carpeta armeabi y armeabi-v7a. Lamentablemente, uno de los archivos .so es de 6 MB y necesito reducir el tamaño del archivo. En lugar de tener un archivo APK gordo, me gustaría usar solo los archivos armeabi y eliminar la carpeta armeabi-v7a.¿Por qué usar el código armeabi-v7a sobre el código armeabi?

De acuerdo con la documentación NDK, el código armeabi-v7a es un código armeabi extendido que puede contener instrucciones adicionales de la CPU. Todo esto va más allá de mi experiencia, pero me pregunto por qué a uno le gustaría tener el código armeabi-v7a y armeabi. Debe haber una buena razón para tener ambas, ¿verdad?

En mis dispositivos de prueba todo parece funcionar bien. Estos tienen CPU ARM v7. ¿Es seguro asumir que todo funciona ahora?

+1

Es posible que desee leer este blog ahora. Es minucioso y está actualizado: https://androidbycode.wordpress.com/tag/armeabi-v7a/ –

Respuesta

139

Depende de lo que hace su código nativo, pero v7a tiene soporte para operaciones de punto flotante de hardware, lo que hace una gran diferencia. armeabi funcionará bien en todos los dispositivos, pero será mucho más lento y no aprovechará las capacidades de la CPU de los dispositivos más nuevos. Tome algunos puntos de referencia para su aplicación particular, pero eliminar los binarios de armeabi-v7a generalmente no es una buena idea. Si necesita reducir el tamaño, es posible que desee tener dos apk separados para dispositivos más antiguos (armeabi) y más nuevos (armeabi-v7a).

+0

Gracias por su respuesta clara. Será una buena idea hacer benchmarking y dividir la aplicación en 2 archivos APK. ¡Este último es realmente una muy buena idea! ¡Muchas gracias! – PaulT

+1

¿Dónde puedo encontrar la diferencia entre ambos ABI? Estoy muy instersted para entender las diferencias reales ... – webshaker

+7

ARM manuales? http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344c/Cacciced.html –

55

EABI = Interfaz binaria de aplicaciones incorporadas. Son las especificaciones a las que debe ajustarse un ejecutable para ejecutarse en un entorno de ejecución específico. También especifica varios aspectos de la compilación y el enlace necesarios para la interoperación entre las cadenas de herramientas utilizadas para la arquitectura ARM. En este contexto cuando hablamos de armeabi hablamos de la arquitectura ARM y del sistema operativo GNU/Linux. Android sigue el poco-endian ARM GNU/Linux ABI.

armeabi la aplicación se ejecutará en ARMv5 (por ejemplo, ARM9) y ARMv6 (por ejemplo, ARM11). Puede usar hardware de punto flotante si construye su aplicación utilizando las opciones apropiadas de GCC como -mfpu = vfpv3 -mfloat-abi = softfp que le dice al compilador que genere instrucciones de punto flotante para el hardware de VFP y habilite las convenciones de llamada de flotación suave. armeabi no es compatible con las convenciones de llamadas de flotación dura (significa que los registros de FP no se utilizan para contener argumentos para una función), pero las operaciones de FP en HW todavía son compatibles.

armeabi-v7a la aplicación se ejecutará en los dispositivos Cortex A # como Cortex A8, A9 y A15. Admite procesadores multi-core y es compatible con -mfloat-abi = hard. Entonces, si construyes tu aplicación usando -mfloat-abi = hard, muchas de tus llamadas a funciones serán más rápidas.

+0

Según https://developer.android.com/ndk/guides/abis.html : 'El ABI de armeabi-v7a utiliza el modificador -flota-abi = softfp'. Entonces, ¿a qué te refieres con ** compatible -mfloat-abi = hard **? –

Cuestiones relacionadas