前提：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 に設定することで、
ランニング用途に十分な精度を保ちながら、安定性を大きく向上できた
位置情報取得と保存処理はセットで設計し、
バックグラウンド時は「粒度を落とす＋書き込みを軽くする」が重要