Ответ 1

Вы можете запустить два экземпляра симулятора iOS из командной строки. Они не будут привязаны к отладке Xcode - действительно, это работает, только если вы делаете это без запуска Xcode.

Сначала вам нужно запустить приложение в симуляторе из Xcode, чтобы установить его в симуляторе. Убедитесь, что вы используете те же симуляторы, которые вы в конечном итоге будете использовать

Теперь откройте окно терминала и сделайте это.

cd /Applications/Xcode.app/Contents/Developer/Applications
open -n iOS\ Simulator.app
open -n iOS\ Simulator.app

Обновление для Xcode 7: С Xcode 7 имя приложения симулятора изменилось, поэтому вместо этого:

cd /Applications/Xcode.app/Contents/Developer/Applications
open -n Simulator.app
open -n Simulator.app

Когда второй запускается, вы получите предупреждение об ошибке. Просто отпустите его и выберите другое устройство из раздела "Оборудование" "Устройство". Теперь у вас есть два симулятора, и все приложения, которые вы уже установили в них из Xcode, будут там.

Ответ 2

Xcode 9

Xcode 9 теперь поддерживает запуск нескольких симуляторов. Это было объявлено в WWDC 2017.

Просто пойдите и измените симулятор в Xcode, Cmd + R, и вы увидите новый симулятор, появляющийся.

Ответ 3

Успешно протестировано, что решение i40west работает для запуска симулятора вручную, но кажется глупым, что в этот день и возраст симулятор iOS требует разных версий Xcode и разных типов устройств при выполнении параллельных тестов из командной строки (немного другой вариант использования, но связанный с оригиналом вопрос наверху).

Обратитесь к статье Apple, которая наиболее важна для сборки и тестов командной строки: https://developer.apple.com/library/ios/technotes/tn2339/_index.html

Несколько параллельных тестов работали отлично для нас, если вы передавали правильные -args - на "iOS simulator.app" перед запуском команды "xcodebuild test" с правильным значением "-добавление", совпадающим с запуском симулятора со значением UUID с вывода из списка "xcrun simctl list" и установки переменной среды DEVELOPER_DIR для выбора различных двоичных файлов версии XCode (т.е. базового пути к Xcode 6.1 и 6.4)

Причина необходимости параллельных модульных тестов на одном и том же физическом компьютере и том же iOS-симуляторе, таком как iPad или iPhone, и той же версии Xcode, в первую очередь, для поддержки CI (непрерывной интеграции) любого проекта iOS, при котором одна и та же система сборки может запускать более 1 сборка нескольких приложений (наша компания имеет 30 приложений или около того) в момент регистрации на ветких функций автоматически сканируется и создается агентом Bamboo без необходимости ждать завершения других запущенных Builds - Bamboo поддерживает этот тип автоматической сборки при активированных автообнаружениях.

Что касается того, что происходит при запуске нескольких параллельных тестов, мы запускаем несколько команд "xcodebuild test" дважды подряд в разных окнах Terminal.app, в результате появляется только одно окно симулятора, и тесты проваливаются в простейшем тесте.

Когда мы усложняем критерии входа для нашего тестового запуска, разные версии Xcode для каждого sim и запуска теста, при использовании DEVELOPER_DIR в соответствии с man-страницами (xcodebuild test) мы указываем другое устройство, которое открывается в двух отдельных окнах, но результатом является то, что любые текущие тесты в первом окне прерываются вторым окном симулятора iOS.

Кажется, что существует общий общий ресурс под капотом, который мешает, не уверен, что он предназначен или просто новая функция, для которой требуется более чем несколько дней серьезной мысли о том, как лучше реализовать параллельные тестовые прогоны wihout неблагоприятные последствия.

Мы не хотим использовать виртуальные машины для работы с ограничениями на сим, поскольку наш опыт и другие в целом - это то, что производительность сборки iOS на виртуальных машинах с большим количеством небольших файлов медленнее, чем физическое. Виртуальные машины обычно замедляют сборку из-за проблем ввода-вывода в сочетании программного обеспечения VMware и аппаратного обеспечения Apple и/или прошивки. Извините virtualghetto, но для нас виртуальные машины не работают хорошо - сайт virtualghetto предоставил нам инструкции по установке ESXi 5.5 на Mac Mini для нашей фермы сборки.

Мы столкнулись с проблемой производительности сборки с ESXi 5.5 на Mac Mini медленнее, чем голый металл, даже с SSD в 2 раза или более (т.е. 10-минутная сборка без сборок занимает 20 на виртуальной машине). Обратитесь к статье, приведенной ниже, о том, почему.

https://corner.squareup.com/2015/07/ios-build-infrastructure.html

Ограничение 1 sim-устройства за один раз для модульных тестов xcodebuild значительно снижает производительность и экспоненциально увеличивает значительные затраты для Apple и экосистемы.

Стоимость Apple, не поддерживающая concurrency, чтобы оправдать дополнительные покупки оборудования, должна быть тщательно продуманной, взвешивая риски потери скорости разработчика против других конкурентов, у которых меньше ограничений в отношении симов и лицензионного соглашения.

Преимущество одновременных тестов в том же входе в систему (как работает большинство систем ci) - это качество приложений для приложений приложений Apple, которые, в свою очередь, частично заставляют людей покупать устройства iOS в первую очередь. Плохое качество программного обеспечения делает весь бренд немного более грязным, а поддержка concurrency в симуляторах iOS определенно кажется умным способом поддержки экосистемы. Немногим из следствия этой проблемы являются недавние улучшения, такие как Apple Xcode-сервер для CI, Xcode автоматизированных тестов пользовательского интерфейса в Xcode 7.

Поощрение ненужных накладных расходов, чтобы люди покупали массовое количество аппаратного обеспечения, настройки, конфигурации, не говоря уже о том, что многие люди, необходимые для поддержки всех машин, сети и точек питания, и т.д., потенциально могут нанести ущерб прибыли Apple, в конце концов, как Apple, и может позволить себе столы MacPro или Mac Mini только для поддержки параллельных тестов на симуляторах. Весь смысл симулятора состоит в том, чтобы избежать использования аппаратного обеспечения, а также ускорить тесты.

Плюс ограничения EULA для виртуальных машин делают случай для виртуальных машин на Mac Pro довольно слабым. Этот тип аппаратного обеспечения был бы привлекательным, если бы несколько симов могли запускаться, но поскольку параллельные модульные тесты не поддерживаются (за исключением двух вышеперечисленных условий - другой версии XCode и другого симуляторного устройства), мы, скорее всего, будем использовать Mac Mini для инфраструктуры построения.

Эти ограничения на sim и EULA от Apple не только замедляют работу сборки, но также добавляют излишнюю сложность и стоимость. Возможно, это не так касается небольших приложений, но по мере того, как приложения растут по размеру и сложности, сборка может занять более часа (я слышал, что сборка iOS для Facebook может занять много времени). Никто не хочет ждать часа, чтобы узнать, прошла ли сборка.

Мы знаем о таких хакерских решениях, как запуск виртуальных машин ESXI на Mac Minis, которые не очень хорошо работают с OS X и xcodebuild в крупных проектах со сборками, которые занимают более 10 минут на современной Mac Book Pro или Mac Mini или разные учетные записи на голом металлическом компьютере для среды, чтобы иметь возможность запускать параллельные тесты на той же версии Xcode и одном и том же симуляторе.

ESXi официально не поддерживается, хотя работает очень хорошо. Одной из причин, по которой VMware может не поддерживать оборудование Mac Mini, пока не хватает памяти ECC, хотя Mac Pro поддерживается, так как у него есть память ECC, у него, вероятно, есть те же проблемы, что и Mac Mini с точки зрения iOS, строит медленнее по сравнению с голыми металлами тесты на одном и том же аппаратном и программном обеспечении (только изменение - это виртуальная машина против голого металла, работающая с ОС X). В настоящее время MacPro не тестировалось нами. По нашему опыту VMware Fusion работает довольно медленно и с точки зрения производительности.

Более важно, что разработчикам придется подождать дольше, когда вышеупомянутые проблемы будут объединены вместе, если пул машин не будет достаточно большим для поддержки множественных изменений (одна сборка CI для каждых 2 разработчиков, очень высокое отношение машин к разработчику). Машины сборки CI должны иметь возможность запускать более параллельные сборки и более параллельные тесты, чем 1.

Одно из других замечаний о симуляторах iOS заключается в том, что они, похоже, работают незавершенными и полностью незавершенными даже после 7 основных версий. Подкоманда "xcrun simctl" имеет параметр -set, который может позволить некоторую гибкость некоторого вида, но не уверен, что допустимое значение действительно, и то же самое с --noxpc. Никто не должен угадать соответствующие значения, и, кроме того, должна быть страница руководства, которая охватывает эту опцию и, возможно, пример. Каковы некоторые варианты использования этих двух интересных вариантов?

Вы можете сказать, что ни одно приложение не должно быть спроектировано так, чтобы иметь большой след, который требует одновременного теста для запуска и использования лучшей архитектуры на базе XPC, поскольку проблема с монолитом является проблемой. Это может быть очень правильным, это не такое прагматическое решение, на что мы могли бы надеяться, и проблема остается, если у вас есть 20 приложений для создания такой же инфраструктуры.

Создание конфигурации машины и процессов как общих и масштабируемых, насколько это возможно для более высокой пропускной способности, потребует некоторой работы над симулятором (разработчиками приложений + core). Это также требует высокого уровня сотрудничества между всеми разработчиками симулятора Apple и владельцем (ов) продукта симулятора, чтобы правильно заказать товарный запас для этой проблемы, чтобы привлечь внимание: -)

Ответ 4

FBSimulatorControl из Facebook предоставляет программный способ сделать это. Он доступен в https://github.com/facebook/FBSimulatorControl.

В методе testLaunchesMultipleSimulatorsConcurrently в FBSimulatorControlSimulatorLaunchTests.m приведен пример кода, иллюстрирующий запуск нескольких тренажеров.

Ответ 5

Вы можете запускать несколько экземпляров симулятора для разных профилей оборудования и отлаживать их. Во-первых, вам нужно запустить приложение из XCode для каждого типа оборудования (iPhone 6, iPad и т.д.), Чтобы установить его в экземпляры симулятора. Затем запустите экземпляры симулятора и ваше приложение, как описано выше. Чтобы отладить его, вы можете подключить отладчик к запущенным процессам из меню "XCode- > Debug- > Attach to Process". Вы можете проверить эту запись в блоге для примера : http://oguzdemir.dualware.com/?p=43

Ответ 6

здесь немного script в .sh, чтобы перечислить UDID симуляторов на вашем компьютере и запустить его. Скопируйте приведенный ниже код в файл с расширением ".sh" и запустите его в терминале.

Как сделать:

Шаг 1. Перечислите устройства с параметром 1 и скопируйте требуемый UDID

Шаг 2. Запустите опцию 2 и вставьте UDID, затем нажмите клавишу ввода

Будьте осторожны: убедитесь, что путь, содержащий ваши симуляторы, в порядке (если не заменить по вашему пути)

#!/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

Спасибо,