👠 👞 🍬 Badooジオロケーションテスト：バンプ、石、松葉杖、自撮り棒 🔝 🆒 🧘

モバイルアプリケーションのテストに関する資料は既に数千あるようですので、ここで驚くことはありません。しかし、UIのような側面はすでに穴で上書きされていますが、ジオロケーションテストはあまり一般的ではありません。そして、 ニコライのラママーであるコズロフとアレクサンダーz3us Khozya （ Badoo ）がハイゼンバグ会議で彼らの経験を共有したとき、聴衆は会議に非常に興味を持ちました。ジオロケーションを取得し、ユーザーの電話を拒否しないようにするにはどうすればよいですか？なぜこのテストで自撮り棒がスティックするのですか？ロンドンのパブはどれくらい近くにありますか？

Habrの視聴者も面白いかもしれないと判断し、ファンがビデオを見るためとファンがカットの下でテキストバージョンを読むための2つのバージョンで一度に投稿します。

エントリー

アレクサンダーホスティング ：

最初にあなたを知りましょう。私の名前はAlexander Khozyaです。会社の全員が「Khozya」という名前で呼んでいますが、私は慣れていますが、そのように連絡することもできます。私はBadooのすべての手動モバイルテストを担当しています。すべてのモバイルオペレーティングシステムが同じことを好まないので、今日はiOSについてお話します。

ニコライ・コズロフ：

私の会社名は「Kozya」です。私もそれに慣れています。特にAndroidオペレーティングシステムで、一般的にUnixライクなガジェットが大好きです。私はiOSが好きではありません。AppleWatchとiPhoneを持っているのは、彼らの優れたサービスとサービス品質をどれだけ嫌っているのかを理解するためだけです。

私たちについて少し。 Badooが新しい友達を見つけるためのサービスであることは、おそらく既にご存知でしょう。ユーザー数は3億6,000万人（うち月間6,000万人がアクティブ）、1日あたり約30万人の登録があります。 1日に3億5,000万のメッセージを生成します。

懸念事項として、直接報告書。貧弱なサーバーが処理しなければならないデータの量を理解するために、ユーザーは1日に約20億の座標を生成します。これらの20億は約1,000万の「交差点」を生成します-交差点とは何かについて少し後で説明します。

さらに、以下で説明するすべてのことは、テストユーザーのみが可能です。何らかの異常やバグをチェックする場合を除き、実際のユーザーのデータにアクセスすることはできません。この場合でも、このアクションに対するユーザー自身の許可が必要です。

それで、今日お話しすることは：

ジオロケーションが役立つ理由
7キログラムの神経細胞を保存できるツールについて（あなたからわかるように、それらはよく保存されます）
位置情報とその最適化を使用する場合のエネルギー消費について
現場で働き、そこに行く必要がある理由について
もちろん、テスト会議以来、バグについて話しましょう

ジオロケーションが役立つ理由

まず、ジオロケーションとは何であるか、何を使用しているか、そして最新のデバイスでどのように機能するかを思い出してみましょう。

歴史的には、2008年のバージョン2.0のリリースでiOSに登場し、その後、電話機は「IPによる計算」を学びました。問題は、Geo IPの精度が低いことです：せいぜい通りであり、モバイルデバイスの場合、通常は国です。IPアドレスはほとんどの場合浮動しているためです（各地域のオペレーターは独自のアドレス範囲を持っていますが、地理的に接続されていません）。

将来、エンジニアはいわゆるセルIDを使用することにしました。操作の原理は非常に簡単です。空間内の基点の位置を知っており、これらの点からの信号レベルを知っていれば、それらまでの距離をほぼ決定できます。次に、多数のラウンドを描画し、すべてのサークルの重複領域のどこかにユーザーがいます。精度はすでに向上しています。小さな都市では1000メートルであり、モスクワのような多くの基地局がある都市では60メートルです。 Wi-Fi、Bluetooth、およびその他のビーコンを使用する場合、精度を10メートルに上げることができます。これは非常に便利です。GNSSと呼ばれる次のシステムやグローバルナビゲーション衛星システムを使用する必要はありません。

「GPS」と言っていないのはなぜですか？ナビゲーションシステムの市場には複数のプレーヤーがいるためです。主なものは、GPS、GLONASS、中国の北斗、ヨーロッパのガリレオです。さらに、インドのIRNSSと日本のQZSS （「準天頂ナビゲーションシステム」）の2つの地域ナビゲーションシステムがあります。なぜそんなに多くのシステムがあるのですか？必要に応じて、すべてのデュアルユースシステムは、特定の場合に、オフにすることができます。また、インドと日本では常に計算する必要がある既知のGPS衛星オフセットがあるため、場所を明確にするためにいくつかのシステムが必要です。これは余分な頭痛です。日本人は精度が大好きで、QZSSの導入後、最悪の場合は10センチメートル、最良の場合は1センチメートルの精度で衛星を2つ作成するだけで十分です。

同時に、すべてのナビゲーションシステムの主な問題はコールドスタートです。工場からリリースされたばかりで、ジオロケーションを受信したことがないデバイスの場合、最初の起動では、A-GPSを使用しないコールドスタートは15分です。星空のアトラスを12分半ダウンロードし、さらに2分半後に出発します衛星からの信号を受信します。これは大きな問題であるため、A-GPSシステムを思い付きました。GeoIPとセルIDを使用して、電話機はおおよその位置をすばやく決定し、アトラスを送信する特別なサーバーに送信します。そして、2〜3分後（ほとんどの場合、さらに短い時間）、電話はすぐに衛星を見つけ、現在地を非常に便利に表示します。

では、ジオロケーションが一般的に必要な理由について話しましょう。まず、コンテンツをカスタマイズします。

製品がナビゲーションシステムであり、ジオロケーションを使用していない場合、ほとんどのユーザーはそれを使用しません。何らかの広告アプリケーションを作成している場合、パーソナライズも可能です：ある店を通り過ぎると、電話がこれを理解し、プッシュ通知がトリガーされます。この店では、現在50％の割引があります。デートでは、ジオロケーションも非常に重要です。私たちのユーザーは自分の街にいる人を見たいと思っていますが、できるだけ近くにいることが望ましいです。また、他の国のユーザーを表示したくない。ジオロケーションの助けを借りて、この問題や他の多くの問題を解決します。

交差点サービスのジオロケーションに関連するすべての改善点を開発しました。サーシャについては、少し後で説明します。私は、これがユーザー、ロジックの観点からどのように機能するかが明確であるとのみ言います。しかし、できるだけ少ない電力でできるだけ多くの座標とジオデータを取得する方法は完全に理解できませんでした。 2014年で、これをすべてクライアント側で実装する方法に関する多くの情報がありましたが、それをテストする方法に関する情報はまったくありませんでした。残念ながら、自分ですべてを見つけ、ドキュメントをゼロから作成する必要がありました。次に、位置情報を使用する場所と方法について説明します。

ホスティング：

最初のメイン画面は、ユーザーがお互いに投票するデートです。 Kolyaが前述したように、近くにいる人を見つけてコミュニケーションをとることは非常に興味深いため、ジオロケーションは、サーバーがユーザーを相互に発行する最も重要な重みの1つです。

次の画面には「近くの人」という言葉があります。最初のセクションでは、できるだけ近くにいる人が表示されます。もちろん、ジオロケーションサービスへのアクセスを許可してくれない限り。あなたがそれを与えなかったなら、我々はあなたに少なくとも都市に入るよう頼みます。ユーザープロファイルを開き、近くにいることを確認します。たとえば、Alenaは私たちから300メートルのところにいました。

同じ画面で交差点を表示しているだけです。今度はすべてがどのように機能するかを説明します。理論的にはそれほど難しいことではありません。特定の時点で移動し、特定の瞬間にあなたと他のユーザーの軌跡が交差するか、または可能な限り近く（20メートルなど）でした。 1人のユーザーとパスを交差させると、パーソナライズされたプッシュが生成されます。このユーザーと会話したかどうかを確認します。たとえば、あなたは彼が好きかチャットか、彼はあなたをお気に入りとして追加しましたなど。私たちはパーソナライズされたプッシュを送信し、プロファイルを開いて、特定の場所で交差していることを確認できます（ゲートウェイであなたに会いたい邪悪な大根を取り除くために）。すぐに3〜4人と交差した場合、「近くの人」画面に表示され、交差したユーザーには特別なチェックマークが付けられます。

チャットでジオロケーションを共有したり、リクエストしたりすることもできます。ユーザーがあなたに来たとしましょう。あなたはカフェにいて、ジオロケーションを送信して、とても便利です。

また、副産物の1つでは、位置情報がチェックインに使用されます。原則として、プラスまたはマイナスのSwarmですが、デートについてです。あなたが同じステーキハウスに行き、他の誰がステーキについて話をするのか不思議に思ったとしましょう。または、クラブに来てアプリケーションを起動したところ、クラブには現在24人の人がいることがわかります。データが示すように、共通の場所を見つけると、メッセージを受信する可能性が約40％増加します。また、スパム対策では位置情報を使用します。

Kozya：

まず、ユーザーが他のユーザーを三角測量するのを困難にします。さらに、地理位置情報を使用して、ユーザーが自分の位置を突然変更したことを判断できます。2つの場合があります。スパム対策が機能したか、ユーザーが別の国に移動して他のユーザーを困らせるか、ユーザーが別の国のハッカーのアカウントに乗っ取られたかのいずれかです。そのような場合には、対策を講じます。

さらに、交差点サービスのために、いわゆる「タクシードライバーモード」を開発しました。ナビゲーターをオンにして常に街中を移動する人々は、多くの正確なジオデータを生成します。多くの交差点があることは明らかです。これらのユーザーが馴染みを持たず、他のユーザーに迷惑をかけないように、交差点は、より厳しいフィルタリングを備えた特別なアルゴリズムによって生成されます。

ジオロケーションが優れている理由、およびそれを使用する場所について説明しましたが、別の問題、つまりジオデータ収集の問題について説明します。

ロケーションコレクション

これはタイムラインであり、アプリケーションが起動してから特定の精度でジオロケーションを受信するまでに時間がかかる場合があります。地理位置情報をより速く取得するには、バッテリーの観点から不経済なセンサー（気圧計、ジャイロスコープなど）を追加で使用する必要があります。ただし、デバイス上にあるすべての可能なセンサーを使用する場合でも、指定された座標の精度を取得する保証はありません。

Googleのドキュメントで、精度の定義を直接読んでみましょう：「精度とは、ユーザーが68％の確率でいる点の周りの半径です」。

または、簡単に言えば、68％の確率で、私たちは今ここのどこかにいます。

そして、そうではないかもしれません。ご覧のとおり、2つのポイントが来ており、それらの間の距離はそれらが与える精度よりもはるかに小さくなっています。また、そのようなジオデータを操作できる必要があります。

正確なジオデータの取得は時間に依存しますが、まったく取得されない可能性があるため、それを処理できる必要があります。早い段階で、オフィスを離れずにアセンブリをテストし、場所を送信する方法について話しましょう。システムが少なくとも何らかの方法でジオロケーションを受け入れる方法を知っていることを確認する必要がある場合。

これを行うには、利用可能な最も単純なツール、たとえばAndroidエミュレータを使用するのが妥当です。エミュレーションモードでは、ロケーションには、ロケーション自体のエミュレーションやGPXルートの読み込みなど、最も単純なものが含まれます。これについては、後でSashaが説明します。

Androidエミュレーターのデフォルトの場所がアイスランドのDalvikの村であることは興味深いです。 Dalvikは、バージョン5.0までのAndroidの仮想マシンです。

一方、iOSの場合、何らかの理由で、シミュレーターの方がはるかに豊富である理由を私自身は理解していません。

ホスティング：

はい、確かに。通常、アップルは非常にユーザーフレンドリーですが、エンジニアは巨大なポポールを持っています。ただし、この場合、Appleは私たちのことを考えて、ジョギング、サイクリング、高速道路でのライディングという3つの選択肢を用意しています。

システムは、座標自体、速度、動きベクトル、水平および垂直速度、場合によっては床に関する必要なすべてのデータをシステムに返すため、これは便利です。オフィスを離れずにジオロケーションをテストするのに非常に便利です。

ただし、アプリケーションをバックグラウンドに最小化すると、システムから座標がまったく送信されない場合があります。これは、Xcode、シミュレータ、またはmacOS自体のバグです。これを無効にするには、Xcodeまたはシミュレーターを強制終了する必要があります。いずれも解決しない場合は、再起動してください。しかし、シミュレータを起動してすべてがうまく機能し、いくつかの操作後に停止した場合、おそらくこれはまだアプリケーションのバグです。

次に使用するのは、お気に入りのXcode開発環境です。デバッガーをシミュレーターまたは実際のデバイスのいずれかに接続します（これは重要です。実際のiOSデバイスでジオロケーションをシミュレートできることを知っている人はほとんどいません）。青い矢印をクリックするか、メニューの[デバッグ]> [ロケーションのシミュレート]を選択し、 Appleの追加-モスクワ、ロンドンなどしかし、最下部にある[GPXファイルを職場に追加]ボタンを使用すると、GPXルートを追加できます。

生成するには、 Maps to GPX converterを使用することをお勧めします。入り口で、彼はGoogleマップから完全なURLと短縮URLの両方を追跡します。出力はGPXファイルを生成します。実際には、時間と空間内のポイントを含むXMLのサブセットにすぎず、システム自体がすべてを補間します。このGPXファイルは、Android、iOSおよびWindows Phone、GPSトラッカーなどと互換性があります。

実際、このツールはPokemon Goのブームの間に作成されたもので、そのおかげでテストが大幅に容易になりました。唯一のことは、このツールでGPXファイルを生成する場合、システムはiOSの移動速度を決定しないため、速度を知る必要がある場合は、シミュレータを使用することをお勧めします。

今、緑のバケツについて話しましょう。

Kozya：

エミュレータはiOSシミュレータほどリッチではないことに気付いたので、アプリケーションを制限なく配置できるという事実を利用しました。

私が使用することをお勧めする最初のアプリケーションはLockitoで、これは非常に便利で、実際にはAppleが持っているトラックのシミュレーションを置き換えます。ポイントは次のとおりです。アプリケーションを起動し、空間内のポイント、これらのポイント間の移動のタイプ（直線またはある種の輸送）を指定し、座標、速度などのパラメーターを指定します。シミュレーションを実行し、アプリケーションで宇宙空間をどのように移動するかを観察します。

2番目のアプリケーションはGPS Status＆Toolboxです。便利な機能：マルチウィンドウモードで実行し、小さなデバイスで、大きなデバイスで直接アプリケーションがどのように見えるかを確認できます。さて、デバイスのジオデータシステムが提供するもの、アプリケーションが受け取るものを示し、比較します。あなたの場所が実際の場所と一致しないときに何らかの異常ゾーンにいることに気付いた場合（たとえば、突然Vnukovoに移動した場合）、 GPS Testを使用してこれが起こった理由を理解できます。

Lockitoを使用するとき、アプリケーションで使用したジオデータソースを使用する問題を解決するライブラリを使用する場合、Location Mockを使用できる必要があることに注意してください。また、Androidですべてのジオデータソースをデフォルトで有効にしている場合、シミュレーションの時点に戻ってしまうことがよくあります。理由は何ですか：場所をエミュレートするアプリケーションはGPSサブシステムのみをエミュレートするため、設定ではGPSデータなどのデータソースを切り替える必要があります。

少しまとめてみましょう。Mapsto GPX Converterは非常に優れていることがわかりました。GPXファイルを異なるデバイスに同時にアップロードし、異なるオペレーティングシステムが同じルートを処理する方法を確認できます。残念ながら、iOSは残念ながらAndroidよりもリッチですが、Androidは環境に優しく、美しく、一般的に優れています！

これで、システムがデータを受信していることがわかりました。ここで、何かが何らかの形で機能していること、つまりビジネスロジックのテストを開始することを理解する必要があります。

ビジネスロジックテスト

まず、ビジネスロジックが大きすぎるという事実に直面し、すべてを念頭に置くことができませんでした。問題点：特定のロケーション処理システムを担当するファイル、機能、クラスが多数ありました。ジオデータ処理の間隔または座標を取得する間隔を短縮するには、すべてを探して変更し、アプリケーションを組み立てる必要があります。すべてを頭の中に保持できないため、何かを見逃す可能性があります。

これを行うために、便利な構成ファイルを作成しました。 iOSの設定ファイルの例を次に示します。ここでは、必要なデータをすべて変更し、お気に入りのXcodeでアプリケーションを構築して、使用を開始できます。

ホスティング：

, — , (, ), , . , . , . , , .

, , . , , . , . , , .

, , background, , foreground, UI .

, : GPS, - , , , API (, geofencing, visits API significant location change API iOS).

, : , , , , . , . , : , (, , , ), Wi-Fi ..

, , , .

-, , , 30 . - : -, . out of memory killer, , . - - API. , .

, , - : , -. , , . , , . , PHP-, , . , , -, , -:

, , . , , « », , . - , , . , , , ( /, , - ). , — , .

:

, , , , , … c :) , 7 . , , , — .

debug menu . Android . , GNSSLogger Google , , . , , , . , , , . , , ! , , - : , , , , .

iOS , iOS.

:

, , Android, . , iOS , ! , — location manager.

, , , - , . debug- , : , , . : , , .

Apple-, , , : , . , . , Visits API, iOS 8, . , , - . -, : «, , , - », , - . , , . , , , , 45 . «» : , , . API, , . iOS 7.

, , , , : foreground, — background, — visit.

, , . debug- , — .

:

, . , 2014 , , , , .

, . Power Meter. : , -, — , . , — .

. : , , , . .

, ( Android, ). , , , , Android . . , Power Meter , , . iOS .

« », , Heisenbug, . , , , , . , , , , Arduino, . , , !

. Android, .

, Android — , , . , . , , , , .

Android, : CPU foreground, background, (, GPS), ..

Google Play Services? Android : Android 8.0 Google Play Services «», . Google , « Google Play Services» : «, , , ». , .

, — Test Fairy, -sandbox, . -, , .

— , . 1-2 , , , , ( , , 3000+ ). , 22- , , . , , , .

, , — Battery Historian . Google, , «» , - . , , .

, , , , 3 . , , , : , . , developer infinite loop . .

, , . , , , .

, : , , , . , , , . iOS .

:

, iOS ( , Android), .

, : «» — «». , : , . , .

. , . , 5 , 55 , , . , , , , , , .

— Energy impact Xcode. , , : , , , , .

, : , CPU 100%, , , GPS , . : , CPU , GPS, , . , . .

— : «Settings — Developer — Instruments», . , .

, , , , - — . - , -, Android. , , . , 1/17 , 17 .

, , instruments . , , .

iOS, , - , . Android — Battery Historian, , .

:

, , , . , , - - , . , . Location Manager iOS , Apple , 100 .

. , , , . « »: , . , , , . «» Apple .

, , , iOS, Android. , , . , : , ( 1000 - ), . , , « » , , 15 (, , ). «, », .

, - . , , , , , , , . , , , , - , . , , , , unit-, .

, : 20 ( , ) . 20 — , :) 20 , , , .

Significant location change API. , GPS ( ), API, , . .

«», «significant»? , , , , , . , 750 , 750 . , . , , Apple .

, , Android. , , . -, , . : encounters ( ), - , . .

Visits API. , API iOS 7, .

Apple , - , , , . .

: . iOS 120 , NSurlsession , . , , , 30 . , - , , , , 5 . 120 , , , . , Wi-Fi, 3G:

Android.

:

Android Fused Location Provider . , , . GPS .

— . , iOS, Android . , , : - , , ., , , .

, . , , . , , « 100 », , . : , - , - . , , .

, , Fused Location Provider 90% . 9% Legacy Location Provider — , Android . , , Google Play Services, Google Play Services, , Xiaomi.

, Aggressive Location Provider. Legacy Location Provider, :

-, , Fused Location Provider (, , , ). - , .

. Google Play Services — , , «», , , — .

Aggressive Location Provider . , 20%, , Aggressive Location Provider . .

, Activity Recognition API Google Play Services — . 4 : , , ( ).

, , , still. , , - , , , . still , , still, . , , , . , - - .

, : , --, , , , still. , , , , , , still, , , , -. : - , , — .

だから、あなたはあなたの実験室の条件で持っているすべてのものを実行し、それが何らかの形で機能することを理解していますが、それはまだ真空中の球形の馬です。これを行うには、「フィールドに」行く必要があります。

「フィールドで」終了

Kozya：

そして、フィールドに出て行くために、あなたはあなたと一緒に持っていくものを理解する必要があります。 OSの異なるバージョン、Wi-Fiのオン/オフ、さまざまな省エネ設定、SIMカードの有無にかかわらず、実際のデバイスを使用する必要があります。 2種類のSIMカードで消費電力が異なる場合があることに注意してください。たとえば、4Gをサポートするものとそうでないものがあります。同じ周波数をサポートする2枚のSIMカードでも、ファームウェアが異なるため、消費電力が異なることがあります。 Sashaと私は、さまざまな関係者のVodafone SIMカードを使用してこれに出会いました。

次に、ユーザーを理解する必要があります。ユーザーのバグを見つけるためには、ユーザーのようになる必要があり、ユーザーとして行動し、ユーザーが行うことを行う必要があるためです。アプリケーションのユーザーになるために、結局、誰もドッグフーディングをキャンセルしませんでした。そして、これが私たちがしたことです。

ホスティング：

まず、オフィスを出て近所を少し散歩することにしました。なぜそんなに便利なのですか？はい。建物の密度、Wi-Fiネットワーク、セルラーネットワークの密度が異なるため、場所を特定する精度が非常に高くなるためです。ロンドンは非常に不均一です。

また、「不規則な」歩行ペースにより、送信間隔を確認できます。あなたは同じ速度で歩いていません。あなたの前の誰かがくすんだり、誰かを追い越したり、横断歩道に立ったり、地下通路に降りたりしました。具体的には、この場合、バグを見つけることさえできました。座標の束の形成中に、座標が送信前に受信された場合、座標は送信用のパックとキャッシュの両方に追加されました。したがって、まれに、これらの座標を複製しました。正直に言って、偶然に再現されましたが、このケースは興味深いものです。

iOSで「訪問」をテストすることも非常に便利です。 2つの意味変化ポイント間の距離は750メートルであり、プラスまたはマイナス5分後に「訪問」が遅れて送信されることを思い出させてください。便利な理由：ロンドン中心部のパブ間の距離は、これらの750メートルよりもはるかに短いです。

したがって、あなたはパブに行き、ピントチカを飲んで、外に出て、5分で次のパブに着きます、そして何かが起こるかもしれません。具体的には、iOSの場合、前の機関の出口か、次の機関の入口を噛みました（時間的に非常に近いことが判明した場合）。全体をSwiftに書き直すことで、静的アナライザーがより良く機能し、間違った定数を使用し、式が常にfalseであると判断できるようになりました。

一般的に、テストは簡単で快適です。ピントを飲み（通常はヤギとピントを飲みました）、交差し、プッシュし、開きます。場所が正しい場合、および/またはすでにテストされている場合は、家に帰らなければなりません。

また、あらゆる種類の機関に行くことで、訓練システム全体を破壊する潜在的なバグを見つけることができました。ロンドンでは、パブに加えて、平方メートルあたりのあらゆる種類の施設がたくさんあります。 100〜200平方メートルのエリアに4〜5のカフェがあります。そして私達との正確さは通常10-30メートルです。したがって、特定のカフェにいると判断するのは非常に困難です。そして、私たちは非常に非自明に行動しています：カフェに行き、エントリイベントを取得し、接続されたWi-FiポイントとそのMACアドレス（もちろん、ある場合）を取得し、サーバーに送信します。つまり、ユーザーが絶えずこのポイントにアクセスする場合、ユーザーは同じWi-Fiを使用しているため、高い確率でこの場所にいることになります。

しかし、判明したように、ロンドンにはまだオープンWi-Fiネットワークがあり、3分で次の機関に行き、すでにそこにいて、再びアクセスポイントを取得してサーバーに送信できます。それだけでなく、サーバーは、エントリーイベントとエグジットイベント用の2つの異なるWi-Fiネットワークを持っているという事実に驚いていましたが、物理的にそれらの間の距離は300-400メートルにもなります。歩く速さに応じて、これを考慮に入れる必要があるため、自発的な決定により、出口イベントへのアクセスポイントの名前の入力を無効にしました。

その後、公共交通機関に乗ることにしました。ロンドンの中心部は非常に混雑しており、バスは平均速度が低いため、最初に行うのはバスです。また、動きの性質の決定を確認し、そらすことができました：あなたが行く、行くなど。そのような定義は確率です。つまり、条件付きでバスに乗る場合、90％の確率でバスに乗ると決定され、10％の確率で、たとえば自転車に乗ることになります。場合によっては、対応するウェイトを締める必要があります。

また、バスに乗っている間に、面白いサーバーのバグを見つけました。横断歩道や信号で止まると、場所を見つけることがあります。サーバーは、次の場所を取得する方法と、以前に速度を落としたものを認識できなかったため、バス停に最も近い施設で私たちをチェックしようとしました。この問題は単純に解決しました。速度定義（メートル/秒）を追加しました。速度がゼロでない場合、この機関で確認する必要はありません。

それから、ロンドン地下鉄に行くことにしました。非常に古く、セルラーネットワークがなく、GPSを捕捉しないため、Wi-Fiを使用して場所を特定するのが最も簡単です。車に乗り、次の駅に行き、Wi-Fiが自動的に接続され、場所が特定され、非常に便利で便利です。

それから、車とタクシーを運転することにしました。これが便利な理由：高速で移動していて、ナビゲータがオンになっていない場合、オペレーティングシステムは電力消費を調整しようとしています。したがって、20-30 km / hの速度で運転する場合、これはバックグラウンドで750メートルであり、110 km / hを運転する場合はすでに2-4 kmであり、高速列車で空港に旅行している場合（ロンドンで約250 km移動します/ h）セルタワーがあまりない場合、高速移動するGPSオブジェクトを修正するのが難しく、列車には多くの金属が含まれているため、タワーの密度に応じてすでに4〜11 kmになります。これは測位の精度に寄与しません。

また、移動速度に応じて、Geofencing APIを使用する場合は、半径を正しく設定する必要があります。ジオフェンシングは非常に簡単に機能します。ポイントに移動し、半径を設定し、そこから抜け出すためのアクションを実行します（たとえば、座標の束を送信します）。または、逆に、特定の場所に行きます。マクドナルドに行って、彼らがあなたを特定し、「今日のハンバーガーはあなたにとって2倍安い」というプッシュを送信するとします。高速で移動している場合は、より大きな半径を設定する必要があります。そうしないと、バッテリーを着陸させたり、この半径を離れることがよくあります。逆に、座標の精度がそれを超える場合は、離れることはありません。

Kozya：

さらに、Android 7以降では別のジョークが発生する場合があります。電話があり、車に乗り、助手席に乗せて、ポイントAからポイントBに行きます。到着したので、電話が受信した場所の数を確認したいのですが、そうではありません。この理由は何ですか？ Googleはユーザーにとっては良いこと、開発者にとっては悪いことをすることを決定し、いわゆる居眠り、スリープモードを導入しました。それだけでなく、携帯電話が使用されていないときは「スリープ」するため、Android 7.1のバージョンではGoogleが積極的な居眠りを追加しました。なぜ悪いのか：あなたの電話は状況をより速く分析し始め、助手席でそれを投げてポイントBに行った場合にそれが需要がないことを理解し、結果として座標を受け取りません。ドキュメントを読んだ後、黒い羊から房の毛まで、少なくとも1時間に4回は座標を取得できることがわかりました。

私たちの馬はもはや球形ではなく、本物であることに気付きました。最悪について話しましょう。

フィールド出力の裏側

Kozya：

最初の恐ろしいことは、デバイスが破損して落下する可能性があるため、フィールドを出る前に適切なカバーを用意することです。

2つ目は回帰です。

ホスティング：

主な機能であるバグ修正を確認した後、最初に尋ねるのは、収集および送信された座標を見逃したかどうかです。キャップは、2つのデバイスを取り、それらに異なるアセンブリを配置し、それらと一緒に散歩し、座標を比較する必要があることを示唆しています。しかし、どんなに。 Kolyaは、消費電力の異なるSIMカードについて話をしていましたが、デバイスを同じ状態にするのが非常に難しいことを証明する別の興味深い方法に出会いました。

右側のポケットに1つのテストデバイスがあり、バックパックにもう1つのテストデバイスがありました。バックポケットに入れるのは危険なので、彼らはそれを引き出すことができます。結局のところ、歩いていると、ポケットに入っていたデバイスがより動き、目を覚まし、より多くの座標を収集します。仕事に着くと、バックパックに入っていたデバイスがそれらを収集するのが1.5倍少なく、アプリケーションのさまざまなビルドがこれとは何の関係もないことがわかりました。したがって、デバイスを最も類似した状態に配置してください。

また、最新のデバイスには大量のRAMがあるため、バックグラウンドで長期的なサービスチェックを行うことをお勧めします。たとえば、OnePlus 5〜6ギガバイトと8ギガバイトのRAMの変更があります。この場合、アプリケーションは非常に長く存続し、存続する場合は正常に動作します。通常、夜間または週末は、アプリケーションをデバッガーに接続したまま、動作のシミュレーションモードのままにします。

しかし、この機能のリリース中にモスクワからロンドンまで車を運転しなければならなかったとき、Kolyaはテストで最も助けてくれました。私たちは彼にいくつかのテストデバイスの箱を渡しました。2日間と3000キロメートルで膨大な量の座標を収集し、機能をオフにしたユーザー（自分自身を含む）と交差し、ギガバイトのログを収集して、バグを見つけました。起動前に修正されました。

バグについて話しましょう、結局のところ、テスト会議があります。

Kozya：

この機能のリリース後、過去と未来から座標を受け取り始めました。問題の原因：ユーザーは移動し、タイムゾーンを超えたり、初期座標が取得されたタイムスタンプに関して過去と未来に移動したりする可能性があります。

タイムゾーンを超えたときにタイムスタンプを決定する際のデバイスのバグとファームウェアに加えて、同様のエラーは他のバグが原因であることが判明していますが、これは簡単に解決できます。デバイスには常にゼロより大きい時間があります。これは、起動後の稼働時間です。座標を取得するときに追加し、この座標のパックをサーバーに送信する必要がある場合にのみ、稼働時間とともに送信します。原則として、これでほとんどの問題が解決します。

2番目の問題は、テレポートを開始する人々です。前述のこと（ユーザーが他のユーザーを煩わせるために座標を急激に変更するか、アカウントを乗っ取る）に加えて、非常に現実的なユーザーも宇宙にテレポートし始めます。これに関連するもの：まず第一に、座標を指定するとき、ポイントは歩くことができるという事実。座標の精密化と中心の変位は、非常に高速で発生する可能性があります。そして、ユーザーの移動の最大可能速度を乗客ライナーの速度に制限しましたが、これまでのところ非現実的です。これにより、いくつかの興味深い例外を除き、99.9％の問題が解決しました。

ホスティング：

GPSがキャッチされない、またはオフになっている場合、位置はWi-Fiまたはベースステーションから取得されます。少なくとも2つのエラーが発生しました。 1つ目は、Badooがそれぞれ非常に厚い壁と天井のある美しいカントリーハウスで10年を祝ったとき、GPSを捕捉できませんでした。私たちの勇敢な管理者は、ロンドンオフィスからアクセスポイントを傷つけました。マップアプリケーションとアプリケーションを起動すると、ロンドンオフィスにいることがわかりました。幸いなことに、最新のアクセスポイントは、数分から数日までかなり迅速に場所を更新できます。数時間でこのすべてが修正されます。

そして、モスクワに住んでいる人々は、より人気のある物語を知っています。クレムリンに近づくと、ヴヌーコボに「テレポート」できます。これは私たちにも起こりました。グーグルでは、GPS / GLONASS座標を置き換え、VnukovoでセルID座標を設定していることがわかりました。 Yandex.Taxiの人たちは、そこから人を連れてくるか拾うために、ハックをしなければなりませんでした。

また、一部のユーザーは中国とブラジルにテレポートしました。判明したように、主にBlackberryデバイスからブラジルにテレポートされました。GPSサブシステムに何かが発生すると、ブラジルのデバイスのアセンブリサイトにテレポートされたことがわかりました。そして、中国の携帯電話は中国に移動していました。

また、iOS上のいくつかのデバイスを2つのポイントの間に投げました。メモリが提供される場合、iOS 9.2より前の非常に厄介なバグがありました。バックグラウンドで位置を受信すると、10〜15ミリ秒の差があるシステムは、たとえば6〜8時間前に受信した非常に古い位置を抑制しました。あなたは前進し、その後ジャンプして戻り、そして前進します。このために、クライアントとサーバー上の松葉杖の両方で、古くなった座標のフィルタリングを作成する必要がありましたが、クライアントでこれを行うことが常に可能とは限りません。サーバーはこのすべてをスムーズにします。

私が個人的に大量の血を飲んだ最後のバグ：実際のデバイスでジオロケーションのふりをして、その時点でXcodeが「悪くなった」場合、またはデバッグセッション中にコードを抜いた場合、デバイスは最後の既知のジオロケーションでフリーズします。私の状況の面白いところは、家に帰る前に私たちのオフィスの正確な座標をシミュレートし、このデバイスを家に持ち帰って戻ってきて、一度も座標を受け取っていないことに驚いたことでした。私と開発者。

私たちは皆、私たちが望んでいたことを話しました、要約しましょう。

おわりに

Kozya：

最初に気づいたのは、IDE、ログ、追加アプリケーションなどの優れたツールがなければ、ジオロケーションサービスをテストすると、実際のメリットよりも多くの情報ノイズが発生することです。

ジオサービスをテストするときにフィールドを終了する必要があることは明らかですが、問題はフィールドに出ても、すべてのバグを見つけることができないことです。落とし穴の一部のみを説明しましたが、その方法に応じて、さらに多くの可能性があるか、まったくない可能性があります。

あなたによって発見されたすべてのバグは、何らかの方法で分類し、メモすることが望ましいです。これらは、Vnukovoへの転送の場合のように、機能のバグ、APIのバグ、デバイス自体のバグ、または位置情報である可能性があります。これらのバグは念頭に置いておく必要があります。もし見つかった場合は、すぐに言ってください。これは「ジオロケーション」クラスのバグであり、意味をなさないため修正しません。

テスターは、ユーザーとビジネスの間のリンクです。ビジネスが私たちに多くの座標を持つことを望んでいることは明らかであり、ユーザーはバッテリーが急激に消耗することを本当に嫌います。このため、エネルギー消費をできるだけ早く測定することを検討する必要があります。しかし同時に、テストと開発がより困難になるため、開発の非常に早い段階で再最適化しないことが重要です。

そして、この会議で今日私たちができる最も重要な結論：CISのパブの密度はロンドンのパブの密度よりもはるかに低く、急にジオロケーションサービスを正確にテストする必要がある場合は、光景を歩き、私たちのところに来てください。お手伝いします。よろしくお願いします！

関連リンク：

広告の分。 ハイゼンバグ会議のこのレポートが気に入った場合、新しいハイゼンバグ（5月17〜18日、サンクトペテルブルク）がすでに近づいていることに注意してください。たくさんの皆様にお会いできることを楽しみにしています！

Badooジオロケーションテスト：バンプ、石、松葉杖、自撮り棒