Xcode6 : 시뮬레이터의 두 인스턴스 실행

Xcode6 : 시뮬레이터의 두 인스턴스 실행

---

iOS 앱에 대해 두 가지 다른 대상이 있습니다. 두 개의 서로 다른 시뮬레이터 인스턴스에서 두 개의 앱을 동시에 실행할 수 있습니까? Xcode의 디버거를 활용할 필요가 없다면 괜찮습니다. 지금까지 내가 찾은 유일한 솔루션은 두 가지 버전의 XCode를 설치하는 것이지만 매우 무겁고 공간 소모적 인 솔루션입니다.

---

명령 행에서 두 개의 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에서 이미 설치 한 앱이 있습니다.

---

Xcode 9 이상

Xcode 9는 이제 여러 시뮬레이터 실행을 지원합니다. 이것은 WWDC 2017에서 발표되었습니다.

Xcode, Cmd + R 에서 시뮬레이터를 변경하면 새로운 시뮬레이터가 나타납니다.

---

i40west의 솔루션이 시뮬레이터를 수동으로 시작하는 데 효과가 있는지 성공적으로 테스트했지만 요즘에는 iOS 시뮬레이터에 명령 줄에서 동시 테스트를 실행할 때 다른 Xcode 버전과 다른 장치 유형이 필요합니다 (약간 다른 사용 사례이지만 맨 처음 질문과 관련이 있음) ).

https://developer.apple.com/library/ios/technotes/tn2339/_index.html 명령 줄 빌드 및 테스트와 가장 관련이있는 Apple 기사를 여기에서 참조하십시오.

'xcrun'의 출력에서 ​​UUID 값으로 올바른 '대상'값 일치 시뮬레이터 실행으로 'xcodebuild test'명령을 실행하기 전에 올바른 --args-를 'iOS simulator.app'에 전달하면 여러 동시 테스트가 제대로 작동했습니다. simctl list '및 DEVELOPER_DIR 환경 변수를 설정하여 다른 XCode 버전 바이너리 (예 : Xcode 6.1 및 6.4의 기본 경로)를 선택

동일한 물리적 시스템과 iPad 또는 iPhone과 같은 동일한 iOS 시뮬레이터 장치 및 동일한 Xcode 버전에서 동시 단위 테스트가 필요한 이유는 기본적으로 동일한 빌드 시스템이 여러 빌드의 여러 빌드를 실행할 수있는 모든 iOS 프로젝트의 CI (연속 통합)를 지원하기위한 것입니다. 기능 분기를 체크인 할 때 한 번에 앱 (우리 회사에 30 개 정도의 앱이 있음)이 실행중인 다른 빌드가 완료 될 때까지 기다릴 필요없이 Bamboo 에이전트가 기능 분기를 자동으로 스캔하고 빌드합니다. 사용 가능한 경우 기능 분기를 발견했습니다.

여러 개의 동시 테스트를 실행할 때 발생하는 상황에 대해 서로 다른 Terminal.app 창에서 여러 개의 'xcodebuild test'명령을 연속으로 두 번 실행하면 결과는 하나의 시뮬레이터 창이 나타나고 가장 간단한 테스트에서는 테스트가 실패합니다.

When we complicate the entry criteria for our test launch, different Xcode versions for each sim and test launch, when using DEVELOPER_DIR as per man pages (xcodebuild test) we are specifying a different device which open in two separate windows, but the result is that any running tests in first window are interrupted by second iOS simulator window.

There seems to be a common shared resource under the hood that is getting in the way, not sure it is intended or just a new feature that requires more than a few days of serious thought in how to better implement concurrent test runs wihout adverse impacts.

We don't want to use VMs to work around the sim restrictions as our experience and of others in general is that iOS build performance on VMs with large number of small files is slower than physical hardware. VMs generally will slow the build down by a lot due to I/O issues in the combination of VMware software and Apple hardware and/or firmware. Sorry virtuallyghetto but for us VMs don't perform well -- the virtuallyghetto site has provided us instructions on how to install ESXi 5.5 on Mac Mini's for our build farm.

We have experienced the build performance issue with ESXi 5.5 on Mac Mini being slower than bare metal even with SSD by a factor of 2 or more (i.e. a 10 minute baremetal build takes 20 on VM). Refer to squareup article below on why.

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

The restriction of 1 sim device at a time for xcodebuild unit tests severely reduces productivity and exponentially adds significant costs to Apple and the ecosystem.

The cost to Apple of not supporting concurrency to justify more hardware purchases should be thought of carefully, weighing risks of losing developer velocity against other competitors who have less restrictions in terms of sims and EULA.

The advantage of concurrent tests in same user login (how most ci systems work) is that quality of Apple branded app store apps which in turn is in part what makes people buy the iOS devices in the first place. Poor software quality makes the whole brand a bit more slugish and concurrency support in iOS simulators definitely seems like the smart way to go to support the ecosystem. A bit of a corollary to the issue at hand are recent improvements such as Apple's Xcode server for CI, Xcode's automated UI tests functionality in Xcode 7.

Encouraging needless overheads to make people buy mass quantities of hardware, setup, configuration, not to mention numerous people required to support all the machines, network and power points, etc, will potentially harm Apple's profits in the end as not everyone is like Apple and able to afford racks of MacPro's or Mac Mini's just to support concurrent tests on simulators. The whole point of a simulator is to avoid using the hardware and also speeding up the tests.

Plus the EULA limitations on VMs makes the case for VMs on Mac Pro's quite weak. This hardware type would be attractive if multiple sims could run but since concurrent unit tests isn't supported (except in above two conditions - different XCode version and different simulator device) we will likely stick with Mac Mini's for build infrastructure.

These sim and EULA limitations from Apple not only make the build pipeline slower but also add unnecessary complexity and cost. It may not be so concerning for small apps but as the apps grow in size and complexity, the build can take upwards of an hour (I heard that Facebook iOS builds can take that long). Nobody wants to wait an hour to know if a build passed.

We know of hack solutions like running ESXI VMs on Mac Minis which don't play well performance wise with OS X and xcodebuild on large projects with builds that take more than 10 minutes on a modern Mac Book Pro or Mac Mini, or different login accounts on bare metal machine to the environment just to be able to run concurrent tests on same Xcode version and same simulator device.

ESXi is not officially supported although it works pretty well. One of the reasons VMware might not support Mac Mini hardware yet is lack of ECC memory, although Mac Pro is supported as it does have ECC memory, it likely has same issues as the Mac Mini's in terms of iOS builds slow down compared to bare metal tests on same hardware and software config (only change is VM versus bare metal running OS X). MacPro has not been tested by us at this time. In our experience VMware Fusion is quite slow in terms of performance as well.

More importantly developers will need to wait longer when aforementioned issues are compounded together unless the pool of machines is large enough to support pipleline of changes (one CI build for every 2 devs, very high ratio of machines to developer). CI build machines should be able to run more concurrent Builds and more concurrent tests than 1.

One of the other observations about the iOS simulators is that they seem to be a work in progress and completely unfinished even after 7 major versions. The 'xcrun simctl' subcommand has a --set option which may allow some flexibility of some kind but not sure of what possible value is valid, and same with --noxpc. Nobody should need to guess appropriate values and furthermore, there should be a man page that covers this option and and perhaps example. What are some use cases for these 2 interesting options?

You may say, well no app should be designed to have a large footprint that warrants concurrent test to run, and making use of better architecture based on XPC, as monolithic apps are the issue. This may very well be correct, it is not as pragmatic solution as we could hope for, and the issue remains if you have 20+ apps to build on same infrastructure.

Making a machine configuration and processes as generic and scalable as possible for higher throughput will require some work on the simulator (app + core devs). It also requires a high level of collaboration between all Apple simulator developers and the simulator product owner(s) needs to order the product backlog correctly for this issue to get any attention :-)

---

FBSimulatorControl from Facebook provides a programmatic way to do this. It's available at https://github.com/facebook/FBSimulatorControl.

The method testLaunchesMultipleSimulatorsConcurrently in FBSimulatorControlSimulatorLaunchTests.m has sample code illustrating how to launch multiple simulators.

---

You can run multiple instances of simulator for different hardware profiles and debug them. First, you need to run your app from XCode for each hardware type (iPhone 6, iPad etc.) to install it into simulator instances. Then run simulator instances and your app as it is explained above. To debug it, you can attach debugger to running processes from "XCode->Debug->Attach to Process" menu. You can check this blog entry for an example :http://oguzdemir.dualware.com/?p=43

---

여기에 .sh의 작은 스크립트가 컴퓨터에 시뮬레이터의 UDID를 나열하고 실행합니다. 확장자가 ".sh"인 파일에 아래 코드를 복사하여 터미널에서 실행하십시오.

어떻게:

1 단계. 옵션 1로 장치를 나열하고 원하는 UDID를 복사합니다.

단계 2. 옵션 2를 실행하고 UDID를 붙여 넣은 후 Enter 키를 누르십시오.

주의 : 시뮬레이터가 포함 된 경로가 올바른지 확인하십시오 (경로로 대체되지 않은 경우)

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

감사합니다,

참고 URL : https://stackoverflow.com/questions/26446346/xcode6-run-two-instances-of-the-simulator