Mission Impossible：バッテリーを消耗しないAndroidのジオロケーション

ユーザー：これは不可能です。GPSはバッテリーを消費します

ジュニア：可能です、ジオフェンスを使用します

シニア：より良いオプションがあります

写真では、最初は1人、次に1人が同時に他の方向に、6台の同じ電話が「歩いた」。 しかし、なんと違う結果でしょう！



ジオロケーションはさまざまなタスクで使用されます。 ユーザーの座標がそれ自体では面白くない場合の一般的なシナリオを考えてみましょうが、ユーザーが特定の地理的半径に入ったときを知ることは非常に重要です。 店舗リストやジオゲームからロジスティクスやセキュリティまで、それが必要とされるアプリケーションの範囲は非常に広いです。



私たちの場合、このシナリオは3つの完全に相互に排他的なものによって複雑になっています。

1. 小さな半径。 ユーザーが地形のかなり小さな半径-500メートルを入力したという事実を判断する必要があります。
2. 高い確率。 必要なのは、ユーザーが半径を滑らない非常にゼロでない確率です。 現在、「交通量のない」時間帯があり、車を運転していることを考えると、すべてがかなり悲しくなります。
3. 低消費電力。 どんなアプリケーションにとっても重要なポイントですが、最悪なのは、アプリケーションではなく、他のアプリケーションに組み込むべきSDKを開発していることです。 他の開発者は私たちを信頼しており、最初に問題が発生する場合は、ユーザーの影響を受けたり削除されたりするのはアプリケーションです。 したがって、エネルギー要件が最も高くなります。

一般に、スクリプト自体は、もちろん、技術的な観点から見ると怪物です。 確かに、ほとんどのアプリケーションでは、ジオロケーションは短時間使用され（現在の場所を確認し、exifで写真の場所を保存します）、多くの電力消費を必要としません。 ここでは、多くの場合、バックグラウンドでハングアップする必要があります（親アプリケーションの開発者が望む場合）。そのため、場所の使用に関する通常のGoogleの推奨事項は本質的に役に立ちません。

だから問題があります。 しかし、解決策はありますか？

この資料は、引き裂かれた考えや実際の使用に耐えられなかった特定の一連の実験ではなく、得られたデータに基づいて実装され、実際に使用されている技術に関するものであることに注意してください。



「time-price-development resources」という式のように、2つのパラメーターのみを削減できるため、何かを節約する必要があります。 原則として、500メートルが一定であるため、半径への進入を決定する確率の1.0から少し下がってください。





GPSが有効になっていない場合、ユーザーが赤い半径を通過するタイミングを確認します。 ほんと？



最初に、基本的に3つの基本的なオプションがあります-Geofencesを使用するGoogleのボックスソリューション、独自のアルゴリズムでGoogleサービスの組み込みAndroidを使用する、または独自のアルゴリズムでオープンgeo-APIを使用する

明らかに、戦闘に近い条件ですべてを実行する必要があります。 また、かなりの時間コストが依然として必要なので、同時に特定の限界オプションをテストします。

生存者

1. Googleサービスパッシブモード -他のアプリケーションからGEOデータへのシステムキャッシュコールのみを受信します。 ネットワークロケーションコール-パッシブモードとアクティブモードのWi-Fi、セルタワーの監視、またはGPSの使用のいずれかです。

2. Googleサービス GPS-古き良きオールデバッシングGPS

3. Mylnikov Provider - mylnikovの Wi-FiネットワークでのオープンAPIを使用した実装（多くの相談と有用な記事に感謝します）。 Wi-Fi経由で複数のジオベースから集約されたベースで動作するAPIを使用します 。 Wi-Fiネットワークのリストを直接使用するため、ACCESS_FINE_LOCATIONおよびACCESS_COARSE_LOCATION権限（ACCESS_WIFI_STATEのみで十分です）の使用を避けたい場合は特に興味深いです。 Android 6.0の場合、これはもはやあまり重要ではないため、ネットワークスキャンにはACCESS_COARSE_LOCATIONも必要になりました。

4. Googleサービスジオフェンス -ユーザーが半径内にいるかどうかを判断するためのGoogleの実装を閉じています 。 アプリケーションが対応するイベントをキャッチする場所に入ると、地理的領域を決定できます。 明らかなマイナス-半径を100だけにすることができますが、タスクによっては十分ではなく、埋め込み（または「反転」）半径のプログラミングが必要になる場合があります。 ほとんどのデバイスでは、ネットワークロケーション（Wi-Fi +セルタワー）のみを使用します。

5. Googleサービス結合モード -Googleサービスパッシブモードのバランスの取れた動作モード+ Wi-Fiおよびセルタワーの座標の強制要求。キャッシュされたデータの関連性がもはや私たちに合わない場合。

6. i402-402ターゲティングRusの実装：Googleサービス結合モード+ユーザーの最も近い半径からの距離に応じてスキャン頻度（1分から24時間）を調整する適応モード

調整する

テストには、7つの同一の電話モデルのセットが必要です。 追加のソフトウェアをインストールせずに、すべての電話が新品になります。 Googleサービスパッシブモードのより現実的なテストでは、逆に追加のソフトウェアをインストールするのが正しいでしょうが、これは予測できない干渉をもたらし、テストを非常に複雑にします。

各サイクルとキャリブレーション、およびテストは、電話機をフル充電することから始まります。 すべての測定は、+ 15以上の温度で行われます。

キャリブレーションには1週間かかります。これにより、すべての電話機のバッテリーが「揺れ」て、安定した状態になったという確信を得ることができます。

キャリブレーションプロセスは2段階で実行されます。

ステージ番号1

1.すべてのインスタンスの設定とソフトウェアは同じ状態になり、電話は充電されて同じ状態になります。

2. 24時間待機します。

3.残留電荷のデータを削除します。



ステージ番号2

1.すべてのインスタンスの設定とソフトウェアは同じ状態になり、電話は充電されて同じ状態になります。

2.すべての電話には、1人の携帯電話会社のSIMカードがあります。

3. 24時間待機します。

4.残留電荷のデータを削除します。



すべてのコピーで5サイクルで実行される、ステージ番号1と2の合計。

結果によると、異常な電力消費の電話が検出され、テストの制限から除外されます。



デバイスの操作を支援するのは、チームリーダーの1人が、プッシュボタン式の携帯電話とスマートフォンとiPhoneの両方でクラッシュテストが行​​われた、攻撃的かつ技術的な詳細プロジェクトに参加した経験が一度にあったという事実です。 そこで、彼らはスマートフォンのエネルギー効率の測定も行いました-極端な温度ではありますが。

2日間で6つのアプリケーション

すぐに生き始める小さなものを書くのはいつもいいことです。 ジオデータを収集するためのさまざまなアルゴリズムを使用して、1つの単純なAndroidアプリケーションの6つのアセンブリを準備しました。 各アセンブリには、アルゴリズムのバリアントの実装、開始/停止ボタン、完全なステップごとのログ記録、およびインスタンスとアセンブリの状態のインジケータが含まれます。

インジケータは、1分に1回の短いビープ音で、基本的にはきしみ音です。 このため、試験片で満たされたテストバッグからは奇妙な音が絶えず鳴ります。 幸いなことに、私たちの困難で危険な時間のために、通りや交通機関の音は私たちの周りの人々のために私たちの病棟の絶え間ないきしみ音から完全に消えてしまいました。 同時に、きしみ音は、デバッグの初期段階でアセンブリがハングしているかどうかを理解するのに役立ち、特定のインスタンスでバッテリーがまだ切れているかどうか、およびシステムが特定のアプリケーションを安楽死させることを決定したかどうかを判断するのに役立ちます。 結局のところ、テストを実行する際に状況を明確にするための貪欲な画面を含めることは許されない贅沢であり、大きなヒントです。



＃4および＃5を除くすべてのアセンブリは、10分ごとに座標を要求します。 一方では、これは大きな仮定です。輸送のユーザーは500メートルの半径を短時間で簡単に横断できるからです。 一方で、将来が確認するように、10分に1回チェックするだけでも、「限界」の中で壊滅的なエネルギー消費につながり、すべての希望はもっぱらスマートアルゴリズムになります。

テストダンス！

キットの各インスタンスには、テストアプリケーションの独自のアセンブリがあります。 キットの1つのコピーがコントロールグループに含まれているため、プラセボが必要です。 つまり、何もインストールされていません。



すべてのインスタンスの入力データは引き続き共通です。共通のモバイルオペレーター、共通のルート、テスターの共通のぼろきれ。 ラグは、受信信号との干渉の可能性がないように特に選択されています。



ルートは、都市部と市外の両方の異なるレリーフに構築されています。 車、交通機関、地下鉄、ハイキングルートのルートがあります。 定義上、Wi-Fiのない地形上のルートもあり、ラドガ湖の湖remoteから遠く離れた場所にあるセルラー通信もあります。





このサイクルで最も難しかったのは、嵐の間にテスターのバッグをownれさせないことでした。

結果は？

フィールド調査には2週間以上かかります。 各アルゴリズムの出力は、2つのパラメーターに関して評価されます。



精度-標準と比較した5段階の専門家による評価（より良い）。



エネルギー効率-テストサイクル完了後のデバイスのバッテリー充電の割合は、0（サイクル内のキットインスタンスからの最低レベルの充電）から10（サイクル内のキットインスタンスからの最高レベル）までの一般的な10ポイントスケール（高いほど良い）に削減されます。



以下は、パラメーターの平均値です。 テストの再現性により平均値に近いため、中央値は与えられません。

1. Googleサービスのパッシブモード

精度：3.4（4位）

ENERGOEFF。：4.3（5位）



中程度の精度。 ルートの一般的なパスを定義できます。 エネルギー効率の面では、最後から2番目ですが、最後の参加者であるGPS（4.3対2.1）よりもはるかに先です。 精度は、スマートフォンにサードパーティのソフトウェアがあるかどうか、またはシステムをキャッシュするものがほとんどないかどうかに大きく依存します。 2番目の場合-システムは、独自の定期的なシステム要求のみをキャッシュできます。 善良な企業が、 私たちがとるすべてのステップを維持していることを覚えていますか？

残念ながら、ほとんどの場合、作業明細書に独自のプログラムを登録することは不可能です。「電話にはさまざまなプログラムがあり、多くの場合ジオデータにアクセスするという計算を行います」。

2. GoogleサービスGPS

精度：4.6（2位）

ENERGOEFF。：2.1（6位）



予測可能なほど優れた精度（メトロを除く）を示しますが、予測可能なコストもかかります。すべてのテストで最悪のエネルギー効率を示しました。

3. Mylnikov Provider（Wi-Fiのみ）

精度：2.2（6位）

ENERGOEFF。：6.2（3位）



精度が低いのは、Wi-Fiネットワークがない市内外のルートが利用できるためです。 同時に、セルタワーにAPIを使用すると、高い精度と低消費電力を示すことができます。

4. Googleサービスジオフェンス

精度：5.0（1位）

ENERGOEFF。：6.8（2位）



半径500メートルのフェンスの定性的決定の安定した統計。 小さなフェンスでのテストは実施されなかったことを警告する価値があります。 外国の同僚のいくつかの実験、およびドキュメント自体から判断すると、150未満のフェンスでは、精度に問題があるか、エネルギー消費量が大幅に増加する可能性があります。

しかし、500メートルであっても、これがシステム機能であることを考慮すると、消費電力は低くなる可能性があります。

5. Googleサービス結合モード

精度：3.6（3位）

ENERGOEFF。：5.5（4位）



リファレンスGPSに関するエラーがありましたが、全体的に安定しています。 より良いエネルギー消費をお願いします。

6.i402

精度：3.1（5位）

ENERGOEFF。：8.5（1位）



半径から遠く離れた場所では検査の頻度が低下したため、半径の場所から遠く離れた領域では、予想どおりに不十分な近似が示されました。 同時に、エネルギー効率の面で競合他社を上回り、2つの長期テスト（1日以上）により、最も近い競合他社からのバッテリ充電の5〜7％以上の節約が示されました。 半径へのエントリをチェックする-基本的な問題を解決するとき、ほとんどの場合、歩いている人と十分な確率で旅行している人をキャッチします。

合計

精度とエネルギー効率の組み合わせにおける最初の場所は、まだGoogleサービスジオフェンスでした。 しかし、彼らがエネルギー効率で賞を受賞したとしても、彼らが私たちが必要とするシナリオに基づいて2位になったことは受け入れられません。 すぐに使用できるソリューションは標準シナリオにのみ役立ちます。これは、高度なオプションの場合、要件の微妙な違いやアプリケーションの詳細を考慮できるのは自分だけだからです。

さらに、参加者のペロトンが基礎として位置付けられました。エネルギー効率により、GPSははるかに遅れ、十分な精度が確保されました。 注意-参加者の1人は原則としてGPS（Mylnikov Provider）のドーピングを拒否し、他の4人はGPS自体をカウントせず、他のアプリケーションがスマートフォンで高精度の座標を必要とする場合にのみデータを使用します。

GPS、さようなら？

さまざまなオプションのテストおよびテスト中に、単純なアイデアが確認されました-都市の位置の許容可能な精度を決定するためにGPSは必要ありません。 いずれにせよ、100万以上の都市について話している場合で、ユーザーが主に住宅から離れた荒れ地でアプリケーションを使用していない場合。



携帯電話の設定でGPSを無効にして、Yandex.Mapsを開いてみてください-彼らはあなたの位置を非常に正確に決定します。 さらに、Wi-Fiがオフになっている場合でも-設定でWi-Fiネットワークスキャンが無効になっていない場合のみ（Android 4.3以降に表示されます）。 ただし、ほとんどのユーザーにとっては有効になっています。

Googleマップを開く-あなたの場所はさらに正確に決定されます。 ある種のWi-Fiネットワークトラッカーを使用して、街を歩き回ったりドライブしたりします。スマートフォンは何千ものWi-Fiネットワークをキャッチします。





彼らは、コマーシャルディレクターにWi-Fiネットワークトラッカーを1日間置くように依頼しました。



ソースの品質（Googleまたはオープンベース）と都市の地形に応じて、Wi-Fiの精度は約30〜50メートルです。 これは、市内の精度が300〜400メートル以下のセルラーネットワークよりも1桁優れていることに同意します。

ほとんどのアプリケーションでは、30〜50メートルの精度で十分であるため、すべての消去GPSをヤンクする必要はまったくありません。 長時間にわたるテストの結果によると、チャージの15％がGPSインスタンスに残っていた場合、最高の対戦相手はチャージの57％を持っていました-違いを感じてください！

それで解決策は何ですか？

具体的には、i402は産業実装に選ばれました-現在、第3世代モバイル広告ネットワークの1つで使用されています（ Habr：Advertising networks 3.0 ）。

i402は、次の組み合わせです。

• 他のアプリケーション（他のアプリケーションに含まれている場合はGPSデータを含む）からGEOデータへのシステムキャッシュコールの受信
• キャッシュされたデータが古い場合、Wi-Fiやセルタワーを介した座標の明示的な要求
• 最も近い半径からのユーザーの距離に応じた明示的なリクエストの浮動周波数

標準的な使用では、i402実装を含み、サービスモードで継続的に動作する組み込みSDKを備えたアプリケーションは、1日あたりのバッテリー充電の5％以内で消費されます。

適応性とインテリジェンスを実装するには、メトロの「テレポート」や空港の「テレポート」との戦いなど、他の多くの興味深い問題を解決しなければなりませんでした）そして、たとえば、安静時の座標の実現期間の値の要因を考え出します。 また、大食いセンサーの助けを借りずに、人が歩いているのか、交通機関に乗っているのか、車に乗っているのかを判断する方法も学びます。 しかし、これについて-別の資料で。