Esta es una pregunta de iOS.¿Por qué el tamaño del binario final sería mucho más pequeño que el tamaño de la biblioteca estática?
Construyo una biblioteca estática (framework en iOS) que luego se incluye en una aplicación. El tamaño del resultado binario (500 kb) es menor que el tamaño de la biblioteca estática (6 mb). ¿Como funciona esto? Mi comprensión de la biblioteca estática es que la biblioteca estática se incluye en el binario final
Porque no está utilizando todas las funciones de su biblioteca. Una biblioteca estática de tipo de archivo .a es una colección de archivos de objetos .o y solo los archivos de objeto necesarios en su programa se incluyen en el tiempo de enlace.
Siempre que estáticamente enlazar un archivo ejecutable, el enlazador puede seguir adelante y resolver todos los nombres de símbolos (es decir, ellos mapa para una dirección) desde todos los símbolos que estará al tanto de que haya proporcionado al enlazador ahora (en la forma de archivos .o y .a bibliotecas que son realmente solo una colección de archivos .o). Si hay nombres que no están allí, obtendrá un error de enlace (esto es diferente al enlace dinámico donde puede cargar otra biblioteca en tiempo de ejecución). En su caso, tiene símbolos adicionales que no son referenciados por el ejecutable. Como el vinculador sabe que estos símbolos no se utilizan, simplemente se eliminan de la salida ejecutable. Por lo tanto, su ejecutable será más pequeño que las bibliotecas de entrada en este caso.
¿Qué sucede cuando agrega el indicador '-Objc' o' -all_load'? – Tony
Los efectos de '-Objc' [descritos aquí] (https://developer.apple.com/library/content/qa/qa1490/_index.html) dice que" cargará todos los miembros de bibliotecas estáticas que implementen cualquier Objetivo- Clase C o categoría. ", Y como advertencia:" Pero puede hacer que el ejecutable resultante sea más grande y puede recoger objetos innecesarios ". Esto hará que el ejecutable sea más grande que el enlace regular (si tiene esos objetos). '-all_load' suena aún más agresivo, incluido el código objeto de acuerdo con [esta descripción] (http://stackoverflow.com/a/2906210/425738), incluyendo más código objeto. – ldav1s
¿Eso significa que cuando agrega los indicadores el ejecutable debe ser tan grande como la combinación de bibliotecas que incluye? En la práctica, ese no parece ser el caso. – Tony
Además de esto, una biblioteca correctamente factorizada tiene cada función (o familia de funciones estrechamente relacionadas) en un archivo separado '.o'. En dicho uso, la cabecera del encabezado del archivo '.o' puede fácilmente ser del 25% del tamaño del archivo para cada archivo' .o', y en el peor de los casos, la sobrecarga puede ser decenas o cientos de veces el tamaño del código. Es decir, un archivo '.a' bien factorizado podría ser normalmente un 50% de código y 50% de encabezados de archivo' .o'. Por supuesto, esto funciona junto con la respuesta de ouah: cuanto mejor sea una biblioteca, mayor será la posibilidad de que el enlazador omita los archivos de objeto innecesarios. –
Estoy de acuerdo en principio con el comentario de @R .. Pero en estos días las herramientas pueden hacer algunas de estas tareas automáticamente (por ejemplo '-ffunction-sections' de gcc (efectivamente coloca cada función en un archivo' .o') et al.), Así que tal vez hacerlo en el nivel de código fuente no sea tan importante como lo fue una vez. – ldav1s
@ ldav1s: aunque '-ffunction-sections' y opciones relacionadas están disponibles, no creo que sean de uso generalizado, y no tengo claro si las opciones de enlazador necesarias están habilitadas por defecto. También hay algunos casos, como estructuras estáticas que contienen punteros a funciones, donde '-ffunction-sections' podría (de nuevo, no estoy seguro) ser insuficiente para eliminar las funciones innecesarias. –