症状： 複数の端末条件を一度に確認したいのに、Macのメモリやビルド時間への影響が読めません。
最短の解決策： Xcodeで必要なシミュレーターだけを起動し、メモリ使用量、ビルド時間、テスト時間を同じ条件で記録してから並行数を決めます。
異なるiOS端末やシステム環境で動作を確かめたい開発者は、シミュレーターの組み合わせ方と測定手順を確認できます。
ビルドとテストを並行するチームは、メモリ不足や処理待ちを切り分ける際に役立ててください。
手元のMacと遠隔のMac環境を比較したい場合も、確認すべき指標が分かります。
Macで複数のiOSシミュレーターを動かすと、何を測るべきですか？
XcodeとSimulatorを使えば、複数のiOSシミュレーターを起動し、複数デバイステストに利用できます。ただし、シミュレーターを増やすとメモリやプロセッサーへの負荷も増えるため、台数を増やせばビルドが速くなるとは限りません。Appleのシミュレーター実行手順でも、シミュレーターと実機は実行先として区別されています。
ここでいう「実測」は、特定のMac、macOS、Xcode、プロジェクトを使って記録した値を指します。本記事では確認可能な本サイトの計測記録がないため、実際のメモリ量やビルド時間は掲載しません。環境が分からない状態で性能数値を当てはめる代わりに、同じ条件で再確認できる測定方法を示します。
測定では、次の値を別々に記録します。
- メモリの状態： アクティビティモニタのメモリプレッシャーとスワップ使用量。Appleのメモリ監視ガイドで表示項目を確認できます。
- ビルド時間： 初回ビルドと増分ビルドを分け、ビルドログの所要時間を記録します。増分ビルドの計測方法はAppleのビルド速度改善資料を参照してください。
- テスト時間と結果： シミュレーターごとの実行時間、失敗、再実行の有無を記録します。テストの実行と結果の確認方法も確認してください。
起動しただけの状態と、アプリを操作してテストを実行している状態は負荷が異なります。起動完了後の値だけで判断せず、テスト中のピークも記録してください。
Xcodeで複数のシミュレーターを準備する手順
テスト対象は、実際に確認したい画面サイズやOS条件から選びます。端末の種類を増やすこと自体を目的にせず、対象ユーザーや過去の不具合に関係する組み合わせを優先してください。
- 対象条件を決める： 画面レイアウト、OSごとの挙動、回帰確認など、今回のテスト目的を書き出します。
- 実行先を選ぶ： Xcodeの実行先から必要なシミュレーターを選択します。追加のシミュレーター用コンポーネントが必要な場合は、Xcodeコンポーネントの追加手順を確認します。
- 複数の実行環境を起動する： Simulatorから対象を起動し、端末モデルとランタイムを記録します。Xcodeの画面操作に加えてコマンドラインから実行する場合は、Xcodeコマンドラインツールの資料を参照してください。
- 基準値を記録する： シミュレーターを起動する前に、メモリプレッシャー、スワップ、CPU負荷を記録します。バックグラウンドのビルドや同期処理も、実施の有無を控えます。
- 一台ずつ追加する： 起動のたびに同じ項目を記録し、すべて起動した状態でも測ります。続けてテストを実行し、テスト中の負荷を別に記録します。
- 条件をそろえて再実行する： 同じプロジェクト、ビルド設定、コード状態、起動方法で測定を繰り返します。結果が大きく変わる場合は、ほかの処理やキャッシュ状態も確認します。
複数デバイステストでビルド効率が変わる理由
ビルドとテストは別の処理として評価します。ビルド時間を比べるときは、シミュレーターを複数起動しただけの条件と、テストを同時に走らせた条件を混同しないでください。テスト側の処理がCPUやメモリを使えば、ビルドが待たされることがありますが、影響の大きさはMacとプロジェクトによって異なります。
初回ビルドは、増分ビルドと分けて記録します。コードやビルド設定が異なる状態の結果を比べると、シミュレーターの台数ではなく変更内容が所要時間に影響した可能性があります。Xcodeのビルドログとタイミング情報を確認し、処理時間が伸びた箇所を追ってください。
| 比較する状態 | 確認する内容 | 判断に使うポイント |
|---|---|---|
| 起動前 | メモリプレッシャー、スワップ、実行中の作業 | Macの基準状態を把握できるか |
| シミュレーター起動後 | 起動のたびのメモリ状態、CPU負荷 | 追加した実行環境に伴う変化があるか |
| テスト実行中 | メモリ状態、テスト時間、失敗や再実行 | 並行テストが安定して完了するか |
| ビルド中 | 初回・増分それぞれの所要時間、ビルドログ | テスト負荷とビルドの遅れを区別できるか |
測定の間は、コード、ビルド設定、テスト内容、並行して動かす作業をそろえます。コマンドラインでビルドする場合も、実行方法やログの取り方を記録し、異なる条件の結果をひとまとめにしないことが重要です。
結果から同時起動する構成を選ぶ
次の条件で、並行実行を続けるか、テストを分けるか決めます。
- メモリプレッシャーやスワップがテスト中に悪化し、操作やビルドが不安定になるなら、まずシミュレーターを減らします。
- ビルド時間が伸びた場合は、テストを実行していない条件でも再測定し、ビルドそのものと同時実行の影響を切り分けます。
- 必須の端末条件を残したまま不安定さが解消しないなら、端末の組み合わせを分割して順番に実行します。
- 実行時間より幅広い同時確認を優先する場合は、ピーク時の負荷と失敗率を許容できるか確認してから並行数を決めます。
| 選択肢 | 向いている状況 | 注意点 |
|---|---|---|
| 必要なシミュレーターだけ同時起動 | 複数の端末条件を一度に回帰確認したい | テスト中のメモリとビルド時間を確認する |
| シミュレーターを分けて順次実行 | 負荷が高い、または結果が不安定 | 全体の完了時間と実行順を記録する |
| 手元のMacで実行 | 実機に近い作業感で日常的に開発する | ビルドや別作業と資源を共有する |
| 遠隔のMac環境を検討 | 手元の作業とテスト環境を分けたい | 接続方法、環境の再現性、データの受け渡しも比較する |
手元のMacが安定して必須条件を満たし、ほかの作業と競合しないなら、同じ環境で続けるのが合理的です。一方、ローカルのビルドや日常作業とテスト負荷がぶつかる場合は、テストを分割するか、別のMac環境を候補に加えて同じ測定項目で比較してください。遠隔環境は接続やファイル受け渡しが加わるため、常時高負荷の作業や物理接続が必要な検証に必ず適するわけではありません。
既存の構成で負荷が高い場合、遠隔環境なら自動的にビルドが速くなるとは言えません。それでも、手元の作業との資源競合を避けたい一時的なテスト環境としては、Macをレンタルして同じ手順で確かめる方法があります。利用条件を確認する際は、Macレンタルの利用方法を参照し、必要な実行先や作業方法に合うか判断してください。国内で使う環境を検討する場合は、日本向けMacレンタルの案内も確認し、掲載されている構成と自身の測定条件を照らし合わせてください。