У меня есть две разные цели для моего приложения iOS. Можно ли одновременно запускать два приложения на двух разных экземплярах симулятора? Это нормально, если не потребуется использовать отладчик Xcode. Пока что единственным решением, которое я нашел, была установка двух версий XCode, но это очень тяжелое / занимающее много места решение.
Xcode6: запустить два экземпляра симулятора
Ответы (7)
Вы можете запустить два экземпляра симулятора 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, будут там.
xcodebuild
CLI, но я не уверен, как связать это с конкретным симулятором.
- person abbood; 21.07.2015
xcodebuild
поддерживает параметр -destination, который позволяет указать конкретный симулятор. Я не пробовал, но похоже, что вы ищете.
- person i40west; 21.07.2015
Xcode 9+
Xcode 9 теперь поддерживает запуск нескольких симуляторов. Об этом было объявлено на WWDC 2017.
Просто перейдите и смените симулятор в Xcode, Cmd + R, и вы увидите всплывающее окно нового симулятора.
Успешно протестировано, что решение i40west работает для ручного запуска симулятора, но кажется глупым, что в наши дни симулятор iOS требует разных версий Xcode И разных типов устройств при запуске параллельных тестов из командной строки (немного другой вариант использования, но связанный с исходным вопросом вверху ).
См. Статью Apple здесь, которая наиболее актуальна для сборок и тестов из командной строки: https://developer.apple.com/library/ios/technotes/tn2339/_index.html.
Множественные параллельные тесты сработали для нас, если передать правильный --args - в 'iOS simulator.app' перед запуском команды 'xcodebuild test' с правильным значением '-destination', совпадающим с запуском симулятора со значением UUID из вывода 'xcrun simctl list 'и установка переменной среды DEVELOPER_DIR для выбора различных двоичных файлов версии XCode (т.е. базовый путь к Xcode 6.1 и 6.4)
Причина необходимости одновременных модульных тестов на одном физическом компьютере и одном и том же устройстве-симуляторе iOS, таком как iPad или iPhone и одна и та же версия Xcode, заключается в первую очередь в поддержке CI (непрерывной интеграции) любого проекта iOS, при этом одна и та же система сборки может запускать более 1 сборки из нескольких приложений (у нашей компании около 30 приложений) одновременно при регистрации, ветки функций автоматически сканируются и создаются агентом Bamboo без необходимости ждать завершения других запущенных сборок - Bamboo поддерживает этот тип автоматической сборки на автоматическом обнаруженные функциональные ветви, если они включены.
Что касается того, что происходит при запуске нескольких одновременных тестов, мы запускаем несколько команд «xcodebuild test» дважды подряд в разных окнах Terminal.app, в результате появляется только одно окно симулятора, и тесты не проходят в простейшем тесте.
Когда мы усложняем критерии входа для нашего тестового запуска, разные версии Xcode для каждой sim-карты и тестового запуска, при использовании DEVELOPER_DIR в соответствии с страницами руководства (тест xcodebuild) мы указываем другое устройство, которое открывается в двух отдельных окнах, но в результате любые запущенные тесты в первом окне прерываются вторым окном симулятора iOS.
Кажется, что под капотом есть общий общий ресурс, который мешает, не уверен, что он предназначен, или просто новая функция, которая требует более нескольких дней серьезных размышлений о том, как лучше реализовать параллельные запуски тестов без неблагоприятных воздействий.
Мы не хотим использовать виртуальные машины для обхода ограничений симулятора, так как наш опыт и другие в целом показывают, что производительность сборки iOS на виртуальных машинах с большим количеством небольших файлов ниже, чем на физическом оборудовании. Виртуальные машины обычно значительно замедляют сборку из-за проблем с вводом-выводом в сочетании программного обеспечения VMware и оборудования и / или прошивки Apple. Извините, что виртуальные машины не работают хорошо - сайт фактически гетто предоставил нам инструкции по установке ESXi 5.5 на Mac Mini для нашей фермы сборки.
Мы столкнулись с проблемой производительности сборки из-за того, что ESXi 5.5 на Mac Mini был медленнее, чем голый металл, даже с твердотельным накопителем в 2 или более раз (то есть 10-минутная сборка без сборки занимает 20 минут на виртуальной машине). Обратитесь к статье ниже о том, почему.
https://corner.squareup.com/2015/07/ios-build-infrastructure.html < / а>
Ограничение одновременного использования одного SIM-устройства для модульных тестов xcodebuild серьезно снижает производительность и значительно увеличивает затраты Apple и экосистемы.
Следует тщательно продумать затраты Apple на отказ от поддержки параллелизма для оправдания закупок большего количества оборудования, взвесив риски потери скорости разработки по сравнению с другими конкурентами, у которых меньше ограничений с точки зрения симуляторов и лицензионного соглашения с конечным пользователем.
Преимущество параллельных тестов при входе в систему одного и того же пользователя (как работает большинство систем ci) заключается в том качестве приложений магазина приложений под брендом Apple, которое, в свою очередь, отчасти заставляет людей покупать устройства iOS. Низкое качество программного обеспечения делает весь бренд более медленным, а поддержка параллелизма в симуляторах iOS определенно кажется разумным способом поддержки экосистемы. Некоторым следствием проблемы являются недавние улучшения, такие как сервер Apple Xcode для CI, функция автоматизированных тестов пользовательского интерфейса Xcode в Xcode 7.
Поощрение ненужных накладных расходов, чтобы заставить людей покупать массовое количество оборудования, установки, конфигурации, не говоря уже о том, что множество людей требуется для поддержки всех машин, сетей, точек питания и т. может позволить себе стойки 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 по сравнению с голым металлом. тесты на той же конфигурации оборудования и программного обеспечения (единственное отличие - виртуальная машина по сравнению с голым железом под управлением OS X). MacPro в настоящее время нами не тестировался. По нашему опыту, VMware Fusion также довольно медленный с точки зрения производительности.
Что еще более важно, разработчикам придется ждать дольше, когда вышеупомянутые проблемы будут объединены вместе, если только пул машин не будет достаточно большим для поддержки набора изменений (одна сборка CI на каждые 2 разработчика, очень высокое соотношение машин к разработчику). Машины сборки CI должны иметь возможность запускать больше параллельных сборок и больше одновременных тестов, чем 1.
Еще одно наблюдение, касающееся симуляторов iOS, заключается в том, что они, похоже, находятся в стадии разработки и полностью незавершены даже после 7 основных версий. Подкоманда 'xcrun simctl' имеет параметр --set, который может допускать некоторую гибкость, но не уверен, какое возможное значение является допустимым, и то же самое с --noxpc. Никто не должен угадывать подходящие значения, и, кроме того, должна быть справочная страница, описывающая этот параметр и, возможно, пример. Каковы варианты использования этих двух интересных вариантов?
Вы можете сказать, что ни одно приложение не должно иметь большую площадь, требующую одновременного выполнения тестов, и использовать лучшую архитектуру, основанную на XPC, поскольку проблема заключается в монолитных приложениях. Это вполне может быть правильным, это не такое прагматичное решение, как мы могли бы надеяться, и проблема остается, если у вас есть 20+ приложений для создания на одной и той же инфраструктуре.
Чтобы сделать конфигурацию машины и процессы как можно более универсальными и масштабируемыми для повышения пропускной способности, потребуется некоторая работа над симулятором (разработчики приложения + ядра). Это также требует высокого уровня сотрудничества между всеми разработчиками симуляторов Apple и владельцами симуляторов, которые должны правильно упорядочить отставание продукта, чтобы эта проблема привлекла внимание :-)
FBSimulatorControl от Facebook предоставляет программный способ сделать это. Он доступен по адресу https://github.com/facebook/FBSimulatorControl.
Метод testLaunchesMultipleSimulatorsConcurrently
в FBSimulatorControlSimulatorLaunchTests.m содержит пример кода, иллюстрирующий запуск нескольких симуляторов. .
Вы можете запустить несколько экземпляров симулятора для разных профилей оборудования и отладить их. Во-первых, вам нужно запустить приложение из XCode для каждого типа оборудования (iPhone 6, iPad и т. Д.), Чтобы установить его в экземпляры симулятора. Затем запустите экземпляры симулятора и ваше приложение, как описано выше. Для его отладки вы можете подключить отладчик к запущенным процессам из меню «XCode-> Debug-> Attach to Process». Вы можете проверить эту запись в блоге для примера: http://oguzdemir.dualware.com/?p=43
вот небольшой скрипт в .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
Спасибо,
Это 2020 год, xCode 11.4: File -> Open Device -> iOs 13.4 -> и выберите версию iPhone, которая не была запущена первой, и вы получите второй эмулятор.