WWDC Quick Look 💓 By SwiftGGTeam
Discover breakpoint improvements

Discover breakpoint improvements

元の動画を見る

ハイライト

Xcode 13 では、列ブレークポイント、未解決のブレークポイント プロンプト、実行時問題ブレークポイントがブレークポイントに追加され、開発者が特定の式、シンボル解析の失敗ポイント、および実行時問題でプログラムを一時停止できるようになります。

主要内容

デバッグ時に開発者が本当に望んでいることは、エラーが発生する前にプログラムを停止することです。停止後、プロセスのステータスを確認し、ロジックを段階的に検証できます。

以前は、行ブレークポイントが最も一般的に使用されていました。特定の行で停止するのに適していますが、1 行のコードに複数の式が含まれる場合があります。コンパイラは、これらの式に対して複数の停止位置を生成します。入りたいですかconvertedToVolume、デバッガは最初に入るかもしれませんadjustedDensity。次に、ステップアウトしてからステップインする必要があります。これを数回繰り返すと、デバッグのリズムが崩れてしまいます。

Xcode 13 は、この粒度の問題を解決します。列ブレークポイント(Column Breakpoint)を追加します。開発者は、同じ行の式にブレークポイントを配置できます。プログラムが一時停止されると、Xcode は Column PC を使用して式の下に緑色の下線を引き、次にどの式が実行されるかを示します。

シンボリック ブレークポイントにも同様の問題点があります。関数名を入力すると、LLDB はプロセスによってロードされたすべてのライブラリでその関数名を照合します。関数名が一般的すぎる場合は、数百件もヒットすることがあります。関数名のスペルを間違えると、ブレークポイントが失われ続けるため、その理由を推測することしかできません。

Xcode 13 では、未解決のブレークポイントに対する点線のアイコンとヒントが追加されています。これは、シンボル名のスペルが間違っているかどうか、シンボルが存在するかどうか、ライブラリがロードされているかどうか、ソース コード行がコンパイルに参加したかどうか、モジュールがデバッグ情報を生成したかどうかなど、一般的な原因を指摘します。

実行時の問題は 3 番目のタイプのシナリオです。たとえば、バックグラウンド スレッドで UI 状態を変更します。デフォルトでは、Xcode は呼び出しスタックを問題ナビゲーターに記録しますが、プログラムを一時停止しません。問題が発生した後、現在のプロセスのステータスを確認しても、通常はあまり役に立ちません。実行時問題ブレークポイントにより、問題が発生したときにプログラムが停止する可能性があります。

詳細

列ブレークポイント: 行内で停止する特定の式

(02:27) 行ブレークポイントはソース コード行で一時停止します。行内に複数の式がある場合、LLDB はコンパイラによって生成された行テーブルに基づいて停止位置を選択します。 Xcode 13 の列ブレークポイントは、停止ポイントを式レベルに進めます。

キー操作は以下の通りです。

Command-click expression
Select "Set Column Breakpoint"
Continue execution
Check the green underscore from Column PC
Step into the highlighted expression

キーポイント:

  • Command-click expression: ターゲット式でアクション ポップオーバーを開きます。
  • Set Column Breakpoint: ブレークポイントをこの列の式にバインドします。
  • Continue execution: 列ブレークポイントに到達するまで実行を続けます。
  • Column PC: 緑色の下線は、デバッガーが次に実行する式をマークします。
  • Step into:シングルステップ入力を実行する前に、下線が対象式の下にあることを確認してください。

(04:15) この機能は、Swift クロージャと Objective-C ブロックにとってより実用的です。 Swift 行には複数のクロージャが存在する場合があります。以前は、ライン全体のポイントをブレークし、ステップインとステップアウトを繰り返すことしかできませんでした。これで、最後のものを直接追加できるようになりました$0列ブレークポイントをオンに設定します。

キー操作は以下の通りです。

Command-click the last $0
Select "Set Column Breakpoint"
Inspect $0 when the debugger pauses

キーポイント:

  • the last $0: ターゲットは、同じ行の最後のクロージャの匿名パラメータです。
  • Set Column Breakpoint: クロージャに対応する行テーブル エントリで LLDB を一時停止させます。
  • Inspect $0: 一時停止位置はターゲット クロージャ内にあり、匿名パラメータを直接表示できます。

シンボリック ブレークポイント: 関数名で一時停止し、モジュールのスコープを制限します

(05:27) シンボリック ブレークポイントは関数名によって一時停止します。これは、ソース コード ファイルがない場合、または多くのサブクラスが同じ関数を実装している場合、および各ファイルにブレークポイントを設定したくない場合の 2 つの状況に適しています。

Xcode でシンボリック ブレークポイントを作成するパスは次のとおりです。

Breakpoint Navigator
Add button
Symbolic Breakpoint
Symbol: toggle
Module: Fruta

キーポイント:

  • Breakpoint Navigator: ブレークポイント管理エントリ。
  • Add button: 作成できるブレークポイントの種類のリストを開きます。
  • Symbolic Breakpoint: シンボル名で一時停止する場合に選択します。
  • Symbol: toggle:照合する関数名を入力します。
  • Module: Fruta: システム ライブラリ内の同じ名前のシンボルが一緒にヒットするのを防ぐために、一致範囲をアプリケーションのメイン バイナリに制限します。

(06:34) 関数名が一般的な単語である場合、モジュールを制限する必要があります。 LLDB は、プロセスによってロードされたすべてのライブラリ内のシンボルと一致します。に限定されるFrutaその後、デモ内のヒット位置は、潜在的に多数の結果から 3 つに絞り込まれました。

未解決のブレークポイント: アイコンと LLDB を使用したタイプミスの検出

(07:59) Xcode 13 では、LLDB によってどこにも解決されないブレークポイントが点線のアイコンとして表示されます。アイコンの上にマウスを置くと、Xcode で一般的な説明が表示されます。

一般的な理由は次のとおりです。

Symbol name must be spelled correctly
Symbol must exist in its library
Library for the breakpoint must be loaded
Source line must be compiled
Module must have debug info

キーポイント:

  • Symbol name注: シンボリック ブレークポイントの関数名の綴りは正確である必要があります。
  • Symbol must exist: シンボルは指定されたライブラリに存在する必要があります。
  • Library ... loaded: ライブラリはユーザーの操作後にロードされる場合があり、LLDB はロード後に自動的にライブラリを解析します。
  • Source line ... compiled: ソース コードのブレークポイントが配置されている行はコンパイルに参加する必要があります。
  • debug info: モジュールはデバッグ情報を生成する必要があります。そうしないと、ソース コードのブレークポイントを解析できません。

(09:15) デモでは、開発者はconvertedToMass終わりconvertToMass。ソースコード内を直接検索するconvert複数の結果が得られます。より高速な方法は、Xcode コンソールで LLDB を使用して、プロセス内でシンボル名を検索することです。

image lookup -rn convert Fruta

キーポイント:

  • image: LLDB のモジュールの略でもあります。
  • lookup: モジュール内のシンボル情報を検索します。
  • -r: 正規表現マッチングを使用します。
  • -n: 名前で検索します。
  • convert: 検索するシンボル名のフラグメント。
  • Fruta: 検索をアプリケーション モジュールに限定します。

このコマンドは、デモでは 4 つの一致のみを返します。結果は、正しい関数名が次であることを示します。convertedToMass。これをブレークポイント エディターにコピーして戻すと、LLDB は 1 つの場所に正常に解決されました。

ソース コードのブレークポイントが解決されていません: コンパイル条件とデバッグ情報を確認してください

(10:22) 未解決のブレークポイントは、ソース コードのブレークポイントにも表示されます。デモのブレークポイントは 23 行目に配置されていますが、この行はコンパイラ条件にあります。elseブランチの場合、現在のビルドではコンパイルされません。

トラブルシューティングのパスは次のとおりです。

Check whether the source line is compiled
Check build settings for debug info

キーポイント:

  • source line is compiled: ブレークポイントが配置されている行は、現在のビルド製品に入る必要があります。
  • build settings: モジュールがデバッグ情報を生成しない場合は、ビルド設定を確認する必要があります。
  • debug info: デバッガーは、デバッグ情報に基づいて、ソース コードの場所をコンパイルされたアドレスにマップします。

実行時問題ブレークポイント: 問題が発生したときに一時停止します。

(10:49) 実行時の問題 (実行時の問題) は、実行フェーズ中に発生する問題です。講演で挙げられた例は、バックグラウンド スレッドから UI 状態を変更することです。デフォルトの動作では、バックトレース (コールスタック) が記録され、問題ナビゲーターに表示されます。

問題が発生したときにプロセスのステータスを調べたい場合は、実行時問題ブレークポイントを作成できます。

Add Runtime Issue Breakpoint
Choose a specific type in the type popup
Open Scheme Editor
Diagnostics tab
Enable Main Thread Checker

キーポイント:

  • Runtime Issue Breakpoint: 実行時の問題が発生したときにデバッガーを一時停止させます。
  • type popup: 特定の質問の種類を選択します。
  • Scheme Editor注:一部のランタイム問題ブレークポイントでは、最初に対応する診断機能を有効にする必要があります。
  • Diagnostics tab: 診断スイッチの位置。
  • Main Thread Checker: メインスレッドに関連する実行時の問題をキャプチャするためにデモで使用される診断機能。

重要ポイント

  • 内容: 複雑な Swift 呼び出しチェーン用の「式レベルのデバッグ マニフェスト」を作成します。 実行する価値がある理由: 列ブレークポイントは、同じ行内の特定の式で停止できます。これは、複数のクロージャと複数の関数呼び出しを含む Swift コードのデバッグに適しています。 開始方法: プロジェクト内のキーで複数のクロージャを含む長い行を見つけます。$0または、Command キーを押しながらターゲット呼び出しをクリックし、列ブレークポイントを設定し、列 PC を使用して一時停止位置を確認します。

  • 内容: プロトコルまたは基本クラスと同じ名前の実装に対してシンボリック ブレークポイントを確立します。 実行する価値がある理由: シンボリック ブレークポイントは、複数のクラスの同じ名前の関数を一度にカバーできるため、ポイントを 1 つずつブレークする必要がなくなります。 開始方法: ブレークポイント ナビゲーターで新しいシンボリック ブレークポイントを作成し、シンボルに関数名を入力し、モジュールにアプリケーション バイナリ名を入力します。

  • 何をすべきか: 「ブレークポイントがヒットしない」トラブルシューティング プロセスをチームのデバッグ ドキュメントに書き込みます。 実行する価値がある理由: Xcode 13 で LLDB の未解決のブレークポイントが表示されるimage lookup -rnシンボル名を素早く確認できます。 開始方法: Xcode コンソールで実行しますimage lookup -rn <name> <module>、実際のシンボル名を確認し、ブレークポイント エディターでシンボルを修正します。

  • 内容: UI スレッドの問題に対して専用のランタイム問題ブレークポイントを作成します。 価値がある理由: 問題ナビゲーターは、すでに発生した問題のみを表示できます。ランタイム問題ブレークポイントを使用すると、その場で変数と呼び出しスタックを検査できます。 開始方法: スキーム エディターの [診断] タブでメイン スレッド チェッカーを開き、ランタイム問題ブレークポイントを追加します。

  • 内容: デバッグ チェックの手順を条件付きでコンパイルされたコードの隣に置きます。 実行する価値がある理由: 現在のビルドでは行がコンパイルされないため、ソース コードのブレークポイントは解決されない可能性があります。 開始方法: 点線のブレークポイントが見つかった場合は、まずその行が現在のコンパイラ条件に該当するかどうかを確認し、次にモジュールがデバッグ情報を生成するかどうかを確認します。

関連セッション

コメント

GitHub Issues · utterances