こんにちは、今日は、LLDBを使用したiOSアプリケーションのデバッグに関する記事の翻訳に慣れることをお勧めします。
WWDC 2018プレゼンテーションの最も興味深い部分の1つである
LLDBのXcodeと高度なデバッグは 、Appleのエンジニアによって紹介されました。 開発者が見つけたどこでも、Xcodeおよび低レベルデバッガー（LLDB）でブレークポイントを使用して、バグのデバッグプロセスを最適化する方法について、いくつかの有用なヒントを提供しました。
この記事は3つの部分で構成されており、WWDCで述べられている主なポイントについて説明します。 さまざまなタイプのブレークポイント（ブレークポイント）をLLDBと組み合わせて使用して、アプリケーションのバグをキャプチャおよびデバッグする方法を完全に理解するために、デモプロジェクトを作成しました。
デモプロジェクトすべてのiOS開発者が何らかの方法で出会ったテンプレートタスクプロジェクトを作成しました。 記事を読む前に、その仕組みを理解することが非常に重要です。 デモプロジェクトの主な機能は次のとおりです。
- 開くと、投稿のリストをロードするTable View Controllerが表示されます。
- 下にスクロールすると、Table View Controllerは新しい投稿をロードします。
- 合計で、投稿を7回ロードできます。
- 投稿のリストを更新するには、更新コントローラーを使用してプルダウンします（プルダウンして更新します）。
- 上部のナビゲーションバーには、ダウンロードされた投稿の数（右ラベル）と、ユーザーが既に投稿をアップロードした回数（左ラベル）を表示する2つのラベル（ラベル）があります。
Objective-Cを使用
する場合は
、ここからデモプロジェクトをダウンロードできます。
Swiftをご希望の場合は
、こちらから 。
Xcodeを起動して、始めましょう！
修正するバグ！そのため、プロジェクトに精通し、おそらく次のエラーに気付いたでしょう。
- テーブルを下にドラッグしても、リフレッシャーは投稿を更新しません。
- ユーザーは、接続の問題が原因でHTTP要求が完了していないという通知を（アラートコントローラーを使用して）受け取りません。
- 投稿を7回以上読み込むことができます。
- ダウンロード数のカウントを担当するナビゲーションバーの左側のインジケータ（ラベル）は機能しません。
重要なルール：この記事の終わりまで、コンパイラーを停止せず、最初の起動後にアプリケーションを再起動しないでください。 プログラムの実行中にエラーを修正します。
指示の力最初のバグに取りかかりましょう。
1.テーブルがプルダウンされると、投稿は更新されません。エラーを再現する方法：
- アプリケーションを起動すると、最初の10件の投稿が既に読み込まれています。
- 下にスクロールして、さらに投稿を読み込みます。
- テーブルの先頭までスクロールし、下にドラッグして更新します。
- 新しい投稿は読み込まれず 、古い投稿は消えず、投稿カウンターはリセットされません。
このようなエラーを修正するための標準的なアプローチには、テーブルのUIRefreshControlを担当するメソッドセレクター内で何が起こるかを調べることが含まれます。
プラグママークリフレッシュコントロールサポートセクションの
PostsTableViewControllerに移動します。 setupRefreshControl関数から、投稿の更新を担当するセレクターはreloadNewPosts関数であると結論付けることができます。 この関数の最初の行にブレークポイントを追加して、ここで正確に何が起こっているのかを調べましょう。 テーブルの先頭までスクロールし、画面をドラッグして更新します。
Objective-c
スイフトデバッガーは、設定したブレークポイントで停止しました。 さらに学習するには、デバッガの「ブロックをスキップ」ボタンをクリックしてください。
Objective-c
スイフトこれで、何が間違っているのか理解できました！
「if」条件が満たされていない（つまり、ブール変数isPullDownToRefreshEnabledがNOに設定されている）ため、投稿を更新するためのコードはスキップされます。
標準的なアプローチでは、コンパイラを停止する必要があります。次に、isPullDownToRefreshEnabledをYES / trueに設定する必要があり、これにより問題が解決します。 しかし、コードを変更する前に、コンパイラを停止せずに、まず仮説をテストする方がはるかに便利です。 これは、デバッガーの命令コマンドが非常に役立つことが判明した場所です。
インストールされたブレークポイントをダブルクリックするか、「ブレークポイントの編集」を右クリックして「アクションの追加」ボタンをクリックします。 また、アクションタイプ「デバッガーコマンド」を選択します。
ここで、isPullDownToRefreshEnabledプロパティをYES / trueに設定する必要があります。 次のコマンドをデバッガーに追加します。
Objective-c
expression self.isPullDownToRefreshEnabled = YES
スイフト
expression self.isPullDownToRefreshEnabled = true
次に、「アクションの評価後に自動的に続行する」チェックボックスが選択されていることを確認します。 彼は、デバッガー
が毎回ブレークポイントで停止
せず 、新しく追加されたコマンドを自動的に処理し続けることを保証する責任があります。 テーブルの先頭までスクロールし、下にドラッグして更新します。
Voila、新しい投稿が読み込まれ、古い投稿が置き換えられ、それに応じて投稿カウンターが更新されました。
最初の問題を解決し、バグ対策武器を入手して、2番目に進みます。
2.ユーザーは、接続の問題が原因でHTTP要求が完了していないという通知を（アラートコントローラーを使用して）受け取りません。エラーを再現する方法：
- iPhone /シミュレーターでインターネット接続を切断します。
- 表の先頭までスクロールし、下にドラッグして更新します。
- インターネット接続エラーのため、新しい投稿はダウンロードされません。
- ユーザーにはエラー通知は表示されません。
プラグママークネットワークセクションの
PostsTableViewControllerに移動します。
loadPosts関数が1つ
だけあります。 一般的なネットワークマネージャーインスタンスを使用して、「成功」完了ハンドラーを介して投稿の配列を返すGET HTTP要求を実行するか、「失敗」完了ハンドラーを介して
NSErrorを返します。
アラートコントローラーを表示するには、「失敗」クロージャーにコードを追加する必要があります。 プラグママークの
サポートセクションに移動すると、目的のアラートコントローラーの表示を担当する
presentNetworkFailureAlertController関数が既にあることが
わかります。 必要なのは、
loadPostsの 「失敗した」クロージャー内でこの関数を呼び出すこと
だけです。
従来の方法は、シミュレータを停止し、目的のコードを追加することです。 他の方法で行こう！
「失敗した」クロージャー内の行の後にブレークポイントを追加します
Objective-c
[self updateUIForNetworkCallEnd];
スイフト
self.updateUIForNetworkCallEnd()
インストールされたブレークポイントをダブルクリックするか、「ブレークポイントの編集」を右クリックして「アクションの追加」ボタンをクリックします。 また、アクションタイプ「デバッガーコマンド」を選択します。
次のコマンドをデバッガーに追加します。
Objective-c
expression [self presentNetworkFailureAlertController]
スイフト
expression self.presentNetworkFailureAlertController()
「アクションの評価後に自動的に続行する」チェックボックスが選択されていることを確認します。
インターネットをオフにして、テーブルの先頭までスクロールして下にドラッグして更新するか、テーブルの末尾までスクロールして新しい投稿をロードしてみてください。 表示される内容は次のとおりです。
今やったことは、特定のブレークポイントでデバッガーに追加されたコマンドを使用し
てコードを
「挿入
」することです。
簡単な要約ブレークポイントに追加されたデバッガーコマンドを使用してできることをもう一度リストします。
- 既存のプロパティ値で操作します。
- 新しいコード行を追加します。
両方のタスクは、プログラムの実行中に行われました。 基本的に、エラーを修正してアプリケーションを再起動するためにコンパイラを停止する必要はありません。
次は？さらに、
記事の2番目の部分に注目します。ここでは、さらにエラーを修正し、別の種類のブレークポイント（ブレークポイント）-観測ポイント（ウォッチポイント）について学習します。