はじめに
こんにちは、id:FM_Harmonyです。
今回はiOSアプリの開発で実践したXcodeでのlldbを使ったデバッグ事例について、
3件ほど紹介したいと思います。
lldbを使ったデバッグはブレークポイントで処理を止めて、変数を読み書きする
位かと思っていましたが、
他にもいろいろなことが出来ると知ったので、iOSアプリ開発のTIPS(ノウハウ/テクニック)として紹介します。
lldbとは
前回私が投稿した記事でも紹介しましたが、Xcodeにはlldbというデバッガが入っています。
普通はXcodeでブレークポイントを貼ることで処理を止めて、lldbを使って変数の確認や操作ができますが、
ビルドの設定等によってはそれが出来ないことがあります。
一時的に設定を変えてブレークポイントで処理が止まるようにもできますが、
動作確認したいことによっては、設定を変えずにlldbを使ってデバッグできる事があります。
lldbを使ったデバッグ事例
アプリアイコンのバッジを付与する
デバッグ方法
プッシュ通知機能がアプリに実装されている場合、
受信した通知に合わせて、アプリアイコンにバッジを付与することができます。
iOSの場合、通知内のパラメータでバッジを付与することが出来ますが、
アプリからもコードでバッジを付与することが出来ます。
そのため、ブレークポイントで処理を止めなくても、Xcodeから処理を止めた上で、
以下のコードをlldbで実行することで、任意のタイミングでバッジを付与することができます。
(lldb) expression -l swift -- import UIKit // アプリアイコンのバッジ件数を変更する (lldb) expression -l swift -- UIApplication.shared.applicationIconBadgeNumber = /**【アプリアイコンのバッジ件数(数値)】**/;
expr
は式を評価するコマンドで、1行目でUIKitのフレームワークを読み込み、
2行目でアプリアイコンのバッジを付与します。
注意点としては、処理を止めた箇所によってはSwiftのコードが実行できないため、
expr -l swift
で実行する言語にSwiftを指定する必要があります。
但し、Objective-Cのコードであれば、言語を指定することなく、
そのまま実行することが可能です。
また、ブレークポイントで処理を止めた箇所によっては、
UIKitのフレームワークは読み込まれていない可能性があります。
その場合はバッジを付与する前に読みこむ必要があります。
活用例
例えば、アプリアイコンのバッジ件数が期待値となる動作を行いたい場合、
バッジ件数を確認前の状態に戻すことができるので、とても便利です。
楽楽精算が提供しているiOSアプリは、プッシュ通知機能を提供しており、
アプリからログアウトすることで、それまで付与されていたアプリアイコンのバッジの件数が0件になります。
実際の動作確認では、都度ログアウトする必要があったため、
コマンド1回実行することでアプリアイコンのバッジ件数を戻すことができ、楽に動作確認をすることができました。
UserDefaultsを読み書きする
デバッグ方法
アプリアイコンのバッジのように、UserDefaultsもlldbからコマンドを実行して、
値を読み書きすることが出来ます。
(lldb) expression -l swift -- import Foundation // キー:fugaに対して値:hogeをUserDefaultsに書き込む (lldb) expression -l swift -- UserDefaults.standard.set("hoge", forKey: "fuga") // キー:fugaに対する値をUserDefaultsから読み取る (lldb) expression -l swift -- UserDefaults.standard.string(forKey: "fuga")
1行目で必要なフレームワークを読み込み、2行目以降で操作する流れは、
アプリアイコンのバッジの例と同じです。
活用例
UserDefaultsに保存した情報によっては、アプリの操作で値が変更できないことがあります。
例えば「新バージョンでは利用しなくなった過去バージョンの設定値が残っていた時に何か処理を行う」
といった場合です。
具体的に、旧バージョンではUserDefaultsにある機能の設定値を格納していたが、
新バージョンでその機能は廃止し、設定値が残っていればお知らせを表示するといった場合を考えます。
お知らせが表示されるかを確認する場合、廃止した設定値を画面から操作することはできないため、
旧バージョンで設定値を変更して新バージョンへアップデートする方法があります。
しかし、アップデート前後のアプリをipaなどで用意して、都度アップデートするのは手間が掛るため、
上記の方法でUserDefaultsの値を直接書き換えた方が楽でした。
アプリに保存したCookieを扱う
デバッグ方法
lldbからHTTPCookieStorageを利用することで、
アプリに保存したCookieをデバッグ中に扱うことができます。
(lldb) expression -l swift -- import Foundation (lldb) expression -l swift -- let $storage = HTTPCookieStorage.shared // 名前:hogeに合致する最初のCookieを取得 ※例示のため強制アンラップしている (lldb) expression -l swift -- var $cookie = $storage.cookies!.first{ $0.name == "hoge" }! // 取得したCookieの値を確認 (lldb) expression -l swift -- print($cookie) // 取得したCookieをアプリから削除 (lldb) expression -l swift -- $storage.removeCookie($cookie)
1行目で必要なフレームワークを読み込んで、以降の行で処理を行う流れはこれまでと同じです。
上記で紹介したコマンドと異なる点は、2行目、4行目でコマンドの結果を変数に格納しているところです。
lldbでは先頭に$
マークを付けると、以降のデバッグで変数として利用可能になるので、
HTTPCookieStorageやCookieを変数に格納して、Cookieの確認や削除を行っています。
活用例
アプリに正しくCookieが保存されたか、Cookieの有無で変わる挙動を確認するのに役立ちました。
WebViewを利用した画面では、Cookieを利用することがありますが、
そのCookieはアプリが持つCookieとは別に保存されます。
そのため、WebViewへのアクセスでCookieが更新されたとき、
更新されたCookieをアプリへ同期する必要があります。
例えば、safariのWebインスペクタを利用すればWebViewが利用しているCookieは確認できますが、
実際にアプリが利用しているCookieは確認することができないため、
上記のデバッグ方法により正しいCookieが保存されたか確認できる点で非常に有効です。
余談:ブレークポイントで止まらない事例
今回紹介した事例はいずれもブレークポイントではなく、XcodeのPause program execution
の機能を使って、
処理を止めた際のデバッグ方法です。
ブレークポイントで処理を止めた際は、実装されているコードを操作できるので、
フレームワークの読み込みやUserDefaults、HTTPCookieStorageの操作は楽です。
では、どんな時にブレークポイントを使えないのかというと、
例えば、releaseビルドで作成したipaではブレークポイントが破線になってしまい、
利用することができませんでした。
終わりに
いかがでしたでしょうか。
個人的な感想ですが、これまでpo
コマンドで変数を確認するくらいしかlldbを利用していなかったので、
実行する言語の指定や変数の宣言、値の格納といったことまでlldbで行えることに驚きました。
今回の記事が、iOSアプリ開発に携わる皆様のお役に立ちましたら幸いです。
エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております!
ご興味ありましたら是非ご確認をお願いします。
https://career-recruit.rakus.co.jp/career_engineer/
カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
rakus.hubspotpagebuilder.com
ラクスDevelopers登録フォーム
https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/
イベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください!
◆TECH PLAY
techplay.jp
◆connpass
rakus.connpass.com