ブレークポイントの改善

♪ （ブレークポイントの改善） こんにちは Han Ming Ongです Xcode Debugger UIチームの エンジニアです 今日は私たちが ブレークポイントに 加えた改善点について お話したいと思います これによりデバッグの 生産性が向上します まずはブレークポイントの 基本から始めましょう プログラムにバグが発生した場合 それはあなたの期待通りに 実行されていないことを意味します なぜ期待通りにならなかったのか デバッガで確認したいですよね この時点でデベロッパは ２つの一般的なことを行います まず状況をさらに理解するために プロセスの状態を検査することです ２つ目はプロセスの実行に 踏み込んで あなたの論理を確かめます どちらのアクティビティでも 一時停止する必要があります 理想的にはバグが発生する直前です プロセス一時停止の最善の方法は ブレークポイントの使用です Xcodeで作成できる３つの 共通ブレークポイントについて 話しましょう １つ目はソースファイルの ブレークポイントです これらは単一ファイルに設定される ブレークポイントです 最も一般的なタイプは ラインブレークポイントで ブレークポイントの主力です あなたが調べたいコード行で 一時停止するのに 最適です 作成する最速の方法は 一時停止する行のすぐ隣の余白を クリックするだけです この時点でStep Intoで convertedToVolume関数の ロジックを確認したいです

しかし実際にStep Intoすると 別の表現に踏み込んでいます コンパイラは adjustedDensityを 最初に実行する必要があることを 正しく判定しています もちろん 私はStep Outして 再度関数に戻ることができます しかしそれを何度も 繰り返すとなると かなり面倒になります ここでわかるのは 行ブレークポイントの詳細度が 不十分なことがあるということです これは コンパイラがLLDBが停止する 場所を複数生成したためです 本当に望んでいるのは convertToVolumeが 実行される直前で 一時停止することです そこでXcode 13では 列ブレークポイントを導入しました これにより行内の特定の表現で 一時停止する必要がある場合 行ブレークポイントの 欠点を回避できます ConvertedToVolumeに 列ブレークポイントを設定するには コマンドキーを押しながら 式をクリックし アクションポップオーバーを表示させ Set Column Breakpointを 選択します 行ブレークポイントと同じように アイコンをクリックすれば 無効または有効にできます ブレークポイントを変更する 必要がある場合は ダブルクリックして ブレークポイントエディタを起動します 行ブレークポイントは もう必要ないので 余白からドラッグして 削除できます 列ブレークポイントに対しても 同じことができます でも今はそのままにしておきます コントロールか マウスの右クリックで コンテキストメニューが表示され これに前のアクションが含まれます Reveal in Breakpoint Navigator をここでは選択します ブレークポイントの列を表示するため サブタイトルが修正されました 続けると 次のNutritionFactを繰り返し 新規設定した列ブレークポイントが ヒットします ブレークポイントがヒットすると Xcodeは行PCを使用し 一時停止した行を通知します 線の上に薄緑色の ハイライトが表示されます Xcode 11.4では 列PCを導入しました 列PCには一時停止した列が 式の下の緑色の下線で表示され デバッガが次に実行する 式を知らせます ConvertedToVolumeの下に 列PCが表示されているので 私は自信を持って関数へ 一歩を踏み込めます Swiftのクロージャまたは Objective-Cのブロックの場合 列ブレークポイントは特に便利です この269行のように １つのSwiftラインに 複数のクロージャがある 場合があります コンパイラがデバッグ条件下で ファイルをコンパイルすると 「ラインテーブル」 と呼ばれるマップを作成し ソース行と列をコンパイル済み アドレスにマップします したがってこの行の 各クロージャについて コンパイラは ラインテーブルエントリを生成し デバッガが一時停止に使用します 最後のクロージャの 匿名パラメータ$0を 調べたいとします 行ブレークポイントを269に 設定できますが 一時停止した後 最後のクロージャに 到達するために 何度もステップインと ステップアウトする必要があります 生成された ラインテーブルエントリが原因です Xcode13でそれを 見てきました 最後の$0に列ブレークポイントを 設定するだけで 一時停止するとまさに 行きたい場所にいて そして心ゆくまで $0を検査することができます うーん香りのよいドリアンの スムージーを手にしているようです 朝食にも足りなくありません 一日を始めるのに最適な方法です うまい！ シンボリックブレークポイントに 移りましょう これらは関数名に対する ブレークポイントで これらの関数の実行時に プロセスが一時停止します これはソースファイルの ブレークポイントが 使用不可または不便な場合に 非常に役立ちます たとえばソースファイルに アクセスできないため デバッグ情報でソースファイルの コンパイルができない場合 または共通の機能を実装する サブクラスが多数あって それぞれにファイルブレークポイントを 設定するのが面倒な場合です 見てみましょう ブレークポイントナビゲータの 下部のAddボタンをクリックします これにより作成できるブレーク ポイントがリスト化されます Symbolic Breakpointを選択し 表示されるブレークポイントエディタに シンボル名を入力できます 複数のクラスで実装されている トグル機能を 一時停止したいとします 各クラスを探す代わりに ここに「toggle」と入力するだけです

ただし機能名が一般的な用語の場合は 注意が必要です なぜならLLDBは システムライブラリを含む プロセスで読み込まれる 全ライブラリで名前の 一致を行うからです 制限がないと 解決されたブレークポイント数が 時には数千にもなってしまいます それらの多くが実行パスによって 絶えずヒットされる場合 面倒になる可能性があります ありがたいことに検索を特定の モジュールに制限できます モジュールは実行中に ロードできるバイナリ または画像で メインバイナリを含みます ここに「Fruta」と入力します これは私たちのAppの バイナリ名です そして３つの解決された 場所を取得します これははるかに管理が容易です スムージーを選んだので お気に入りボタンを トグルしましょう 先ほど設定した シンボリックブレークポイントに ヒットします さてシンボリック ブレークポイントの場合 誤字が簡単に起こりえます そしてプログラムの実行中に ブレークポイントがヒットしません これでは困惑してしまいます 「convertToMass」という名前の ファイルを作成してみましょう

Xcode13の新機能で ブレークポイントがLLDBの どの場所にも解決されない場合 Xcodeは破線のアイコンを表示します ブレークポイントが解決されない 理由は無数にありますが よくある理由がいくつかあります 未解決のブレークポイント アイコン上にカーソルを移動すると 役に立つツールチップが表示されます 最初のいくつかの理由は ブレークポイントの 種類に関係します シンボリックブレークポイントの場合 名前が正しく綴られていて シンボルがそのライブラリに 存在する必要があります 次の理由はより一般的です ブレークポイントのライブラリが ロードされている必要があります 多くの場合ライブラリは ボタンのクリックなどの 特定のユーザーアクション後に ロードされます この時点でLLDBが自動的に ブレークポイントを解決します この場合は スペルが間違っているようです 確認してみましょう 1つの方法は検索ナビゲータです 「convert」を検索します ご覧のとおりかなりの 数の結果があります 視覚的に分析するには 時間を要します 代わりにLLDBを介して別の方法を 試してみましょう Xcodeコンソールでは 「image」と入力します これはモジュールも意味します 正規表現では「lookup-r」 名前では「n」「convert」

そして検索を限定するため モジュール名「Fruta」と入力します マッチは４つしかないことが わかります 確かに関数名のつづりを 間違えています 「convertedToMass」 とすべきです コピーしてブレークポイント エディタに貼り付けましょう

すると今度は LLDBが正常に解決し ロケーション番号１を返しました

他のLLDBのヒントや技に 興味がある場合は 前回のプレゼンテーション 「LLDB：「po」の先へ」を ご覧ください 別のファイルを表示してみましょう

ソースファイルの ブレークポイント内の未解決の ブレークポイントも 表示されます それらに関係する２つの 理由があります まずは ブレークポイントの行を コンパイルする必要があります この場合23行目は コンパイルされていません コンパイラ条件の else部分にあるためです またコンパイラはモジュール用の デバッグ情報を 生成している必要があります そうでない場合は ビルド設定の確認が必要です 次は実行時エラーの ブレークポイントです 実行時エラーとは実行時に 発生する問題です バックグラウンドスレッドで UIの状態を変更するなどが一例です クラッシュほど深刻でなく 別のバグに集中したいときに 邪魔になる可能性があるため デフォルトではXcodeは プロセスを一時停止しません 実行時エラーが発生すると Xcodeは代わりに バックトレースを記録し Issue navigatorに表示します しかし問題は過去に起こったので 現在のプロセス状態を検査しても 意味がありません エラーの発生時に問題を 把握したい場合もあるでしょう 実行時エラーブレークポイント があれば 問題の発生時に デバッガで一時停止でき プロセスを検証できます 実行時エラーブレークポイントには さまざまなタイプがあり タイプポップアップで 特定のタイプを簡単に選択できます いくつかのタイプでは 対応する機能を スキームエディタの Diagnosticsタブで 有効にする必要がありますので ご注意ください Go Toボタンのクリックだけで そこに移動できます Main Thread Checkerでの 実行時エラーブレークポイントを 利用したいので Main Thread Checkerを 有効にします このセッションでは Xcode13での ブレークポイントの改善 についてご紹介しました ブレークポイントはデバッグ能力を 大幅に向上させることができます ぜひ皆さんのレパートリーの一部に してください ありがとうございます 残りのWWDCもお楽しみください ♪