Xcode6: Exécuter deux instances du simulateur
J'ai deux cibles différentes pour mon application iOS. Est-il possible d'exécuter simultanément les deux applications sur deux instances différentes du simulateur? Ce n'est pas grave s'il ne faut pas profiter du débogueur du Xcode. Jusqu'à présent, la seule solution que j'ai trouvée consistait à installer deux versions de XCode, mais c'est une solution très lourde/qui prend beaucoup d'espace.
Vous pouvez exécuter deux instances du simulateur iOS à partir de la ligne de commande. Ils ne seront pas attachés au débogage Xcode - en effet, cela ne semble fonctionner que si vous le faites sans que Xcode soit exécuté.
Tout d'abord, vous devez exécuter l'application dans le simulateur à partir de Xcode, afin de l'installer dans le simulateur. Assurez-vous que vous utilisez les mêmes simulateurs que vous utiliserez
Ouvrez maintenant une fenêtre de terminal et faites-le.
cd /Applications/Xcode.app/Contents/Developer/Applications
open -n iOS\ Simulator.app
open -n iOS\ Simulator.app
Mise à jour pour Xcode 7: Avec Xcode 7, le nom de l'application du simulateur a changé, c'est donc ceci:
cd /Applications/Xcode.app/Contents/Developer/Applications
open -n Simulator.app
open -n Simulator.app
Lorsque le second démarrera, vous recevrez une alerte d'erreur. Ne le faites pas et sélectionnez un autre appareil dans “Matériel” "“ Appareil ”. Vous avez maintenant deux simulateurs en marche et les applications que vous avez déjà installées à partir de Xcode seront là.
Xcode 9+
Xcode 9 prend désormais en charge le lancement de plusieurs simulateurs. Cela a été annoncé dans WWDC 2017.
Allez simplement changer le simulateur dans Xcode, Cmd + R et vous verrez apparaître un nouveau simulateur.
Testé avec succès que la solution i40west fonctionne avec le lancement manuel du simulateur mais semble stupide qu’aujourd’hui, un simulateur iOS nécessite différentes versions de Xcode ET différents types de périphériques lorsqu’il exécute des tests simultanés à partir de la ligne de commande (cas d’utilisation légèrement différent mais lié à la question initiale en haut) ).
Reportez-vous à l'article Apple qui est le plus pertinent pour les versions et les tests en ligne de commande: https://developer.Apple.com/library/ios/technotes/tn2339/_index.html =
Plusieurs tests simultanés ont bien fonctionné pour nous si nous passions --args - à 'iOS simulator.app' avant d'exécuter la commande 'xcodebuild test' avec la valeur '-destination' correcte correspondant au lancement simultané avec la valeur UUID à partir de la sortie de 'xcrun simctl list 'et la définition de la variable d’environnement DEVELOPER_DIR pour sélectionner différents fichiers binaires de la version XCode (c’est-à-dire le chemin de base vers Xcode 6.1 et 6.4)
La raison pour laquelle des tests unitaires simultanés sont nécessaires sur la même machine physique et le même dispositif de simulation iOS, tel qu'un iPad ou un iPhone, et la même version de Xcode est principalement destinée à prendre en charge le CI (intégration continue) de tout projet iOS dans lequel le même système de génération peut exécuter plusieurs versions. les applications (notre société compte environ 30 applications) à la fois lors de l’enregistrement sur les branches d’entités sont automatiquement analysées et générées par l’agent Bamboo sans qu’il soit nécessaire d’attendre la fin des autres versions en cours d’exécution - Bamboo prend en charge ce type de génération automatique. branches de fonctionnalités découvertes si activées.
En ce qui concerne ce qui se passe lors de l'exécution de plusieurs tests simultanés, nous exécutons plusieurs commandes 'xcodebuild test' deux fois de suite dans différentes fenêtres Terminal.app. Il en résulte qu'une seule fenêtre de simulateur apparaît et les tests échouent lors du test le plus simple.
Lorsque nous compliquons les critères d'entrée pour notre lancement de test, différentes versions de Xcode pour chaque lancement de sim et test, lorsque nous utilisons DEVELOPER_DIR selon les pages de manuel (test de xcodebuild), nous spécifions un périphérique différent qui s'ouvre dans deux fenêtres distinctes, mais le résultat est que les tests en cours dans la première fenêtre sont interrompus par la seconde fenêtre du simulateur iOS.
Il semble y avoir une ressource partagée commune cachée qui gêne la progression, incertaine ou simplement une nouvelle fonctionnalité nécessitant plus de quelques jours de réflexion sérieuse sur la manière de mieux mettre en œuvre des tests simultanés sans impact négatif.
Nous ne voulons pas utiliser les ordinateurs virtuels pour contourner les restrictions relatives aux simulations, car notre expérience et celle des autres en général est que les performances de création iOS sur les ordinateurs virtuels contenant un grand nombre de petits fichiers sont plus lentes que le matériel physique. Les ordinateurs virtuels ralentissent généralement considérablement la création en raison de problèmes d’entrées/sorties associés au logiciel VMware et au matériel et/ou au micrologiciel Apple. Désolé, virtuellement, mais les ordinateurs virtuels ne fonctionnent pas bien - le site de virtghetto nous a expliqué comment installer ESXi 5.5 sur un Mac Mini pour notre batterie de serveurs de construction.
Nous avons constaté que le problème de performances de construction avec ESXi 5.5 sur Mac Mini était plus lent que le bare metal, même avec les disques SSD, par un facteur supérieur ou égal à 2 (c’est-à-dire qu’une version barémétale de 10 minutes prend 20 sur VM). Reportez-vous à l'article ci-dessous squareup sur pourquoi.
https://corner.squareup.com/2015/07/ios-build-infrastructure.html
La restriction d'un appareil sim à la fois pour les tests d'unité xcodebuild réduit considérablement la productivité et augmente de façon exponentielle les coûts significatifs pour Apple et pour l'écosystème.
Le coût pour Apple de ne pas prendre en charge la concurrence afin de justifier davantage d'achats de matériel doit être réfléchi avec soin, en pesant les risques de perte de vitesse du développeur par rapport à d'autres concurrents moins soumis à des restrictions en termes de sims et de CLUF.
L'avantage des tests simultanés dans la même connexion utilisateur (le fonctionnement de la plupart des systèmes ci) réside dans la qualité des Apple applications de la boutique d'applications de marque, ce qui incite en premier lieu les gens à acheter les appareils iOS. La qualité médiocre des logiciels rend la marque un peu plus lente et la prise en charge de la simultanéité dans les simulateurs iOS semble définitivement être le moyen intelligent de prendre en charge l'écosystème. Un corollaire du problème à résoudre concerne les récentes améliorations, telles que le serveur Xcode d'Apple pour CI, la fonctionnalité de test d'interface utilisateur automatisée de Xcode dans Xcode 7.
Encourager des frais généraux inutiles pour amener les gens à acheter des quantités massives de matériel, d’installation, de configuration, sans parler des nombreuses personnes nécessaires pour prendre en charge toutes les machines, le réseau et les points d'alimentation, etc., pourrait potentiellement nuire aux bénéfices d'Apple, car tout le monde n'est pas comme Apple et capable de s'offrir des racks de MacPro ou Mac Mini uniquement pour prendre en charge des tests simultanés sur des simulateurs. L’intérêt d’un simulateur est d’éviter d’utiliser le matériel et d’accélérer les tests.
De plus, les limitations du CLUF sur les ordinateurs virtuels rendent le cas des ordinateurs virtuels sur Mac Pro assez faible. Ce type de matériel serait intéressant si plusieurs simulateurs pouvaient s'exécuter, mais comme les tests unitaires simultanés ne sont pas pris en charge (sauf dans les deux conditions ci-dessus - version différente de XCode et dispositif de simulateur différent), nous allons probablement nous en tenir à l'infrastructure de compilation de Mac Mini.
Ces limitations de sim et de CLUF de Apple ralentissent non seulement le processus de construction, mais ajoutent également une complexité et des coûts inutiles. Ce n'est peut-être pas si inquiétant pour les petites applications, mais à mesure que les applications grandissent en taille et en complexité, la construction peut prendre plus d'une heure (j'ai entendu dire que les versions Facebook de iOS peuvent prendre autant de temps). Personne ne veut attendre une heure pour savoir si une construction a réussi.
Nous connaissons des solutions de piratage telles que l'exécution de machines virtuelles ESXI sur des Mac Mini qui ne fonctionnent pas bien en termes de performances avec OS X et xcodebuild sur des projets volumineux avec des versions prenant plus de 10 minutes sur un Mac Book Pro ou Mac Mini moderne, ou des comptes de connexion différents. sur une machine nue pour l'environnement juste pour pouvoir exécuter des tests simultanés sur la même version de Xcode et le même dispositif de simulateur.
ESXi n'est pas officiellement pris en charge, bien que cela fonctionne plutôt bien. L'une des raisons pour lesquelles VMware n'est peut-être pas compatible avec le matériel Mac Mini, c'est le manque de mémoire ECC. Bien que Mac Pro soit pris en charge car il possède une mémoire ECC, il présente probablement les mêmes problèmes que le Mac Mini en termes de génération iOS ralentie par rapport au système nu. teste la même configuration matérielle et logicielle (seul le changement est VM par rapport à un système d'exploitation nu OS X). MacPro n'a pas encore été testé par nos soins. Dans notre expérience, VMware Fusion est également assez lent en termes de performances.
Plus important encore, les développeurs devront attendre plus longtemps lorsque les problèmes mentionnés ci-dessus seront combinés, à moins que le pool de machines ne soit suffisamment grand pour prendre en charge toute la ligne de changements (un build CI pour 2 développeurs, très grand nombre de machines par développeur). Les machines de build de CI doivent pouvoir exécuter plus de builds simultanés et plus de tests simultanés que 1.
L'une des autres observations concernant les simulateurs iOS est qu'ils semblent être un travail en cours et complètement inachevé, même après 7 versions majeures. La sous-commande 'xcrun simctl' a une option --set qui peut permettre une certaine souplesse, mais ne sachant pas quelle valeur possible est valide, et même chose avec --noxpc. Personne ne devrait avoir à deviner les valeurs appropriées et, en outre, il devrait y avoir une page de manuel qui couvre cette option et peut-être un exemple. Quels sont quelques cas d'utilisation de ces 2 options intéressantes?
Vous pouvez dire, eh bien, aucune application ne devrait être conçue pour avoir une emprise importante qui justifie l'exécution simultanée de tests et l'utilisation d'une meilleure architecture basée sur XPC, car le problème est celui des applications monolithiques. Cela peut très bien être correct, ce n’est pas une solution aussi pragmatique que nous pourrions l’espérer, et le problème demeure si vous avez plus de 20 applications à développer sur la même infrastructure.
Rendre une configuration et des processus de machine aussi génériques et évolutifs que possible pour un débit plus élevé nécessitera quelques travaux sur le simulateur (app + core devs). Il nécessite également un haut niveau de collaboration entre tous les développeurs de simulateurs Apple et le (s) propriétaire (s) du simulateur doivent commander le backlog de produit correctement pour que ce problème puisse attirer l'attention :-)
FBSimulatorControl de Facebook fournit un moyen par programme de le faire. Il est disponible sur le site https://github.com/facebook/FBSimulatorControl .
La méthode testLaunchesMultipleSimulatorsConcurrently in FBSimulatorControlSimulatorLaunchTests.m contient un exemple de code illustrant le lancement de plusieurs simulateurs.
voici un petit script en .sh pour lister l'UDID des simulateurs sur votre ordinateur et l'exécuter. Copiez le code ci-dessous dans un fichier avec l'extension ".sh" et exécutez-le dans le terminal.
Comment:
Étape 1. Répertoriez les périphériques avec l'option 1 et copiez le UDID souhaité
Étape 2. Exécutez l'option 2 et collez le UDID, puis appuyez sur la touche Entrée.
Attention: vérifiez que le chemin qui contient vos simulateurs est correct (sinon remplacez-le par votre chemin)
#!/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
Merci,
Vous pouvez exécuter plusieurs instances de simulateur pour différents profils matériels et les déboguer. Tout d'abord, vous devez exécuter votre application à partir de XCode pour chaque type de matériel (iPhone 6, iPad, etc.) afin de l'installer dans des instances de simulateur. Exécutez ensuite les instances du simulateur et votre application comme expliqué ci-dessus. Pour le déboguer, vous pouvez attacher le débogueur aux processus en cours à partir du menu "XCode-> Debug-> Attacher au processus". Vous pouvez consulter cette entrée de blog pour un exemple: http://oguzdemir.dualware.com/?p=4