iOS9で位置情報を使う定期バックグラウンド処理をする場合のバッテリー消費を抑えるには？
iOSでのバックグラウンド処理の制限
iOSでのバックグラウンド処理は非常に制限されているが、いくつか方法はある。しかし、「定期的にバックグラウンド処理をする」という条件になるとかなり限られる。
どのような方法を選択できるかはアプリのタイプや目的によるが、アプリによらず選択できるであろう方法は少なくとも２つある。
Background fetch
iOSがアプリの利用頻度などから「非定期に」バックグラウンド処理を動作させるので使えない。
Remote Notifications
サーバーからのNotificationが届くタイミングでバックグラウンド処理を起動する方法だが、サーバーサイドの実装が必要な上、Notificationが届くタイミングはまちまちで、最悪の場合は届かないこともあるので、苦労の割に確実性に欠ける。
AndroidのAlarmManagerの代替は無いのか？
調べた限り、iOSではAndroidでいうところのAlarmManagerのようなバックグランド処理はできない。iOSで言うところの「バックグラウンド」とは、タスクマネージャーにプロセスが残っている状態のことである。つまり、ユーザーがタスクマネージャーからアプリを終了させたらバックグラウンド処理はできない。
位置情報の更新を利用した定期バックグラウンド処理を採用
幸い今回開発中のアプリは位置情報を利用するタイプのアプリなので、「Location updates」のcapabilityを利用して定期的にバックグラウンド処理をさせることができた。
位置情報の更新によるバッテリー消費を抑えるために考えた２つのこと（失敗）
しかし、ここで気になるのは、バックグラウンドで位置情報を更新し続けることによるバッテリーの消費がどれだけのものなのかということ。
そこで、このあたりを参考にした。
Energy Efficiency Guide for iOS Apps: Reduce Location Accuracy and Duration
一番始めに考えたのは、iOS9から導入されたrequestLocation()を利用することだった。タイマーで必要な時だけrequestLocation()を使って位置情報を取得すればバッテリーの消費を抑えられるのではないかと。
How to request a user's location only once using requestLocation – Swift 2 example code
しかし、この方法はダメ。requestLocation()は「Location updates」の処理のうちに入らないらしく、タイマー（プロセス）が止まってしまって定期処理を実現できなかった。
次に考えたのは、beginBackgroundTaskWithExpirationHandler()を使う方法。アプリがバックグラウンドになった時に一定の期間でstartUpdatingLocation()を呼び、すぐに停止させればバッテリーの消費を抑えられるのではないかと。
この方法もダメ。beginBackgroundTaskWithExpirationHandler()によるバックグラウンド処理は約3分間しかもたないうえ、処理が終わった時に新たにbeginBackgroundTaskWithExpirationHandler()を使えないので定期処理を実現できなかった。
startUpdatingLocation()を使いつつ、精度でバッテリー消費をコントロール
やはりタイマー（プロセス）をバックグラウンドで動作させ続けるためにはlocationManager.startUpdatingLocation() を使うことが必要。そこで、「Reduce Accuracy of Standard Location Updates Whenever Possible」のTIPsを使うことにした。つまり、ギリギリまで精度を下げて、できるだけバッテリー消費を抑える作戦。
ところで、pausesLocationUpdatesAutomatically = falseにしないとstartUpdatingLocation()を使っていても15分程度で止まるので注意。また、startMonitoringSignificantLocationChanges()ではバックグラウンド動作しなかったので注意。
実験
指定できるオプションはいくつかあるが、上に行くほどバッテリー消費が激しくなる。
Accuracy Constants - Core Location Constants Reference
ここでは、バッテリー100%の状態からstartUpdatingLocation()して、タイマーを使って定期的にWEB APIを叩いてその結果をNotificationするという作業を12時間続けて何パーセントまで減るかを見た。使用した機体はiPhone5。
まず、この処理をさせない場合は12時間放置で100%だった。実際は100%のマージンが大きすぎるのだろうと思うが、これがユーザーが見る現実だ。
次に「数百メートル」（kCLLocationAccuracyHundredMeters）に設定して15分に一回動作するケースを見たら76%だった。30分に1回にしたら78%。少しは効果があるが、やはりほとんどは位置情報の更新にエネルギーが費やされていると考えられる。
次はいきなり「3キロ」（kCLLocationAccuracyThreeKilometers)に設定して15分に一回動作するケースを見たら84%だった。かなり消費を抑えられる。
問題はkCLLocationAccuracyThreeKilometersに設定した場合の位置情報の精度がどれくらいのものなのかということだ。
調べた限りでは、かなり正確な場合もあるし、数百メートルずれている場合もあったが、キロ単位でずれていることは無かった。
結論
位置情報の更新を使って定期的なバックグラウンド処理をする場合は、できるだけkCLLocationAccuracyThreeKilometersを設定し、タイマーでの動作回数を少なくすると良いだろう。
iOSでのバックグラウンド処理は非常に制限されているが、いくつか方法はある。しかし、「定期的にバックグラウンド処理をする」という条件になるとかなり限られる。
どのような方法を選択できるかはアプリのタイプや目的によるが、アプリによらず選択できるであろう方法は少なくとも２つある。
Background fetch
iOSがアプリの利用頻度などから「非定期に」バックグラウンド処理を動作させるので使えない。
Remote Notifications
サーバーからのNotificationが届くタイミングでバックグラウンド処理を起動する方法だが、サーバーサイドの実装が必要な上、Notificationが届くタイミングはまちまちで、最悪の場合は届かないこともあるので、苦労の割に確実性に欠ける。
AndroidのAlarmManagerの代替は無いのか？
調べた限り、iOSではAndroidでいうところのAlarmManagerのようなバックグランド処理はできない。iOSで言うところの「バックグラウンド」とは、タスクマネージャーにプロセスが残っている状態のことである。つまり、ユーザーがタスクマネージャーからアプリを終了させたらバックグラウンド処理はできない。
位置情報の更新を利用した定期バックグラウンド処理を採用
幸い今回開発中のアプリは位置情報を利用するタイプのアプリなので、「Location updates」のcapabilityを利用して定期的にバックグラウンド処理をさせることができた。
位置情報の更新によるバッテリー消費を抑えるために考えた２つのこと（失敗）
しかし、ここで気になるのは、バックグラウンドで位置情報を更新し続けることによるバッテリーの消費がどれだけのものなのかということ。
そこで、このあたりを参考にした。
Energy Efficiency Guide for iOS Apps: Reduce Location Accuracy and Duration
一番始めに考えたのは、iOS9から導入されたrequestLocation()を利用することだった。タイマーで必要な時だけrequestLocation()を使って位置情報を取得すればバッテリーの消費を抑えられるのではないかと。
How to request a user's location only once using requestLocation – Swift 2 example code
しかし、この方法はダメ。requestLocation()は「Location updates」の処理のうちに入らないらしく、タイマー（プロセス）が止まってしまって定期処理を実現できなかった。
次に考えたのは、beginBackgroundTaskWithExpirationHandler()を使う方法。アプリがバックグラウンドになった時に一定の期間でstartUpdatingLocation()を呼び、すぐに停止させればバッテリーの消費を抑えられるのではないかと。
この方法もダメ。beginBackgroundTaskWithExpirationHandler()によるバックグラウンド処理は約3分間しかもたないうえ、処理が終わった時に新たにbeginBackgroundTaskWithExpirationHandler()を使えないので定期処理を実現できなかった。
startUpdatingLocation()を使いつつ、精度でバッテリー消費をコントロール
やはりタイマー（プロセス）をバックグラウンドで動作させ続けるためにはlocationManager.startUpdatingLocation() を使うことが必要。そこで、「Reduce Accuracy of Standard Location Updates Whenever Possible」のTIPsを使うことにした。つまり、ギリギリまで精度を下げて、できるだけバッテリー消費を抑える作戦。
ところで、pausesLocationUpdatesAutomatically = falseにしないとstartUpdatingLocation()を使っていても15分程度で止まるので注意。また、startMonitoringSignificantLocationChanges()ではバックグラウンド動作しなかったので注意。
実験
指定できるオプションはいくつかあるが、上に行くほどバッテリー消費が激しくなる。
Accuracy Constants - Core Location Constants Reference
ここでは、バッテリー100%の状態からstartUpdatingLocation()して、タイマーを使って定期的にWEB APIを叩いてその結果をNotificationするという作業を12時間続けて何パーセントまで減るかを見た。使用した機体はiPhone5。
まず、この処理をさせない場合は12時間放置で100%だった。実際は100%のマージンが大きすぎるのだろうと思うが、これがユーザーが見る現実だ。
次に「数百メートル」（kCLLocationAccuracyHundredMeters）に設定して15分に一回動作するケースを見たら76%だった。30分に1回にしたら78%。少しは効果があるが、やはりほとんどは位置情報の更新にエネルギーが費やされていると考えられる。
次はいきなり「3キロ」（kCLLocationAccuracyThreeKilometers)に設定して15分に一回動作するケースを見たら84%だった。かなり消費を抑えられる。
問題はkCLLocationAccuracyThreeKilometersに設定した場合の位置情報の精度がどれくらいのものなのかということだ。
調べた限りでは、かなり正確な場合もあるし、数百メートルずれている場合もあったが、キロ単位でずれていることは無かった。
結論
位置情報の更新を使って定期的なバックグラウンド処理をする場合は、できるだけkCLLocationAccuracyThreeKilometersを設定し、タイマーでの動作回数を少なくすると良いだろう。
コメント
コメントを投稿