¿Qué significa zipalign y cómo encaja en cómo usamos nuestros dispositivos Android?


19

¿Qué significa "zipalign" y cuál es su significado?

Cuando una ROM dice estar "zipaligned", ¿qué significa eso y cuál es la diferencia de una ROM que no está "zipaligned"?

Respuestas:


21

Este mecanismo se describe en el sitio de desarrolladores de Android de la siguiente manera:

zipalign es una herramienta de alineación de archivos que proporciona una optimización importante para los archivos de aplicaciones de Android (.apk). El objetivo es garantizar que todos los datos sin comprimir comiencen con una alineación particular en relación con el inicio del archivo. Específicamente, hace que todos los datos sin comprimir dentro del .apk, como imágenes o archivos sin formato, se alineen en límites de 4 bytes. Esto permite acceder a todas las partes directamente con mmap () incluso si contienen datos binarios con restricciones de alineación. El beneficio es una reducción en la cantidad de RAM consumida al ejecutar la aplicación.

En resumen: .apkse puede acceder al contenido de manera más fácil / rápida / óptima debido al orden de los datos dentro del archivo empaquetado.

Para obtener más información, hay una "guía completa" disponible en AddictiveTips: ¿Qué es Zipalign en Android y cómo hacer que las aplicaciones estén en Zipaligned , que responde a la segunda parte de su pregunta:

Es comprensible que la situación se reserve para paquetes de aplicaciones no alineados. La lectura de recursos sería lenta y el uso de memoria estaría en el extremo superior del espectro. También dependería de cuántas aplicaciones no alineadas estén presentes. Por ejemplo, si hay menos aplicaciones con una aplicación de inicio no alineada, verás tiempos de inicio de aplicaciones más lentos. Este es el mejor de los casos. Para el peor de los casos, tener una serie de aplicaciones no alineadas dará como resultado que el sistema inicie y elimine procesos repetidamente, luchando con retrasos y una gran descarga de batería.


Para los programadores, es más o menos similar a la alineación de estructura en C. No lo haga struct x { uint16_t id; uint32_t data[100]; };si desea que esté alineado con 32 bits; usostruct x { uint16_t id; uint16_t padding; uint32_t data[100]; };
Mateo Lee

Parece que no hay inconveniente, ¿por qué no todas las aplicaciones están alineadas? ¿Esto también es realmente una preocupación para los usuarios finales o solo es relevante para los desarrolladores?
Matt

1
Es un paso adicional para el desarrollador que diría. Y, por supuesto, el rendimiento es una preocupación para los usuarios finales;)
Izzy

1

Para agregar a lo anterior cómo funciona exactamente zipalign:

En un entorno operativo Android, múltiples procesos acceden a los archivos de datos almacenados en cada paquete de aplicación, por ejemplo, el instalador leerá el manifiesto de datos para determinar los permisos asociados; el servidor del sistema puede leer estos recursos por múltiples razones, como mostrar notificaciones; la aplicación Inicio, por ejemplo, leerá recursos para obtener el nombre y el ícono de la aplicación. Dado que Android se basa en una verdadera infraestructura operativa multitarea, se accede a estos archivos de forma continua y repetida. Finalmente, pero no menos importante, la aplicación misma lee los datos del manifiesto.

Como Android está basado en Linux, el mapeo de memoria juega un papel clave en el manejo eficiente de los procesos. Esencialmente, la alineación óptima para el código de manejo de recursos del sistema operativo Android es límites de 4 bytes. Lo que esto significa es que, si los APK se asignan en memoria a límites de 4 bytes y se alinean en consecuencia, el sistema operativo no necesitará "leer" todo el paquete de la aplicación para llegar al manifiesto de datos deseado. Cada proceso del sistema sabrá de antemano dónde buscar los recursos deseados y, por lo tanto, se ejecutará de manera mucho más fluida y fluida.

En resumen, la alineación zipal de un APK da como resultado que todos los datos sin comprimir dentro del paquete se alineen en límites de 4 bytes, lo que permite acceder a todas las porciones directamente con el mapa de memoria. El consumo de RAM se reduce durante la ejecución porque el código de consulta no tiene que leer todo el paquete de la aplicación.

Fuente


¿Por qué no lee todo el paquete de la aplicación? ¿Se garantiza que los manifiestos tengan un desplazamiento específico?
Kenneth Worden
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.