Testato con successo che la soluzione di i40west funziona per avviare manualmente il simulatore, ma sembra sciocco che in questo giorno ed età, un simulatore iOS richiede diverse versioni di Xcode E diversi tipi di dispositivi quando si eseguono test simultanei dalla riga di comando (caso d'uso leggermente diverso ma correlato alla domanda originale in alto ).
Fare riferimento all'articolo Apple qui che è più rilevante per build e test da riga di comando:
https://developer.apple.com/library/ios/technotes/tn2339/_index.html
Più test simultanei hanno funzionato bene per noi se si passa il corretto --args - a 'iOS simulator.app' prima di eseguire il comando 'xcodebuild test' con il valore corretto di '-destination' che corrisponde al lancio del simultizzatore con il valore dell'UUID dall'output di 'xcrun simctl list 'e impostando la variabile d'ambiente DEVELOPER_DIR per selezionare diversi binari della versione XCode (cioè il percorso di base per Xcode 6.1 e 6.4)
La ragione per la necessità di test di unità simultanei sulla stessa macchina fisica e sullo stesso dispositivo simulatore iOS come iPad o iPhone e la stessa versione di Xcode è principalmente per supportare CI (integrazione continua) di qualsiasi progetto iOS in cui lo stesso sistema di build può eseguire più di 1 build di più build le app (la nostra azienda ha circa 30 app) alla volta al momento del check-in sui rami delle funzionalità vengono automaticamente scansionate e costruite dall'agente Bamboo senza dover attendere il completamento di altre build in esecuzione - Bamboo supporta questo tipo di build automatica su auto- scoperti i rami delle funzionalità se abilitati.
Per quanto riguarda ciò che accade quando si eseguono più test simultanei, eseguiamo più comandi 'xcodebuild test' due volte in successione in diverse finestre Terminal.app, il risultato è che viene visualizzata solo una finestra del simulatore e i test falliscono nel test più semplice.
Quando complichiamo i criteri di accesso per il nostro lancio di prova, diverse versioni di Xcode per ogni simulazione e lancio di prova, quando usiamo DEVELOPER_DIR come da pagine man (xcodebuild test) stiamo specificando un dispositivo diverso che si apre in due finestre separate, ma il risultato è quello eventuali test in esecuzione nella prima finestra vengono interrotti dalla seconda finestra del simulatore iOS.
Sembra esserci una risorsa comune condivisa sotto il cofano che si sta intromettendo, non sono sicuro che sia intenzionale o solo una nuova funzionalità che richiede più di qualche giorno di seria riflessione su come implementare al meglio le esecuzioni di test simultanee senza impatti negativi.
Non vogliamo utilizzare le VM per aggirare le limitazioni della simulazione poiché la nostra esperienza e di altri in generale è che iOS costruisce le prestazioni su VM con un numero elevato di piccoli file è più lento dell'hardware fisico. Le VM generalmente rallentano notevolmente la creazione a causa di problemi di I / O nella combinazione di software VMware e hardware e / o firmware Apple. Scusa virtualmenteghetto ma per noi le VM non funzionano bene - il sito virtualmenteghetto ci ha fornito le istruzioni su come installare ESXi 5.5 su Mac Mini per la nostra build farm.
Abbiamo riscontrato il problema delle prestazioni di build con ESXi 5.5 su Mac Mini che è più lento del bare metal anche con SSD di un fattore 2 o più (cioè una build baremetal di 10 minuti richiede 20 su VM). Fare riferimento all'articolo squareup di seguito sul perché.
https://corner.squareup.com/2015/07/ios-build-infrastructure.html
La limitazione di 1 dispositivo sim alla volta per i test di unità xcodebuild riduce notevolmente la produttività e aggiunge in modo esponenziale costi significativi ad Apple e all'ecosistema.
Il costo per Apple di non supportare la concorrenza per giustificare più acquisti di hardware dovrebbe essere valutato attentamente, soppesando i rischi di perdere velocità di sviluppo rispetto ad altri concorrenti che hanno meno restrizioni in termini di sim e EULA.
Il vantaggio di test simultanei nello stesso accesso utente (come funziona la maggior parte dei sistemi ci) è quella qualità delle app di app store a marchio Apple che a sua volta è in parte ciò che fa sì che le persone acquistino i dispositivi iOS in primo luogo. La scarsa qualità del software rende l'intero marchio un po 'più lento e il supporto della concorrenza nei simulatori iOS sembra sicuramente il modo intelligente per supportare l'ecosistema. Un po 'un corollario al problema in questione sono i recenti miglioramenti come il server Xcode di Apple per CI, la funzionalità di test dell'interfaccia utente automatizzata di Xcode in Xcode 7.
Incoraggiare inutili spese generali per far sì che le persone acquistino grandi quantità di hardware, installazione, configurazione, per non parlare di numerose persone necessarie per supportare tutte le macchine, la rete e i punti di alimentazione, ecc., Alla fine, potenzialmente danneggerà i profitti di Apple poiché non tutti sono come Apple e in grado di permettersi rack di MacPro o Mac Mini solo per supportare test simultanei su simulatori. Il punto centrale di un simulatore è evitare di utilizzare l'hardware e anche velocizzare i test.
Inoltre, le limitazioni dell'EULA sulle VM rendono il caso per le VM su Mac Pro piuttosto debole. Questo tipo di hardware sarebbe interessante se potessero essere eseguiti più sim, ma poiché i test di unità simultanei non sono supportati (tranne nelle due condizioni precedenti - diversa versione di XCode e diverso dispositivo di simulazione) probabilmente rimarremo con Mac Mini per l'infrastruttura di build.
Queste limitazioni di sim e EULA di Apple non solo rallentano la pipeline di compilazione, ma aggiungono anche complessità e costi non necessari. Potrebbe non essere così preoccupante per le piccole app, ma man mano che le app crescono in dimensioni e complessità, la build può richiedere fino a un'ora (ho sentito che le build iOS di Facebook possono richiedere così tanto tempo). Nessuno vuole aspettare un'ora per sapere se una build è stata superata.
Conosciamo soluzioni di hacking come l'esecuzione di VM ESXI su Mac Mini che non funzionano bene in termini di prestazioni con OS X e xcodebuild su progetti di grandi dimensioni con build che richiedono più di 10 minuti su un moderno Mac Book Pro o Mac Mini o diversi account di accesso sulla macchina bare metal nell'ambiente solo per poter eseguire test simultanei sulla stessa versione di Xcode e sullo stesso dispositivo simulatore.
ESXi non è ufficialmente supportato anche se funziona abbastanza bene. Uno dei motivi per cui VMware potrebbe non supportare l'hardware Mac Mini è ancora la mancanza di memoria ECC, sebbene Mac Pro sia supportato in quanto ha memoria ECC, probabilmente ha gli stessi problemi del Mac Mini in termini di build iOS che rallenta rispetto al bare metal test sulla stessa configurazione hardware e software (l'unica modifica è la VM rispetto al bare metal con OS X). MacPro non è stato testato da noi in questo momento. Nella nostra esperienza VMware Fusion è piuttosto lento anche in termini di prestazioni.
Ancora più importante, gli sviluppatori dovranno attendere più a lungo quando i problemi sopra menzionati vengono combinati insieme a meno che il pool di macchine non sia abbastanza grande da supportare la pipleline di modifiche (una build CI per ogni 2 sviluppatori, rapporto molto alto tra macchine e sviluppatore). Le macchine di compilazione CI dovrebbero essere in grado di eseguire più build simultanee e più test simultanei di 1.
Una delle altre osservazioni sui simulatori iOS è che sembrano essere un work in progress e completamente incompiuti anche dopo 7 versioni principali. Il sottocomando 'xcrun simctl' ha un'opzione --set che può consentire una certa flessibilità di qualche tipo ma non è sicuro di quale possibile valore sia valido, e lo stesso con --noxpc. Nessuno dovrebbe aver bisogno di indovinare valori appropriati e inoltre, dovrebbe esserci una pagina man che copre questa opzione e forse un esempio. Quali sono alcuni casi d'uso per queste 2 interessanti opzioni?
Potresti dire, beh, nessuna app dovrebbe essere progettata per avere un ampio footprint che garantisca l'esecuzione di test simultanei e l'utilizzo di un'architettura migliore basata su XPC, poiché il problema sono le app monolitiche. Questo potrebbe essere corretto, non è una soluzione così pragmatica come potremmo sperare e il problema rimane se hai più di 20 app da costruire sulla stessa infrastruttura.
Rendere la configurazione e i processi della macchina il più generici e scalabili possibile per un throughput più elevato richiederà del lavoro sul simulatore (app + core devs). Richiede anche un alto livello di collaborazione tra tutti gli sviluppatori del simulatore Apple e il proprietario del prodotto del simulatore deve ordinare correttamente il backlog del prodotto affinché questo problema attiri l'attenzione :-)
