Dado que el simulador de iOS es un simulador, ¿por qué debo construirlo específicamente? ¿No es el objetivo de un simulador que ejecute el código real en algún tipo de VM/sandbox?¿En qué se diferencia la construcción del dispositivo iOS y el simulador?
¿Cuáles son las diferencias reales en la forma en que funciona la construcción del dispositivo/simulador y cómo difieren las aplicaciones creadas resultantes?
Una aplicación que se ejecuta de forma nativa en un dispositivo iOS es un programa de ARM. Sin embargo, una aplicación que se ejecuta en el simulador de iOS es un programa ordinario de Mac OS X de 32 bits (arquitectura i386). En otras palabras, el simulador no simula un dispositivo iOS hasta el nivel de hardware. Proporciona una copia fiel del entorno de iOS, que se vuelve a implementar en ejecutada de forma nativa en la Mac.
La construcción del simulador utiliza el conjunto de instrucciones i386, ya que eso es lo que usa tu mac.
Cuando compila para un dispositivo iOS, está compilando para los conjuntos de instrucciones armv6 o armv7.
El objetivo del simulador es que pueda hacer algunas pruebas rápidas en su mac, sin necesidad de usar un dispositivo.
Para obtener más información sobre los conjuntos de instrucciones: http://en.wikipedia.org/wiki/Instruction_set
Los simuladores nunca dan advertencias de memoria. Pero los diferentes dispositivos tienen memoria diferente, así que para crear una buena aplicación tenemos que probarla tanto en simulador como en dispositivos. echa un vistazo a la misma pregunta [enlace] (http://stackoverflow.com/questions/380062/iphone-device-vs-iphone-simulator) –
El simulador y el dispositivo deben ejecutar el mismo código de todos modos, sin embargo, hay algunos problemas que uno debe tener en cuenta.
El simulador no se puede ejecutar todas las funciones de la cual el dispositivo puede funcionar, por ejemplo, el simulador no interactúa con una cámara, los datos GPS no está presente (pero se puede establecer una ubicación fija de las opciones), y hay algunas otras cosas en ese sentido.
El simulador se puede utilizar para verificar su código y funcionalidad mucho más rápido que descargar su código en el dispositivo mientras se desarrolla, sin embargo, el simulador utiliza la memoria y CPU de la computadora, lo que significa que no refleja las dispositivo, velocidad y memoria sabia.
buena práctica sería para probar y desarrollar su mayoría en el simulador, cuando el código y estable y trabajando como cepillada - es el momento de probarlo en el propio dispositivo para presentaciones y otros asuntos que son de dispositivo específico.
Puedo elaborar más sobre el tema, pero esta es una respuesta rápida a su pregunta.
Por lo tanto, se compila literalmente para una arquitectura diferente. En ese caso, ¿es extraño que algunas bibliotecas que utilizo pongan los binarios del simulador/dispositivo en la misma ubicación con los mismos nombres, así que cada vez que construyo el simulador pierdo la versión del dispositivo y viceversa? ¿Y cómo funciona una aplicación que viene con bibliotecas de dependencias preconstruidas (archivos .a) tanto en el simulador como en el dispositivo? –
@john Puede usar la herramienta lipo que viene con xcode para hacer un binario gordo (funciona para el dispositivo y el simulador). – Vignesh
# hacer una nueva carpeta de salida mkdir -p $ {} project_dir/construcción/$ {} BUILD_STYLE -iphoneos/DTUtilities # combinan archivos lib para varias plataformas en una sola -create lipo "$ {} project_dir/construcción/$ {BUILD_STYLE} -iphoneos/libDTUtilities.a "" $ {PROJECT_DIR}/build/$ {BUILD_STYLE} -iphonesimulator/libDTUtilities.a "-output" $ {PROJECT_DIR}/build/$ {BUILD_STYLE} -iphoneos/DTUtilities/libDTUtilities- $ {BUILD_STYLE} .a " – Vignesh