前提：GPSはスマホにとって重い処理
位置情報のリアルタイム取得は、
CPU負荷・電池消費・センサーアクセスが大きく、
OSが積極的に監視・制御する対象です。
特にランニング計測のように「長時間・連続」で位置情報を取得する場合、
設定しだいで OS 側が「高負荷アプリ」と判断し、
バックグラウンドプロセスを停止してしまいます。
ORPHE TRACK の初期状態
※アプリでは計測時に下記のようにランニング時の走行軌跡を記録
- geolocator を使用
- LocationAccuracy.high
- distanceFilter = 0m（デフォルト）
[distanceFilter = 0m（デフォルト）]
位置更新頻度：非常に高い → 電池消耗大・OS停止リスク高
移動軌跡イメージ：
●-●-●-●-●-●-●-●-●-● （細かく連続で位置更新）
この状態だと、
iOS側の電池消耗が大きく、10分弱で OS によりアプリが停止する挙動を確認しました。
対策：distanceFilter を 10m に設定
※開発者版にてGPS粒度の調整機能をつくり、アプリが停止しないGPS粒度を検証。
位置更新の粒度を調整し、
無駄に高頻度で位置情報を取得しないようにしました。
[distanceFilter = 10m（ORPHE TRACK）]
位置更新頻度：適度 → 電池消耗低・OS停止リスク低
移動軌跡イメージ：
●---------●---------●---------●
（10mごとに位置更新）
結果
-
ランニング用途では 10m 粒度でも距離計測・軌跡表現に支障なし
-
電池消耗が大幅に低減
-
実測で 90分以上の継続動作を確認
※90min近くバックグラウンド動作→画面オンにした際のアプリ画面
OS 停止メカニズムとの関係
前記事で示したように、
OS は「高負荷プロセス」を検知するとバックグラウンド優先度を下げ、
メモリ・バッテリー状況によってはプロセスを停止します。
GPSを高精度・高頻度で動かし続けると、
この「高負荷判定」に引っかかりやすくなります。
distanceFilter の調整は、
その高負荷判定を避けるための現実的な対策になりました。
保存処理との組み合わせ
GPSデータの書き込み処理も重くなりがちです。
記事1で触れたように、
- 通常時：masamune に保存
- バックグラウンド時：shared_preferences に保存（復帰時に復元）
という構成にすることで、
-
高頻度 GPS ＋ 重い DB 書き込み
という“ダブルパンチ”を避けられるようになりました。
記事2のまとめ
-
GPSは電池消耗・OS停止リスクの観点で最も注意が必要な処理
-
geolocator の distanceFilter を 10m に設定することで、
ランニング用途に十分な精度を保ちながら、安定性を大きく向上できた -
位置情報取得と保存処理はセットで設計し、
バックグラウンド時は「粒度を落とす＋書き込みを軽くする」が重要