IOSアプリには2つの異なるターゲットがあります。シミュレーターの2つの異なるインスタンスで2つのアプリを同時に実行することは可能ですか? Xcodeのデバッガーの恩恵を受けないことが必要な場合は問題ありません。これまでに私が見つけた唯一の解決策は、XCodeの2つのバージョンをインストールすることでしたが、それは非常に重い/スペースを消費する解決策です。
コマンドラインからiOSシミュレーターの2つのインスタンスを実行できます。 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
2番目のものが起動すると、エラーアラートが表示されます。それを閉じて、別のデバイスを選択「ハードウェア」"「デバイス」から。これで2つのシミュレーターが実行され、Xcodeから既にインストールしたアプリがそこにあります。
I40westのソリューションがシミュレーターを手動で起動することを正常にテストしましたが、今日では、iOSシミュレーターはコマンドラインから同時テストを実行するときに異なるXcodeバージョンと異なるデバイスタイプを必要とするように見えます)。
コマンドラインのビルドとテストに最も関連するAppleの記事を参照してください。 https://developer.Apple.com/library/ios/technotes/tn2339/_index.html =
正しい--args-を 'iOS simulator.app'に渡してから、 'xcrunの出力からのUUIDの値でシミュレーターの起動に一致する正しい' -destination '値で' xcodebuild test 'コマンドを実行すると、複数の同時テストがうまく機能しましたsimctl list」、および環境変数DEVELOPER_DIRを設定して、異なるXCodeバージョンのバイナリ(Xcode 6.1および6.4へのベースパス)を選択する
同じ物理マシンおよびiPadやiPhoneなどの同じiOSシミュレータデバイスと同じXcodeバージョンで同時ユニットテストが必要な理由は、主に同じビルドシステムが複数のビルドを複数実行できるiOSプロジェクトのCI(継続的統合)をサポートするためです機能ブランチでのチェックイン時に一度にアプリ(当社には30個ほどのアプリがあります)は、他の実行中のビルドが完了するのを待つことなく、Bambooエージェントによって自動的にスキャンおよびビルドされます-Bambooは、このタイプの自動ビルドをサポートします-有効になっている場合、検出された機能ブランチ。
複数の同時テストを実行すると何が起こるかについて、異なるTerminal.appウィンドウで複数の「xcodebuild test」コマンドを連続して2回実行すると、1つのシミュレータウィンドウのみが表示され、最も単純なテストではテストが失敗します。
テストの開始、各シミュレーションの異なるXcodeバージョン、およびテストの開始の入力基準を複雑にする場合、manページ(xcodebuildテスト)に従ってDEVELOPER_DIRを使用する場合、2つの別々のウィンドウで開く異なるデバイスを指定しますが、結果は最初のウィンドウで実行中のテストは、2番目のiOSシミュレータウィンドウによって中断されます。
邪魔になるフードの下に共通の共有リソースがあるように見えますが、それが意図されているのかわからないか、悪影響なしに同時テスト実行をより適切に実装する方法に数日以上の真剣な検討を必要とする単なる新機能です。
私たちの経験やその他の一般的な経験により、多数の小さなファイルを含むVMでのiOSビルドのパフォーマンスは物理ハードウェアよりも遅いため、シムの制限を回避するためにVMを使用したくありません。通常、VMは、VMwareソフトウェアとAppleハードウェアおよび/またはファームウェアの組み合わせにおけるI/Oの問題により、ビルドを大幅に遅くします。仮想ゲットーは申し訳ありませんが、仮想マシンのパフォーマンスは良くありません。仮想ゲットーのサイトでは、ビルドファーム用の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デバイスを制限すると、生産性が大幅に低下し、Appleおよびエコシステムに大幅なコストが指数関数的に追加されます。
ハードウェアの追加購入を正当化するために同時実行をサポートしないAppleのコストは慎重に検討する必要があり、シムとEULAに関して制限の少ない他の競合他社に対して開発者の速度を失うリスクを考慮します。
同じユーザーログインでの同時テストの利点(ほとんどのciシステムの動作方法)は、Appleブランドのアプリストアアプリの品質であり、これが最初に人々がiOSデバイスを購入する原因にもなります。ソフトウェアの品質が悪いため、iOSシミュレーターでのブランド全体の品質がやや低下し、並行性のサポートが確実にエコシステムをサポートする賢明な方法のように思われます。目の前の問題に少し起因するのは、CI用のAppleのXcodeサーバー、Xcode 7のXcodeの自動UIテスト機能などの最近の改善です。
すべてのマシン、ネットワーク、および電源ポイントなどをサポートするために必要な多数の人々は言うまでもなく、大量のハードウェア、セットアップ、構成を購入するために不必要なオーバーヘッドを奨励することは、最終的にAppleの利益を損なう可能性がありますAppleおよびシミュレータでの同時テストをサポートするためだけにMacProまたはMac Miniのラックを購入する余裕があります。シミュレータの重要なポイントは、ハードウェアの使用を避け、テストの速度を上げることです。
さらに、VMに関するEULAの制限により、Mac Pro上のVMの場合は非常に脆弱です。複数のシムを実行できる場合、このハードウェアタイプは魅力的ですが、同時ユニットテストはサポートされていないため(上記の2つの条件-異なるXCodeバージョンと異なるシミュレーターデバイスを除く)、ビルドインフラストラクチャについてはMac Miniに固執する可能性があります。
AppleによるこれらのsimおよびEULAの制限により、ビルドパイプラインが遅くなるだけでなく、不必要な複雑さとコストが追加されます。小さなアプリの場合はそれほど気にならないかもしれませんが、アプリのサイズと複雑さが大きくなると、ビルドに1時間以上かかることがあります(Facebook iOSのビルドには時間がかかると聞きました)。ビルドが成功したかどうかを知るために1時間待つことを望む人はいません。
最新のMac Book ProまたはMac Miniで10分以上かかるビルドや、異なるログインアカウントでの大規模プロジェクトでOS XやxcodebuildのパフォーマンスがあまりよくないMac MiniでESXI VMを実行するなどのハッキングソリューションを知っています。同じXcodeバージョンと同じシミュレータデバイスで同時テストを実行できるようにするために、ベアメタルマシンで環境に接続します。
ESXiは公式にはサポートされていませんが、かなりうまく機能しています。 VMwareがMac Miniハードウェアをまだサポートしていない理由の1つは、ECCメモリがないことです。ECCメモリがあるため、Mac Proはサポートされていますが、ベアメタルに比べてiOSビルドに関してMac Miniと同じ問題がある可能性があります同じハードウェアとソフトウェアの構成でテストします(OS Xを実行するベアメタルとVMの違いのみ)。 MacProは、現時点ではテストされていません。私たちの経験では、VMware Fusionはパフォーマンスの点でも非常に遅いです。
さらに重要なことは、マシンのプールが変更のパイプラインをサポートするのに十分な大きさでない限り、前述の問題が複雑になると、開発者はより長く待つ必要があります(開発者2人ごとに1つのCIビルド、開発者に対するマシンの非常に高い比率)。 CIビルドマシンは、1つよりも多くの同時ビルドとより多くの同時テストを実行できる必要があります。
IOSシミュレーターに関する他の観察の1つは、それらが進行中の作業であり、7つのメジャーバージョンの後でも完全に未完成のように見えることです。 「xcrun simctl」サブコマンドには--setオプションがあります。これにより、何らかの柔軟性が得られますが、有効な値が何であるかは不明であり、-noxpcと同じです。適切な値を推測する必要はありません。さらに、このオプションとおそらく例について説明するマニュアルページが必要です。これらの2つの興味深いオプションの使用例は何ですか?
モノリシックアプリが問題であるため、並行テストを実行し、XPCに基づくより優れたアーキテクチャを使用することを保証する大きなフットプリントを持つようにアプリを設計する必要はありません。これは非常に正しいかもしれませんが、私たちが期待できるほど実用的な解決策ではありません。また、同じインフラストラクチャ上に20以上のアプリを構築する場合、問題は残ります。
マシン構成とプロセスを可能な限り汎用的でスケーラブルにしてスループットを高めるには、シミュレーター(アプリ+コア開発者)でいくつかの作業が必要になります。また、すべてのAppleシミュレーター開発者とシミュレーター製品所有者との間の高度なコラボレーションが必要であり、この問題が注意を引くために製品バックログを正しく注文する必要があります:-)
FacebookのFBSimulatorControlは、これを行うためのプログラム的な方法を提供します。 https://github.com/facebook/FBSimulatorControl で入手できます。
FBSimulatorControlSimulatorLaunchTests.m のtestLaunchesMultipleSimulatorsConcurrently
メソッドには、複数のシミュレーターを起動する方法を示すサンプルコードがあります。
異なるハードウェアプロファイルに対してシミュレータの複数のインスタンスを実行し、それらをデバッグできます。まず、各ハードウェアタイプ(iPhone 6、iPadなど)のXCodeからアプリを実行して、シミュレータインスタンスにインストールする必要があります。次に、上記で説明したように、シミュレーターインスタンスとアプリを実行します。デバッグするには、「XCode-> Debug-> Attach to Process」メニューから実行中のプロセスにデバッガーを接続できます。例については、このブログエントリを確認してください: http://oguzdemir.dualware.com/?p=4
ここで、コンピューター上のシミュレーターのUDIDをリストして実行するための.shの小さなスクリプト。以下のコードを拡張子「.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
ありがとうございました、