ios - tools - xcode requerimientos
Xcode6: ejecuta dos instancias del simulador (6)
Tengo dos objetivos diferentes para mi aplicación iOS. ¿Es posible ejecutar simultáneamente las dos aplicaciones en dos instancias diferentes del simulador? Está bien si requeriría no beneficiarse del depurador de Xcode. Hasta ahora, la única solución que encontré fue instalar dos versiones de XCode, pero esa es una solución muy pesada / que consume mucho espacio.
FBSimulatorControl de Facebook proporciona una forma programática para hacer esto. Está disponible en https://github.com/facebook/FBSimulatorControl .
El método
testLaunchesMultipleSimulatorsConcurrently
in
FBSimulatorControlSimulatorLaunchTests.m
tiene un código de muestra que ilustra cómo iniciar múltiples simuladores.
Probó con éxito que la solución de i40west funciona para iniciar el simulador manualmente, pero parece una tontería que hoy en día, un simulador de iOS requiera diferentes versiones de Xcode Y diferentes tipos de dispositivos cuando se ejecutan pruebas simultáneas desde la línea de comandos (caso de uso ligeramente diferente pero relacionado con la pregunta original en la parte superior )
Consulte el artículo de Apple aquí que es más relevante para las compilaciones y pruebas de línea de comandos: https://developer.apple.com/library/ios/technotes/tn2339/_index.html
Múltiples pruebas simultáneas han funcionado bien para nosotros si pasamos --args - correctos a ''iOS simulator.app'' antes de ejecutar el comando ''prueba xcodebuild'' con el lanzamiento correcto del simulador de coincidencia de valores ''-destination'' con el valor de UUID de la salida de ''xcrun simctl list '', y establecer la variable de entorno DEVELOPER_DIR para seleccionar diferentes binarios de la versión XCode (es decir, la ruta base a Xcode 6.1 y 6.4)
La razón por la que se necesitan pruebas unitarias simultáneas en la misma máquina física y el mismo dispositivo simulador de iOS, como iPad o iPhone, y la misma versión de Xcode es principalmente compatible con CI (integración continua) de cualquier proyecto iOS por el cual el mismo sistema de compilación puede ejecutar más de 1 compilación de múltiples Las aplicaciones (nuestra empresa tiene aproximadamente 30 aplicaciones) a la vez al registrarse en las ramas de funciones son escaneadas y construidas automáticamente por el agente Bamboo sin necesidad de esperar a que se completen otras compilaciones en ejecución: Bamboo admite este tipo de compilación automática en auto- ramas de características descubiertas si están habilitadas.
En cuanto a lo que sucede al ejecutar múltiples pruebas simultáneas, ejecutamos múltiples comandos ''prueba xcodebuild'' dos veces seguidas en diferentes ventanas de Terminal.app, el resultado es que solo aparece una ventana de simulador y las pruebas fallan en la prueba más simple.
Cuando complicamos los criterios de entrada para nuestro lanzamiento de prueba, diferentes versiones de Xcode para cada sim y lanzamiento de prueba, cuando usamos DEVELOPER_DIR según las páginas de manual (prueba xcodebuild) estamos especificando un dispositivo diferente que se abre en dos ventanas separadas, pero el resultado es que cualquier prueba en ejecución en la primera ventana se ve interrumpida por la segunda ventana del simulador de iOS.
Parece que hay un recurso compartido común bajo el capó que se está interponiendo en el camino, no estoy seguro de lo que se pretende o simplemente una nueva característica que requiere más de unos días de reflexión seria sobre cómo implementar mejor las pruebas concurrentes sin impactos adversos.
No queremos usar máquinas virtuales para evitar las restricciones de simulación, ya que nuestra experiencia y la de otros en general es que el rendimiento de compilación de iOS en máquinas virtuales con gran cantidad de archivos pequeños es más lento que el hardware físico. Las máquinas virtuales generalmente ralentizarán mucho la compilación debido a problemas de E / S en la combinación del software VMware y el hardware y / o firmware de Apple. Lo sentimos, virtualmente en el gueto, pero para nosotros las máquinas virtuales no funcionan bien: el sitio de virtualmente en el gueto nos ha proporcionado instrucciones sobre cómo instalar ESXi 5.5 en Mac Mini para nuestra granja de compilación.
Hemos experimentado el problema de rendimiento de compilación con ESXi 5.5 en Mac Mini que es más lento que el metal desnudo incluso con SSD por un factor de 2 o más (es decir, una compilación de metal desnudo de 10 minutos toma 20 en VM). Consulte el artículo de resumen a continuación sobre por qué.
https://corner.squareup.com/2015/07/ios-build-infrastructure.html
La restricción de 1 dispositivo sim a la vez para las pruebas unitarias de xcodebuild reduce severamente la productividad y agrega exponencialmente costos significativos a Apple y al ecosistema.
El costo para Apple de no admitir la concurrencia para justificar más compras de hardware debe pensarse cuidadosamente, sopesando los riesgos de perder la velocidad del desarrollador frente a otros competidores que tienen menos restricciones en términos de simuladores y EULA.
La ventaja de las pruebas simultáneas en el inicio de sesión del mismo usuario (cómo funcionan la mayoría de los sistemas ci) es la calidad de las aplicaciones de la tienda de aplicaciones de la marca Apple, que a su vez es en parte lo que hace que las personas compren los dispositivos iOS. La mala calidad del software hace que toda la marca sea un poco más lenta y el soporte de concurrencia en simuladores de iOS definitivamente parece ser la forma inteligente de apoyar el ecosistema. Un pequeño corolario del problema en cuestión son las mejoras recientes, como el servidor Xcode de Apple para CI, la funcionalidad de pruebas automatizadas de IU de Xcode en Xcode 7.
Alentar gastos generales innecesarios para que las personas compren cantidades masivas de hardware, configuración, configuración, sin mencionar a las numerosas personas necesarias para admitir todas las máquinas, redes y puntos de alimentación, etc., potencialmente dañará las ganancias de Apple al final, ya que no todos son como Apple y capaz de permitirse bastidores de MacPro o Mac Mini solo para soportar pruebas concurrentes en simuladores. El objetivo de un simulador es evitar el uso del hardware y también acelerar las pruebas.
Además, las limitaciones de EULA en las máquinas virtuales hacen que el caso de las máquinas virtuales en Mac Pro sea bastante débil. Este tipo de hardware sería atractivo si pudieran ejecutarse múltiples sims, pero dado que las pruebas unitarias concurrentes no son compatibles (excepto en las dos condiciones anteriores: una versión diferente de XCode y un dispositivo de simulador diferente) probablemente nos quedaremos con Mac Mini para construir infraestructura.
Estas limitaciones de SIM y EULA de Apple no solo hacen que el proceso de compilación sea más lento sino que también agregan complejidad y costo innecesarios. Puede que no sea tan preocupante para las aplicaciones pequeñas, pero a medida que las aplicaciones crecen en tamaño y complejidad, la compilación puede demorar más de una hora (escuché que las compilaciones de Facebook iOS pueden tomar tanto tiempo). Nadie quiere esperar una hora para saber si una compilación pasó.
Conocemos soluciones de hackeo como ejecutar máquinas virtuales ESXI en Mac Minis que no funcionan bien con OS X y xcodebuild en proyectos grandes con compilaciones que toman más de 10 minutos en una Mac Book Pro o Mac Mini moderna, o diferentes cuentas de inicio de sesión en una máquina de metal desnudo al entorno solo para poder ejecutar pruebas concurrentes en la misma versión de Xcode y el mismo dispositivo simulador.
ESXi no es oficialmente compatible, aunque funciona bastante bien. Una de las razones por las que VMware podría no ser compatible con el hardware de Mac Mini todavía es la falta de memoria ECC, aunque Mac Pro es compatible ya que tiene memoria ECC, es probable que tenga los mismos problemas que Mac Mini en términos de versiones de iOS más lentas en comparación con el metal desnudo prueba en la misma configuración de hardware y software (el único cambio es VM frente a bare metal con OS X). MacPro no ha sido probado por nosotros en este momento. En nuestra experiencia, VMware Fusion también es bastante lento en términos de rendimiento.
Lo que es más importante, los desarrolladores deberán esperar más tiempo cuando los problemas mencionados se combinen a menos que el conjunto de máquinas sea lo suficientemente grande como para soportar una línea de cambios (una compilación de CI por cada 2 desarrolladores, relación muy alta de máquinas por desarrollador). Las máquinas de compilación de CI deberían poder ejecutar más compilaciones concurrentes y más pruebas concurrentes que 1.
Una de las otras observaciones sobre los simuladores de iOS es que parecen ser un trabajo en progreso y completamente inacabados incluso después de 7 versiones principales. El subcomando ''xcrun simctl'' tiene una opción --set que puede permitir cierta flexibilidad de algún tipo pero no está seguro de qué valor posible es válido, y lo mismo con --noxpc. Nadie debería tener que adivinar los valores apropiados y, además, debería haber una página de manual que cubra esta opción y quizás un ejemplo. ¿Cuáles son algunos casos de uso para estas 2 opciones interesantes?
Puede decir, bueno, ninguna aplicación debe diseñarse para tener una gran huella que garantice la ejecución de pruebas concurrentes, y hacer uso de una mejor arquitectura basada en XPC, ya que las aplicaciones monolíticas son el problema. Esto puede ser correcto, no es una solución tan pragmática como podríamos esperar, y el problema persiste si tiene más de 20 aplicaciones para construir en la misma infraestructura.
Hacer que la configuración y los procesos de la máquina sean tan genéricos y escalables como sea posible para un mayor rendimiento requerirá algo de trabajo en el simulador (aplicación + desarrolladores centrales). También requiere un alto nivel de colaboración entre todos los desarrolladores de simuladores de Apple y el propietario (s) del producto del simulador necesita ordenar la cartera de pedidos del producto correctamente para este problema para llamar la atención :-)
Puede ejecutar dos instancias del simulador de iOS desde la línea de comandos. No se adjuntarán a la depuración de Xcode; de hecho, parece que solo funciona si lo hace sin Xcode ejecutándose en absoluto.
Primero, debe ejecutar la aplicación en el simulador desde Xcode para poder instalarla en el simulador. Asegúrese de estar ejecutando los mismos simuladores que finalmente usará
Ahora abra una ventana de Terminal y haga esto.
cd /Applications/Xcode.app/Contents/Developer/Applications
open -n iOS/ Simulator.app
open -n iOS/ Simulator.app
Actualización para Xcode 7: con Xcode 7, el nombre de la aplicación del simulador ha cambiado, por lo que es esto:
cd /Applications/Xcode.app/Contents/Developer/Applications
open -n Simulator.app
open -n Simulator.app
Cuando se inicie el segundo, recibirá una alerta de error. Simplemente descarte y seleccione un dispositivo diferente de "Hardware" »" Dispositivo ". Ahora tiene dos simuladores en ejecución, y cualquier aplicación que ya haya instalado en ellos desde Xcode estará allí.
Puede ejecutar varias instancias de simulador para diferentes perfiles de hardware y depurarlas. Primero, debe ejecutar su aplicación desde XCode para cada tipo de hardware (iPhone 6, iPad, etc.) para instalarla en instancias de simulador. Luego ejecute instancias de simulador y su aplicación como se explica anteriormente. Para depurarlo, puede adjuntar el depurador a los procesos en ejecución desde el menú "XCode-> Debug-> Adjuntar al proceso". Puede consultar esta entrada del blog para ver un ejemplo: http://oguzdemir.dualware.com/?p=43
aquí un pequeño script en .sh para enumerar UDID de simuladores en su computadora y ejecutarlo. Copie el código a continuación en un archivo con la extensión ".sh" y ejecútelo en la terminal.
Cómo:
Paso 1. Liste los dispositivos con la opción 1 y copie el UDID deseado
Paso 2. Ejecute la opción 2 y pegue el UDID, luego presione la tecla Intro
Tenga cuidado: verifique que la ruta que contiene sus simuladores esté bien (si no, reemplace por su ruta)
#!/bin/sh
PS3=''Type the number of your choice (1, 2 or 3) and press Enter: ''
options=("List Devices" "Run Simulator" "Quit")
select opt in "${options[@]}"
do
case $opt in
"List Devices")
xcrun simctl list devices
echo "/033[1m/n/nCopy the UDID in parentheses of the device which you want run and launch option 2 (Run Simulator)/033[0m"
;;
"Run Simulator")
read -p ''Type device UDID which you want launch: '' currentDeviceUDID
open -n /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app/ --args -CurrentDeviceUDID $currentDeviceUDID
;;
"Quit")
break
;;
*) echo invalid option;;
esac
done
Gracias,