Apple Watch。から始めました。「 Five Minute Watchkit 」、iOSアプリとWatch Kitアプリの両方をシミュレーターで実行し、両方のプロセスをLLDBデバッガーに接続します。
私がしているのは、iOSアプリを起動して終了し、現在のバージョンをsimにインストールすることです。次に、watchKitスキームに切り替えて起動し、ウォッチシミュレーターにウォッチアプリのUIを表示します。
次に、シミュレータで対応するiOSアプリを起動し、ユーザーがXcodeメニューで「プロセスにアタッチ」して、実行中のiOSアプリにデバッガをアタッチします。
これは動作します。ウォッチキットのInterfaceControllerまたはiOSアプリのいずれかにブレークポイントを設定でき、デバッガーが必要なときにブレークします。
ただし、iOSアプリのデバッグコンソールにNSLog()ステートメントが表示されません。 (WatchKit拡張コードからログステートメントが表示されます。)iOSアプリにブレークポイントを設定すると、必要なときにそのブレークポイントで停止します。 NSLogからのコンソール出力の欠如は、Xcodeから起動するのではなく、simで実行中のプロセスにアタッチすることに関係があると思いますが、それが何かはわかりません。
(ところで、ブレークポイントからNSLogを呼び出すアクションをブレークポイントにアタッチしても表示されませんが、「ログメッセージ」デバッガーコマンドは表示されます。洞察はありますか?)
編集:iOSアプリのコードは重要ではないようです。私の場合、iOSアプリのストーリーボードのボタンに添付されたのは、汚れたシンプルなIBActionでした。
- (IBAction)buttonAction:(UIButton *)sender;
{
NSLog(@"Button clicked on iPhone");
}
NSLogステートメントにブレークポイントを設定できます。デバッガーはその行で停止しますが、デバッグコンソールにログステートメントが表示されません。
WatchKitを使わない簡単なテストアプリで再現できます。このアプリは、1秒ごとに「タイマー起動」を出力するNSTimerで構成されています。 (このコードは100%正しいです;)。プロセスに手動でアタッチした後、ログに何も表示されません。
NSLogがstderrに出力することを知っている限り、デバッガをアタッチしてもstderrはXcode端末にリダイレクトされません。
コンソールアプリまたは端末を使用してログを確認しても問題ない場合は、それを実行できます。 iOS8は、シミュレータログを~/Library/Logs/CoreSimulator/<Device-UUID>
に保存します。このディレクトリには、すべてのNSLog
出力を含むsystem.logがあります。
ターミナル(cat
、grep
、tail
)で確認するか、Console.appで開きます。
Appleは(少なくともGDBの場合) Technical Note TN2239:iOS Debugging Magic で確認しています。
コンソール出力
多くのプログラム、そして実際多くのシステムフレームワークは、デバッグメッセージをstderrに出力します。この出力の宛先は最終的にプログラムによって制御されます。選択した任意の宛先にstderrをリダイレクトできます。ただし、ほとんどの場合、プログラムはstderrをリダイレクトしないため、出力はプログラムによって起動環境から継承されたデフォルトの宛先に送られます。これは通常、次のいずれかです。
- 通常のユーザーが起動するGUIアプリケーションを起動すると、システムはstderrに出力されたメッセージをシステムログにリダイレクトします。前述の手法を使用して、これらのメッセージを表示できます。
- Xcode内からプログラムを実行すると、Xcodeのデバッガーコンソールウィンドウにstderr出力が表示されます(このウィンドウを表示するには、[実行]メニューから[コンソール]メニュー項目を選択します)。
実行中のプログラムへのアタッチ(Xcodeの[プロセスへのアタッチ]メニュー、またはGDBのアタッチコマンドを使用)は、プログラムのstderrをGDBウィンドウに自動的に接続しません。これは、テクニカルノートTN2030の「GDB for MacsBug Veterans」の「接続後のstdoutとstderrの表示」セクションで説明されているトリックを使用して、GDB内から実行できます。
前述のTN2030は、サーバー上で使用できなくなりました( mirror )。 stdoutとstderrをXcodeコンソールにリダイレクトする方法を示しました。ただし、Shell tty
はLLDBの有効なコマンドではないため、あまり役に立ちません。しかし、おそらくtty Xcodesコンソールが使用する別の方法にアクセスできるため、そのTNの重要な部分を添付します。
接続後にstdoutとstderrを見る
(GDB内からプロセスを開始するのではなく)GDBをプロセスにアタッチすると、プロセスがstdoutまたはstderrに出力するものを表示できなくなります。 Finderによって起動されたプログラムは通常、 "/ dev/console"に接続されたstdoutとstderrを持っているため、印刷した情報はコンソールに送られます。これを表示するには、(ユーティリティフォルダー内の)コンソールアプリケーションを起動しますが、別のウィンドウを見る必要があるのは不便です。別の方法は、プロセスのstdoutまたはstderrをGDBのターミナルウィンドウのターミナルデバイスに接続することです。リスト9はこれを行う方法を示しています。
リスト9. stdoutとstderrをGDBの端末デバイスに接続する。
(gdb) attach 795 [... output omitted ...] (gdb) call (void) DebugPrintMenuList() No output )-: Close the stdout and stderr file descriptors. (gdb) call (void) close(1) (gdb) call (void) close(2) Determine the name of the terminal device for GDB itself. (gdb) Shell tty /dev/ttyp1 Reopen stdout and stderr, but connected to GDB's terminal. The function results should be 1 and 2; if not, something is horribly wrong. (gdb) call (int) open("/dev/ttyp1", 2, 0) $1 = 1 (gdb) call (int) open("/dev/ttyp1", 2, 0) $2 = 2 Try the DebugPrintMenuList again. (gdb) call (void) DebugPrintMenuList() Yay output! Index MenuRef ID Title ----- ---------- ---- ----- <regular menus> 00001 0x767725D3 -21629 Ed 00002 0x76772627 1128 <Apple> 00003 0x767726CF 1129 File 00004 0x76772567 1130 Edit [... remaining output omitted ...]
Xcodeバージョン7.2およびiOS 9.2などで、次の作品が見つかりました。
0)電話アプリとウォッチアプリの両方を強制終了します
1)ウォッチ拡張ターゲットを選択して、ヒット Cmd+R (ビルドして実行)
2)電話ターゲットを選択して、ヒット Ctrl+Cmd+R (ビルドせずに実行)
私の場合、両方のアプリをシミュレーターで起動し、両方のNSLog出力を取得します。個別に添付する必要はありません。お役に立てれば。
https://developer.Apple.com/library/ios/qa/qa1747/_index.html
1)デバイスを接続し、Xcodeを開きます
2)メニューバーからウィンドウ->デバイスを選択します
3)左の列の[デバイス]セクションで、デバイスを選択します
4)デバイスコンソールを表示するには、右側のパネルの左下にある上向き三角形をクリックします
5)右下の下矢印をクリックして、コンソールをファイルとして保存します
プロビジョニングプロファイルがAdHocまたはDistributionに設定され、Xcodeがログを表示しない場合、ログを表示するには開発を設定する必要があります