1. Lib y libs
están referenciados en lib y se incluyen en libs.
Los archivos colocados en bibliotecas serán incluidos automáticamente por el editor. Así que no pongas la API en libs.
El contenido de lib no se empaquetará en el APK, el contenido de libs se empaquetará en el APK
2. Biblioteca de .so
NDK biblioteca de enlaces dinámicos compilada.
Algunos algoritmos de cifrado importantes o protocolos centrales generalmente se escriben en C y luego se llaman a Java. Esto puede evitar ver el código fuente de la aplicación después de la descompilación.
3. Cómo almacenar la biblioteca .so
. La postura correcta para colocar el archivo .so es en realidad dos oraciones:
• Para reducir el tamaño del apk, solo mantenga las dos carpetas armeabi y armeabi-v7a, y asegúrese de que el Los archivos .so están en estas dos carpetas. Cantidad constante
• Para el .so de terceros que solo proporciona la versión armeabi, copie una copia en la carpeta armeabi-v7a
. Reglas para almacenarlo:
debe proporcionar tantos archivos .so optimizados para cada ABI como sea posible, pero todo el soporte o ninguno: no debe mezclarlos. Debe proporcionar un archivo .so correspondiente para cada directorio ABI.
En cuanto al almacenamiento, puede consultar este artículo
. ¿Cuál es el papel de armeabi en las
bibliotecas ? La biblioteca .so de almacenamiento es principalmente compatible con diferentes dispositivos, o se puede decir que es compatible con la arquitectura de la CPU en diferentes teléfonos Android.
Hablemos de
los tipos de CPU de los dispositivos Android con CPU de Android (generalmente llamados "ABI")
Introducción a la arquitectura
El primer sistema Android casi solo admitía la arquitectura de CPU ARMv5, y luego se desarrolló para admitir siete arquitecturas de CPU diferentes: ARMv5, ARMv7 (desde 2010), x86 (desde 2011), MIPS (desde 2012), ARMv8, MIPS64 y x86_64 (desde 2014). ), cada uno de los cuales está asociado con un ABI correspondiente.
La interfaz binaria de la aplicación (interfaz binaria de la aplicación) define cómo se ejecutan los archivos binarios (especialmente los archivos .so) en la plataforma del sistema correspondiente, desde el conjunto de instrucciones utilizado, la alineación de la memoria hasta la biblioteca de funciones del sistema disponible. En el sistema Android, cada arquitectura de CPU corresponde a una ABI: armeabi, armeabi-v7a, x86, mips, arm64-v8a, mips64, x86_64.
Sin embargo, los últimos documentos oficiales de Google han eliminado mips y armv5, como se muestra en la figura: 
El análisis de cada versión es el siguiente:
• mips / mips64: rara vez se usa en teléfonos móviles y se puede ignorar (la última documentación de Google ya no es compatible )
• x86 / x86_64: los teléfonos móviles con arquitectura x86 incluirán una herramienta de transcodificación dinámica de conjunto de instrucciones llamada Houdini proporcionada por Intel para lograr la compatibilidad con arm .so, y considerando la participación de mercado x86 por debajo del 1%, los dos .so relacionados con x86 también lo son insignificante
• armeabi: ARM v5 esta es una versión bastante antigua, la falta de soporte de hardware para cálculos de punto flotante, hay cuellos de botella de rendimiento cuando se necesita mucha informática
• armeabi-v7a: ARM V7
• arm64-v8a: 64 bits soporte, la versión principal actualAunque muchos blogs en Internet dicen que v7 es la versión principal, personalmente he probado muchos teléfonos móviles, todos los cuales están basados en arm64-v8a. Los modelos probados incluyen Xiaomi Mi 5-Xiaomi 9, Huawei P30, Huawei Mate 10 , Meizu Blue 2, etc. v8
consulta de arquitectura línea de comandos de la cpu del teléfono móvil:
adb shell getprop ro.product.cpu.abi
- 1
Sin imagen, sin verdad: 
solo un teléfono oppo desconocido, sistema Android 4.3, con arquitectura v7
¿Cómo funciona ABI?
Actualización 2020.06, vi un artículo muy bueno movido, gracias al autor original ( https://juejin.im/post/5eae6f86e51d454ddb0b3dc6 ) el
documento oficial explica lo siguiente: El
sistema Android sabe qué ABI admite en tiempo de ejecución, porque la versión es específica Las propiedades del sistema de indicarán:
- La ABI principal del dispositivo corresponde al código de máquina utilizado en la propia imagen del sistema.
- (Opcional) ABI auxiliar correspondiente a otras ABI que también son compatibles con la imagen del sistema.
Este mecanismo asegura que el sistema extraiga el mejor código de máquina del paquete de software durante la instalación.
Para obtener el mejor rendimiento, debe compilar directamente con la ABI principal. Por ejemplo, un dispositivo típico basado en ARMv5TE solo definirá la ABI principal: armeabi. En contraste, un dispositivo típico basado en ARMv7 define la ABI principal como armeabi-v7a y la ABI auxiliar como armeabi, porque puede ejecutar los archivos binarios nativos de la aplicación generados para cada ABI.
Los dispositivos de 64 bits también admiten su variante de 32 bits. Tome el dispositivo arm64-v8a como ejemplo, este dispositivo también puede ejecutar códigos armeabi y armeabi-v7a. Sin embargo, tenga en cuenta que si la aplicación apunta a arm64-v8a en lugar de depender del dispositivo que ejecuta la versión armeabi-v7a de la aplicación, la aplicación funcionará mucho mejor en dispositivos de 64 bits.
Muchos dispositivos basados en x86 también pueden ejecutar archivos binarios armeabi-v7a y armeabi NDK. Para estos dispositivos, la ABI principal será x86 y la ABI secundaria será armeabi-v7a.
En general , un dispositivo Android puede admitir múltiples ABI, la ABI principal y la ABI auxiliar del dispositivo, el dispositivo con arm64-v8a como ABI principal, la ABI auxiliar es armeabi-v7a y armeabi, y el dispositivo con armeabi-v7a como el ABI principal, el ABI auxiliar es armeabi.
Además, los teléfonos móviles con arquitectura x86 incluirán una herramienta de transcodificación dinámica de conjunto de instrucciones llamada Houdini proporcionada por Intel para lograr la compatibilidad con arm.so, lo que significa que las aplicaciones que son compatibles con la plataforma armeabi pueden ejecutarse en teléfonos x86.
Proceso de adaptación específico de ABI
Para un teléfono móvil cuya cpu es la arquitectura arm64-v8a, cuando ejecuta la aplicación, cuando ingresa a jnilibs para leer el archivo de la biblioteca, primero vea si hay una carpeta arm64-v8a, si no existe dicha carpeta, vaya al armeabi -v7a carpeta, si No, vaya a la carpeta armeabi. Si no existe dicha carpeta, se lanzará una excepción;
si hay una carpeta arm64-v8a, vaya al archivo .so con un nombre específico. Nota: Si no encuentra lo que busca. El archivo so no se buscará (carpeta armeabi-v7a), pero se lanzará una excepción directamente.
Cómo adaptarse en nuestro proyecto
P1: Solo se adapta armeabi-v7a, por lo que si la aplicación se instala en un teléfono móvil con otras arquitecturas, como arm64-v8a, ¿rebotará?
R: No, pero viceversa.
Debido a que armeabi-v7a y arm64-v8a serán compatibles con versiones anteriores:
- La aplicación que solo se adapta a armeabi puede ejecutarse en armeabi, x86, x86_64, armeabi-v7a, arm64-v8
- Solo adaptarse a armeabi-v7a se puede ejecutar en armeabi-v7a y arm64-v8a
- Solo se adapta a arm64-v8a, se puede ejecutar en arm64-v8a
¿Cómo debemos adaptarnos? Se dan las siguientes soluciones:
Solución 1: Solo adaptarse a armeabi
Ventajas: Básicamente adaptado a todas las arquitecturas de CPU (excepto los obsoletos mips y mips_64)
Desventajas: bajo rendimiento, equivalente a la necesidad de ABI auxiliar o transcodificación dinámica para compatibilidad en la mayoría de teléfonos móviles
Solución 2: Adáptese solo a armeabi-v7a. Igual que la
Solución 1, excepto que una parte del equipo antiguo se filtra y el rendimiento y la compatibilidad son más equilibrados.
Solución 3: Adáptese solo a arm64-v8
Ventajas: mejor rendimiento
Desventajas: solo se puede ejecutar en arm64-v8, algunos usuarios de dispositivos antiguos tienen que abandonar
Estos tres esquemas son todos posibles, hoy en día Dachang APP se adapta a los tres, y la mayoría de ellos son los dos primeros esquemas. Cuál elegir depende de sus propias consideraciones, el rendimiento se reemplaza por compatibilidad, arm64-v8, y la compatibilidad se reemplaza por rendimiento armeabi, y el equilibrio entre los dos es armeabi-v7a.
Para teléfonos de 64 bits y procesadores de 64 bits
Los procesadores ARM de 64 bits y los procesadores de computadora de 64 bits son dos conceptos completamente incompatibles. No es que 64 bits puedan ser compatibles de forma nativa con programas de 32 bits, sino que la arquitectura de 32 bits está integrada en los procesadores de 64 bits para ejecutar el programa Bit. . Para decirlo claramente, no ejecuta programas de 32 bits en formato de 64 bits, sino que ejecuta programas de 32 bits en formato de 32 bits.
Dado que el nuevo procesador de 64 bits contiene dos arquitecturas, y la tecnología de proceso no se ha mejorado (28nm), al mismo tiempo, en teléfonos móviles y tabletas, el área del chip está estrictamente limitada y no se puede aumentar excesivamente, lo que conduce a una distribución uniforme de procesadores ARM de 64 bits El número de transistores en cada arquitectura ha disminuido drásticamente, lo que significa que desde la arquitectura de 32 bits del procesador de 64 bits, para el procesador de 32 bits de la misma especificación, no solo tiene el el rendimiento no ha mejorado, pero el rendimiento ha disminuido hasta cierto punto. Pero los fabricantes de procesadores deben dar a los consumidores una explicación para promover mejor los 64 bits, por lo que los fabricantes deben mejorar el rendimiento en otras áreas para compensar la pérdida causada por la reducción en la cantidad de transistores en la CPU. Por ejemplo: reemplazar las GPU con un mayor rendimiento, aumentar el ancho de banda de la memoria, núcleos únicos virtuales multinúcleo para mejorar el rendimiento de un solo núcleo, proveedores de software de ejecución conjunta para modificar las ponderaciones de las puntuaciones de ejecución (aumentar las puntuaciones de la GPU, reducir las ponderaciones de las puntuaciones de la CPU), etc. De esta manera, las fortalezas y debilidades se maximizan y finalmente llegan a las manos de los consumidores Después de ejecutar el software en ejecución, de hecho se mejora, los usuarios están contentos y los bolsillos de los fabricantes también están abultados.
En resumen, el procesador ARM de 64 bits es más apropiado para llamarlo ARM32 + 64 en sentido estricto. Comparado con el procesador ARM de 32 bits, tiene un paso hacia atrás y hay margen de mejora, pero es precisamente por el retroceso. que ha inspirado a ARM a avanzar, la determinación de hacerlo avanzar drásticamente, hay que decir que también es una especie de progreso. Pero, ¿es ARM64 realmente útil en teléfonos móviles? Solo puedo decir que es realmente inútil en este momento, pero puede que lo sea en el futuro. (Recopilado en otro lugar) En resumen, el procesador ARM de 64 bits es más apropiado para llamarlo ARM32 + 64 en sentido estricto. En comparación con el procesador ARM de 32 bits, hay un paso atrás y hay margen de mejora, pero precisamente porque Hacia atrás despertó la determinación agresiva de ARM, dejar que hiciera cambios drásticos hacia adelante, hay que decir que también es una especie de progreso. Pero, ¿es ARM64 realmente útil en teléfonos móviles? Solo puedo decir que es realmente inútil en este momento, pero puede que lo sea en el futuro. (Recopilado en otro lugar)
Un teléfono móvil real de 64 bits no solo permanece en el procesador. Si se le llama teléfono móvil de 64 bits solo porque su procesador es de 64 bits, podemos decir sin dudarlo que esto puede ser una falsa propaganda. Afortunadamente, Lenovo Very inteligente, cuando se lanzaron el A678t y el A805e, solo se mencionaron los teléfonos con procesador de 64 bits.
"Teléfono móvil con procesador de 64 bits" y "teléfono móvil de 64 bits" son dos conceptos muy diferentes: siempre que el procesador contenga 64 bits de arquitectura, se puede denominar "teléfono móvil con procesador de 64 bits". Este tipo de dispositivo móvil Es posible que el teléfono no funcione Los programas de 64 bits solo se utilizan para conquistar el mercado y las ventajas no son obvias en comparación con los teléfonos de 32 bits.
El "teléfono móvil de 64 bits" es diferente: contiene un procesador de 64 bits, un sistema estándar de 64 bits, una máquina virtual Android de 64 bits y un programa de 64 bits. Este es el teléfono móvil real de 64 bits. !
Google dijo oficialmente que Android es compatible con 64 bits hace mucho tiempo. Esto es cierto. Desde Android 4.0 a Android 4.4, los sistemas Android admiten hardware de 64 bits, pero esto solo significa que el controlador subyacente es compatible con 64 bits y puede ejecutarse. En hardware de 64 bits, nada más. Sin embargo, la capa superior que ejecuta el software, ya sea la máquina virtual Dalvik o la máquina virtual ART, es de 32 bits. En otras palabras, siempre que el sistema de su teléfono móvil sea Android4.0-4.4, incluso si su procesador es de 64 bits, solo puede ejecutar programas de 32 bits en una máquina virtual de 32 bits, incluso si el verdadero de 64 bits los programas están frente a usted, tampoco se puede instalar. .
Sin embargo, Google anunció oficialmente la arquitectura obligatoria de 64 bits a principios de este año : 
ya en enero de este año (2019), Google emitió un aviso que a partir del 1 de agosto de este año, además de la versión de 32 bits del aplicación, también se requiere una versión de 64 bits.
Por lo tanto, ya no es posible forzar el uso de solo armeabi como arquitectura antes del proyecto.
Entonces, ¿qué es exactamente el soporte de la versión de 64 bits que se menciona aquí?
Si su aplicación está escrita completamente en Java o Kotlin y no contiene ningún soporte nativo, entonces significa que la aplicación ya es compatible con 64 bits.
Sin embargo, si se utiliza algún soporte nativo (biblioteca so) en la aplicación, es necesario proporcionar diferentes versiones de soporte so para estos archivos so y para diferentes arquitecturas de CPU.
Cabe señalar que a veces, en nuestro propio código, el soporte nativo no se usa, pero se incluyen algunas bibliotecas de terceros que se usan en la aplicación.
En este momento, la forma más segura es analizar el archivo APK generado por el paquete final para determinar si es necesario brindar soporte para la arquitectura de 64 bits.
Configuración del paquete
subcontratación dividida
Este comando se puede subcontratar de acuerdo con varias reglas, como la subcontratación de acuerdo con abi, densidad de pantalla (es decir, ldpi, hdpi, etc.)
splits {
abi {
enable true
reset()
include 'x86','armabi'
exclude 'armeabi', 'armeabi-v7a', "arm64-v8a"
universalApk true
}
}Incluir medios para incluir, excluir medios para no incluir. Cada elemento de la configuración incluida generará un paquete apk.
Pero esta configuración generará dos paquetes, uno que contiene solo la biblioteca so de x86 y otro que contiene solo la biblioteca de armabi so. , Obviamente no satisface la demanda
ndk {abiFilters:} filtrado
Este comando se puede configurar para empaquetar solo la biblioteca so que configuró, y no empaquetar si no hay configuración, es muy flexible.
Para archivos aar de terceros, si el SDK tiene soporte completo para abi, puede incluir cinco tipos de abi, armeabi, armeabi-v7a, x86, arm64-v8a y x86_64, mientras que otros, por lo que solo aplica soporte armeabi, armeabi- v7a, x86 Tres, se refieren directamente al aar del sdk, compilará automáticamente un paquete que admita 5 tipos de abi. Pero la otra parte de la aplicación carece de soporte para las otras dos abi, entonces si la aplicación se está ejecutando en el arm64-v8a, x86_64 es el dispositivo abi preferido, se bloqueará, por lo que debemos configurar la configuración de abiFilter en nuestra aplicación. Evite algunos errores desconocidos
//过滤x86的so库
ndk {
abiFilters 'armeabi', 'armeabi-v7a', 'arm64-v8a'
}Esta configuración empaquetará las bibliotecas so bajo los tres paquetes de armeabi, armeabi-v71, arm64-v8a en una sola apk, a diferencia de las divisiones, que tendrán una apk para cada paquete.