iOS 24/7でジオロケーションを操作する

最近、私はしばしば質問を見ます：

iOSは、アプリケーションが最小化され、データをサーバーに送信するときにジオロケーションで動作できますか？

それは本当に可能であり、まったく難しいことではありません。

プレビュー記事に収める方法 。

ただし、多くの場合、タスクはより複雑であり、この分野でかなりの経験があるため、この経験を共有することにしました。

いくつかの詳細を得るために、自転車トラッカーを作成するタスクに直面することを提案しました。 ユーザー側から見ると、次のようになります。

1. アプリケーションをダウンロードする
2. 走る
3. 登録する
4. 私は彼らが尋ねる場所をクリックします
5. 私は閉じます
6. 乗る
7. 走る
8. 結果を見る

ps最終コードはこちらです。

開発には、3つの主要な作業領域があります。

1. 地理データを使用した作業の安定性。
   
   ユーザーがアプリケーションを起動、最小化、または完全に閉じた-アプリケーションはデータを処理する必要があります。
2. バッテリー節約。
   
   おそらく、追加の説明は必要ありません。
   
   ところで、これは仕事の最も難しい部分です。
3. 適切なデータ処理。
   
   データを操作するには、テストとデバッグが必要です。

マネージャーの初期化

最初に、 CLLocationManagerの使い慣れた作業を見てみましょう。

1. マネージャーを作成します。
2. イベントを購読します。
3. 位置情報の変化に対応するためにマネージャーを開始します。

ただし、これを機能させるには、その場所に関する情報を使用できることを確認するユーザー確認が必要です。

...または私は権利を持っていますか？

iOSは、ジオロケーションを操作するための2つの権限を提供します。

1. requestWhenInUseAuthorization-アプリケーションがアクティブなときに場所の更新に関する情報を受け取ることができます。
2. requestAlwaysAuthorization-さらに、アプリケーションがアクティブでない/閉じているときに、 CLLocationManager APIイベントを受信する機会を取得します 。

このことから、バックグラウンドでのジオロケーションの操作はrequestAlwaysAuthorization権限でのみ実行できると考えるかもしれません-これはそうではありません。

それと同じように、 requestAlwaysAuthorizationでは、「箱から出して」バックグラウンドで静かに作業することはできません。 地域、人気のある場所、重要な動きなどを扱うことです。

上記のコードがプロジェクト内にある場合、 requestWhenInUseAuthorization（）またはrequestAlwaysAuthorization（）メソッドを呼び出しても、ユーザーに権限の要求に関するアラートは表示されません。

これを行うには、対応するキーNSLocationAlwaysUsageDescription / NSLocationWhenInUseUsageDescriptionの info.plistにメッセージの説明テキストを追加する必要もあります。

これで、ユーザーが権利を確認した後、ジオロケーションを操作できます。

私たちはバックグラウンドで働いています

アプリケーションがバックグラウンドで位置情報を処理するには、2つのことを行う必要があります。

1. CLLocationManagerで設定
   
   

    allowsBackgroundLocationUpdates = true
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

2. バックグラウンドモードのパラメーターに追加します（「バックグラウンドモード->場所の更新」）。 そうでない場合、例外がスローされます。

すべて、アプリケーションはジオロケーションを使用してバックグラウンドで動作し、ネットワーク要求などを送信できます。

何かがうまくいかなかった

アプリケーションを最小化したユーザーがしばらくの間システムの観点から動かないままになると、ジオロケーションは停止し、それによってアプリケーションも停止します。

問題は、デフォルトではCLLocationManagerが一時停止を使用してpausesLocationUpdatesAutomaticallyをジオロケーションすることです 。 そして、このパラメーターは見た目ほど単純ではありません。

1. アプリケーションを起動し、動き始めました。 アプリケーションは動作しています。
2. アプリケーションを最小化し、移動を続けました。 アプリケーションは動作しています。
3. 私は友人に会い、彼と話すことをやめた。 アプリはまだ実行中です。

そして、ある時点で機能しなくなります。

ご理解のとおり、一時停止が開始され、しばらくして、バックグラウンドにあるアプリケーション自体の作業が停止しました。 これは一時停止なので、かなり論理的です。

私は動き続けましたが、LocationManagerはまだ一時停止されていました。 そして、私がアプリケーションを自分でデプロイするまで、彼は一時停止したままです。

したがって、システムは、「停止」前に作業する必要がある場合にバッテリー電力を節約しようとします。

これは私たちにとって具体的な問題なので、LocationManagerの一時停止をオフにしてください。

 pausesLocationUpdatesAutomatically = false
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

殺さないで イワン・ツァレビッチ ユーザー名！

以前、 requestAlwaysAuthorizationジオロケーションアクセス権については既に言及しました。 また、 CLLocationManager APIイベントを受信できるようにします。 バックグラウンドとアンロード状態の両方を受信します。 後者の場合、システムはアプリケーションを再起動して新しいイベントを配信できます。 例：

 locationManager.startMonitoringSignificantLocationChanges() —    locationManager.startMonitoringVisits() —    locationManager.startMonitoring(for: CLRegion) —        
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これが使用するものです。 使用してアプリケーションを強制終了する場合、できるだけ早く作業に戻る必要があります。 私の場合、地域には半径の制限があるため、最も適しているのはstartMonitoringSignificantLocationChangesです。 主なことは 、 CLLocationManagerの起動と構成を忘れないことです 。

いいね！ アプリケーションはバックグラウンドで動作し、アプリケーションは再起動し、ジオロケーションで動作し、ネットワークで動作できます。 デバイスからそのようなアクティビティがあった場合、彼らを削除します。

バッテリー節約

エネルギー消費の統計を開くと、99.99％の確率のアプリケーションがリーダーとなり、残念ながら、節約にはなりません。 したがって、最適化を行います。

エラー

バッテリー消費は、 CLLocationManagerからの必要なエラーの影響を大きく受けます。

最も正確なデータを要求できますが、約10メートル、3キロメートル、およびtp（ kCLLocationAccuracy * ）の誤差で要求できます。

したがって、必要なデータ品質が高いほど、バッテリーの消費量が多くなります。

したがって、100m内に十分なエラーがある場合、最大品質を取得する必要はありません。

さらに興味深いのは、低品質が必要な場合、システムが期待以上の結果をもたらす可能性が高いことです。 したがって、実際に必要なものよりもエラーを要求しないことが不可欠です。

ps requiredは有効という意味ではありません。

構成

さらに、 distanceFilterとallowDeferredLocationUpdatesについて考えれば、バッテリーの戦いに勝つことができます。

• distanceFilterを使用すると、距離をメートル単位で設定できます。この間、ポイントからポイントへの位置情報の変更は必要ありません。 節約はそれほど大きくありませんが、節約です。
• 遅延通知（allowDeferredLocationUpdates）により、システムはその裁量で、または指定された基準に従って情報を配信できます。
  
  基準は距離と時間です。
  
  たとえば、最後のポイントが受信された瞬間から、ポイントが5分以内に到着しない場合、アプリケーションロジックは中断しませんが、システムはそれらを一度に配信します 。
  
  基準は5分に等しい時間です。 この時点で別のアプリケーションがジオデータを要求すると、システムは同時に累積ポイントを提供する場合があります。 CLLocationManagerの構成には、覚えておく必要のある多くの関連する制限があります。

本当に必要なときにデータを操作する

私たちの目標はバイクトラッカーであることを示しました。 現時点では、データが必要かどうかに関係なく、常にデータを処理します。 一時停止のため、ジオロケーションを停止できません。

1つのソリューションは、旅行中およびその他の時間に必要なデータ品質を変更します。 最高のデータと最悪のデータの差はほぼ4倍です。

現在では、ユーザーが自転車に乗るときを追跡するだけです。 これには、 CoreMotionのCMMotionActivityManagerを使用できます。

まだ改善の余地はありますか？ もちろん。 このアプローチは、すべてのジオロケーションをバックグラウンドで処理することが重要な場合に必要です。 さらにあなたの想像力に依存します。

ロケーション処理の確認

アプリケーションを確認する必要があります。 「旅行」を書く過程で脱落するのは得策ではありません。 はい、このアプローチでのデバッグは忘れられます。

幸いなことに、AppleはGPXファイルの使用を許可しています（この場合、実際のデバイスは必要ありません）。

移動ルートを生成するサービスを選択し、gpxにフォームのファイルを保存します。

結論の代わりに

残念ながら、面白いこと、明白なことを書くのは難しいので、多くの点はありません。

• アプリケーションがバックグラウンドで「再起動」すると、ユーザーは彼を「殺す」ことができなくなります。
• アプリケーションがバックグラウンドにあるときにジオロケーションが一時停止された場合、プッシュ通知、リージョンなどを使用してジオロケーションを一時停止することはできません。 同じことがマネージャーの再起動にも当てはまります。 これは、アプリケーションの「反転」後にのみ適用されます。
• ジオロケーションはエラーとともに機能します。 フィルターを使用しない場合、1か所に立っている間に位置情報に多くの変更を加えることができます。
• 実際のデバイスでジオロケーションシミュレーションを有効にすると、他のアプリケーションも「新しい」ジオロケーションで機能します。 たとえば、カード。
• ジオロケーションの長いシミュレーションを使用すると、実際のデバイスは「スティック」してシミュレーションの停止を停止できます。 再起動のみが役立ちます。
• アプリケーションを起動すると、「古いポイント」を取得する可能性があります。 tsを見るのを忘れないでください。
• CLLocationManagerをラップして、テストのためにGPXを解析できます。
• GPXファイルでは、速度をポイント単位で設定できます。
• 一部のオブジェクトの近くのGPSが機能しない場合があります。
• 機内モードでジオロケーションを使用できます。
• SIMカードなしでジオロケーションを使用できます。

ps最終コードはこちらです。