Speechフレームワークで音声認識を実装した後、以前Core Locationでのバックグラウンド位置情報取得を実装した経験を踏まえ、今度は特定エリアへの出入りを検知するジオフェンシングに挑戦しました。
1. バックグラウンド位置取得と同じ仕組みだと思っていた
最初、以前実装した継続的な位置情報取得の延長で、取得した座標を自分で判定すればジオフェンシングも作れると考えていました。
locationManager.startMonitoring(for: region)実際にはCore Locationにリージョン監視専用のAPIが用意されており、座標を継続的に取得して自分で判定するよりも、システム側に監視を任せるstartMonitoring(for:)を使う方がバッテリー消費を抑えられる設計になっていると分かりました。目的に応じて適切なAPIを選ぶ必要がありました。
2. 監視できるリージョン数に上限があることを知らず苦労した
登録したいエリアが増えてきたため、思いつく限りのリージョンをすべて監視対象に追加しようとしたところ、途中から新しいリージョンが反映されなくなりました。
制約:
1アプリあたり同時に監視できるリージョンは20件まで調べてみると、iOSでは1つのアプリが同時に監視できるリージョンの数に上限があることが分かりました。すべてのエリアを常時監視するのではなく、ユーザーの現在地に近いエリアだけを動的に選んで監視対象を絞り込む設計に変更する必要がありました。
3. 境界付近で入退場イベントが何度も発生した
ユーザーがエリアの境界付近に留まっていると、入場・退場のイベントが短時間に何度も発生してしまう現象に悩まされました。
気づいたこと:
GPSの誤差により境界をまたいで判定が揺れるGPSの精度には一定の誤差があり、境界ぎりぎりの位置にいるとその誤差の範囲内で判定が行ったり来たりしてしまうことが原因だと分かりました。リージョンの半径に多少の余裕を持たせたり、同じイベントが短時間に連続した場合は無視するような処理を加えることで、体感上の不安定さを軽減しました。
4. アプリを終了していてもイベントを受け取れると誤解していなかったが確認に苦労した
ジオフェンシングの大きな利点として、アプリを起動していなくても入退場を検知できると聞いていたものの、本当に機能するのか半信半疑で確認作業を進めました。
確認方法:
アプリをタスクキルした状態で実機を対象エリアまで移動実際にアプリを完全に終了させた状態でも、対象エリアに入るとCLLocationManagerDelegateのメソッドが呼ばれてアプリが必要に応じて起動されることを実機で確認できました。シミュレータでは信頼できる検証が難しく、実機での確認が欠かせないと実感しました。
まとめ
- ジオフェンシングには専用の
startMonitoring(for:)があり、継続的な位置取得より省電力に判定できる - 1アプリが同時に監視できるリージョン数には上限があり、ユーザーの位置に応じた動的な絞り込みが必要になる
- GPSの誤差により境界付近ではイベントが不安定に発生しうるため、半径の余裕や連続イベントの間引きで対応する
- アプリ終了後でも入退場イベントを受け取れる設計だが、この挙動は実機での確認が欠かせない
同じCore Locationでも、継続的な位置取得とリージョン監視では設計思想も省電力性も大きく異なると実感した実装でした。
本記事は生成AI（Claude）を活用して執筆・編集しています。内容は実体験に基づき、執筆者本人が確認・監修しています。
コメント