状況：私のプログラムには、場所に大きく依存する部分がありますが、場所が実際に必要な場合の問題をスピードアップするために、ロックする時間がありません。私が設計した解決策は、特定の部分がそれらを必要とするときに位置が利用できるように、主要な操作（読み取り：メイン画面）中に位置情報を取得することです。
今、私は更新を登録し、onLocationChangedで場所が十分に正確であるかどうかをチェックします。そうである場合は、removesUpdatesを呼び出します。
問題：デバイスが正確な位置（または任意の位置）を取得できない場所にある場合、GPSが遮断されず、バッターが過熱し、ユーザーは非常に動揺します。
質問：GPSがロックに失敗していないかどうかを確認し、特定の時点で諦めるように指示するための良いクリーンな方法はありますか？スレッドタイマーを作成しましたが、リクエストはonPause / onResumeに関連付けられているため、すべてが絡まる可能性のある余分なスレッドを作成したくありません。
サービスを使用して、この機能をカプセル化します。その中から非同期タスクを実行します。
バインディングを使用して、必要に応じてアクティビティとの対話を処理できます
マーリンの答えに加えて（表示されたときにメモ帳でこのロットを入力していました）-同意します。私の提案は：
同様の問題に直面して、私は最善の方法は、サービスを使用してGPS全体をメインアクティビティから切り離すことであると判断しました。
これは、requestsLocationUpdates()とremoveLocationUpdates()を実行し、を実装するサービスがあることを意味しLocationListenerます。このサービスは、メインアクティビティがIBinderインターフェイスを使用して呼び出すことができるメソッドを提供します。また、BroadcastReceiverこれらのメッセージをリッスンするためにを実装するアクティビティにブロードキャストを送信します。
したがって、主なアクティビティで呼び出すことができるサービスメソッドの1つは、（たとえば）
mLocnServ.startGPS(int timeout, float requiredAccuracy, int minUpdatePeriod, int minResendDistance)
ここmLocnServで、はサービスによって公開されるバインダーインターフェイスです。
最後の2つの引数は、サービスのrequestLocationUpdatesに引数として渡す引数です。（個人的には、GPSが呼び出されるまで常に実行されていることがわかる限り、GPSがオフになったときにこれらが何の違いももたらさないと思いますremoveUpdates()）。とにかく、最初の引数（タイムアウト）は、必要な精度の修正を待つ準備ができている時間である必要があります（引数2）。
したがって、サービスでは、タイマーとしてRunnableが必要になります。タイマーがタイムアウトすると、タイプTIMED_OUT（たとえば）のブロードキャストを送信し、GPSを停止するためにremoveUpdatesを送信します。onLocationChangedで、必要な精度に対して取得した場所をテストできます。十分な場合は、タイプGOT_A_FIX（たとえば）のブロードキャストを送信し、その場所（緯度/経度と精度）をブロードキャストの追加情報として渡してから、removeUpdatesを使用してGPSを停止します。 。（TIMED_OUTおよびGOT_A_FIXは、ブロードキャストメッセージタイプを区別するために作成できる列挙型の単なる例の名前です）
主なアクティビティは、BroadcastReceiver onReceive（）で何を実行するか、つまり、TIMED_OUTブロードキャストを取得した場合に再試行するかどうか、またはメッセージから取得したデータをどのように処理するかを決定できGOT_A_FIXます。
mLocnServ.stopGPSサービスが何をしていてもGPSを閉じることができるように、おそらくバインダーにもが必要です。
GPSがロックを取得できないかどうかを確認するための良いクリーンな方法はありますか
はい、GPSが長時間修正を取得できない場合があります。私の経験から、これらは次のとおりです。
支援されたデータはありません。ご覧のとおり、電話のGPSチップセットにはいくつかの制約（バッテリー、速度など）があるため、修正へのラッチが遅くなります。GPSチップセットは衛星のスペクトルをスキャンする必要があり、それには時間がかかります。支援情報はインターネット経由で送信されます。これには、衛星の位置と周波数情報を含むアルマナックデータが含まれているため、GPS信号の検索時間が短縮されます。インターネットがないということは、GPSチップセットが修正を取得するのに2分以上かかることを意味します（これはスタンドアロンGPSと呼ばれます）。この時間は、チップセット、地形、天気などによって異なります。
（tldr：インターネットにアクセスできるかどうかを確認します。アクセスできない場合は、長いTTFFを期待する必要があります（最初の修正までの時間）
衛星の視程が低い：これは屋内の場合に発生します。GPSチップセットに支援データがある場合でも。屋内なので衛星が見えません。これは、衛星の信号対雑音比が低いか、可視衛星の数が4未満であることを意味します。理論的には2つの衛星で十分です。しかし実際には、適切な修正には少なくとも4つの衛星が必要であることがわかりました。
（tldr：NMEAリスナー/ GPSステータスリスナーを使用して、表示/使用されている衛星の数を確認します。修正には少なくとも4つの衛星を使用する必要があります）
ハードウェア/ソフトウェアの問題：これについては多くのことを行うことはできません。一部のGPSチップセットでは、GPSキャッシュデータを「リセット」するために追加情報を送信できます。巨大なTTFF時間やその他の異常なGPSパターンに注意し、タイムアウトメカニズムを使用します。
これは主にGPSの観点から書かれているので、あまり意味がない場合でもかまいません。
同様の問題がありました。すべてのアクティビティでGPS座標を取得できるようにしたかったのですが、GPSリスナーを使用してスーパークラスを実装したくありませんでした。同じアクティビティと呼ばれるインテントがある場合、GPSがスタックするという問題が発生することがありました。onPause中に無効にしたくありませんでした。
基本的に、GPSの更新を取得するサービスを作成し、サービスに接続/切断したリスナーの数を数えます。コールバック=0の場合、GPSを停止します。コールバック=1の場合、私はそれを開始します。
これはかなりうまく機能しているようで、アプリケーション全体でGPS更新を処理するための非常に確実な方法のようです。良い点は、onStopでコールバックの登録を解除すると、前のアクティビティからonStopが呼び出される前に、onStartが実際に最初に接続することです。これは私のGPSがビートを逃さないことを意味します。
（aidlを介して）サービスのコールバックを接続および実装するスーパークラスを実装しました。これにより、すべてのアクティビティクラスは、アクティビティに実装されているかのように情報にアクセスできます。