小开

最佳答案

您可以从命令行运行两个 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 运行每种硬件类型(iPhone6，iPad 等)的应用程序，将其安装到模拟器实例中。然后运行模拟器实例和你的应用程序，如上所述。要调试它，您可以从“ XCode-> Debug-> Attach To Process”菜单中将调试器附加到正在运行的进程。您可以查看这个博客条目以获得示例译自: 美国《 http://oguzdemir.dualware.com/?p=43》杂志网站(http://oguzdemir.dualware.com/p = 43)

小开

成功测试了 i40west 的解决方案可以手动启动模拟器，但在当今时代，iOS 模拟器在命令行运行并发测试时需要不同的 Xcode 版本和不同的设备类型(用例略有不同，但与最初的问题相关) ，这似乎有些愚蠢。

请参考这篇与命令行构建和测试最相关的 Apple 文章: Https://developer.apple.com/library/ios/technotes/tn2339/_index.html

如果在运行“ xcodebuild test”命令和“ xcrun simctl list”的输出中匹配模拟器启动和 UUID 值的“ xcodebuild test”命令之前，向“ iOS Simulator.app”传递正确的 args，并设置 developER _ dir 环境变量以选择不同的 XCode 版本二进制文件(即 XCode 6.1和6.4的基本路径) ，那么多个并发测试对我们来说是可行的

Reason for needing concurrent unit tests on same physical machine and same iOS simulator device such as iPad or iPhone and same Xcode version is primarily to support CI (continuous integration) of any iOS project whereby the same build system can run more than 1 build of multiple apps (our company has 30 apps or so) at a time upon check-in on feature branches are automatically scanned and built by Bamboo agent without needing to wait for other running Builds to complete -- Bamboo supports this type of auto build on auto-discovered feature branches if enabled.

至于运行多个并发测试时会发生什么，我们在不同的 Terminal. app 窗口中连续两次运行多个“ xcodebuild test”命令，结果只出现一个模拟器窗口，并且测试在最简单的测试中失败。

当我们复杂化我们的测试启动的入口标准，每个 sim 和测试启动的不同 Xcode 版本，当使用 DevelopER _ DIR 作为每个手册页(xcodebuild 测试) ，我们指定一个不同的设备，打开在两个不同的窗口，但结果是任何在第一个窗口运行的测试被第二个 iOS 模拟器窗口中断。

似乎有一个共同的共享资源正在阻碍它的发展，不确定它的目的是什么，或者仅仅是一个新的特性，需要花费几天的时间来认真思考如何更好地实现并发测试运行而不产生负面影响。

我们不希望使用虚拟机来绕过 sim 的限制，因为我们的经验和其他人的经验是，iOS 在大量小文件的虚拟机上构建性能比物理硬件慢。由于 VMware 软件、 Apple 硬件和/或固件的组合中的 I/O 问题，VM 通常会大大降低构建速度。对不起，虚拟贫民区，但对于我们虚拟机不能很好地执行-虚拟贫民区网站已经为我们提供了如何在 Mac Mini 上为我们的构建农场安装 ESXI 5.5的指导。

我们已经经历了 Mac Mini 上 ESxi 5.5的构建性能问题，即使使用 SSD，速度也比裸金属慢2倍或更多(即在 VM 上10分钟的裸金属构建需要20分钟)。请参考下面关于原因的文章。

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

在 xcodebuild 单元测试中，一次只能使用1个 sim 设备的限制严重降低了生产力，并且给苹果公司和整个生态系统带来了巨大的成本。

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.

在同一用户登录(大多数 ci 系统是如何工作的)中并发测试的优势在于苹果品牌应用商店应用的质量，这反过来也是人们购买 iOS 设备的首要原因。糟糕的软件质量使得整个品牌更加迟钝，iOS 模拟器中的并发支持看起来绝对是支持生态系统的明智之举。这个问题的一个必然结果是最近的一些改进，比如苹果的 Xcode server for CI，Xcode 在 Xcode 7中的自动 UI 测试功能。

鼓励人们购买大量的硬件、设置、配置，更不用说支持所有机器、网络和电源等所需的大量人员，这些不必要的开销最终可能会损害苹果的利润，因为不是每个人都像苹果一样，能够买得起一架架的 MacPro 或 Mac Mini，只是为了支持模拟器上的同步测试。模拟器的关键在于避免使用硬件并加快测试速度。

此外，虚拟机的 EULA 限制使得 Mac Pro 上的虚拟机相当薄弱。如果可以运行多个模拟器，这种硬件类型将非常有吸引力，但是由于不支持并发单元测试(除了上述两种情况——不同的 XCode 版本和不同的模拟器设备) ，我们可能会坚持使用 Mac Mini 来构建基础设施。

这些来自苹果的 sim 和 EULA 限制不仅使构建流水线变慢，而且增加了不必要的复杂性和成本。对于小型应用程序来说，这可能并不那么令人担忧，但是随着应用程序的规模和复杂性的增长，构建可能需要一个多小时(我听说构建 Facebook 的 iOS 可能需要那么长的时间)。没人想等一个小时才知道构建是否通过。

我们知道一些黑客解决方案，比如在 Mac Mini 上运行 ESXI 虚拟机，它们在 OS X 和 xcodebuild 大型项目上的性能表现不佳，在现代 Mac Book Pro 或 Mac Mini 上的构建时间超过10分钟，或者仅仅为了能够在相同的 Xcode 版本和相同的模拟器设备上运行并发测试而在裸机上使用不同的登录帐户。

虽然 ESxi 工作得非常好，但它并没有得到官方的支持。VMware 可能还不支持 Mac Mini 硬件的原因之一是缺少 ECC 内存，尽管 Mac Pro 支持 ECC 内存，但它可能和 Mac Mini 一样，在相同硬件和软件配置的裸金属测试中，iOS 的构建速度变慢了(唯一的变化是虚拟机和运行 OS X 的裸金属测试)。MacPro 目前还没有经过我们的测试。根据我们的经验，VMware Fusion 在性能方面也相当慢。

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.

关于 iOS 模拟器的另一个观察是，它们似乎是一个正在进行的工作，即使在7个主要版本之后仍然完全未完成。‘ xcrun simctl’子命令有一个—— set 选项，它可能允许某种灵活性，但不确定可能的值是否有效，与—— noxpc 相同。没有人应该需要猜测适当的值，此外，应该有一个手册页，涵盖这个选项，也许还有示例。这两个有趣的选项有哪些用例？

你可能会说，没有一个应用程序应该被设计成需要大量的并发测试来运行，并且使用更好的基于 XPC 的架构，因为单一的应用程序是问题所在。这很可能是正确的，它不是我们所希望的那样务实的解决方案，如果你有20多个应用程序要构建在相同的基础设施上，问题仍然存在。

为了提高吞吐量，使机器配置和流程尽可能通用和可伸缩，将需要在模拟器(app + core devs)上进行一些工作。它还需要所有苹果模拟器开发人员和模拟器产品所有者之间的高水平协作，以便正确订购产品待办事项列表，从而引起注意: -)

小开

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

FBSimulatorControlSimulatorLaunchTests.m中的 testLaunchesMultipleSimulatorsConcurrently方法有示例代码，说明如何启动多个模拟器。

小开

这里有个小剧本。列出计算机上模拟器的 UDID 并运行它。将下面的代码复制到扩展名为“的文件中。然后在终端运行它。

如何:

步骤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

谢谢,

小开

Xcode 9+

Xcode 9现在支持启动多个模拟器。

只要去改变模拟器在 Xcode，abc 0和你会看到一个新的模拟器弹出。

小开

现在是2020年，xCode 11.4: File-> Open Device-> iOs 13.4-> ，选择第一个没有运行的 iPhone 版本，你将运行第二个模拟器。

Xcode6: 运行模拟器的两个实例

Xcode 9+