新しいカードに古いカード

約4か月前に、マップを少し更新することにしました。 これは、ユーザーに多くの注意を払うセクションの1つであると思われます。

これは4か月前に起こりましたが、今日だけ、私たちEugene johnny_palec EmelyanovとAnton kashey Korzunovは、 gdeetotdom.ruポータルの「On the Map」サービスの作成の話をしたいと思います。 ある意味で私たちは先駆者であり、ある意味では追いつきましたが、いずれにせよ多くの熊手が集められ、最終的にはその種のユニークなサービスを得ました（私たちはそれを誇りに思っていることはあまり目立ちませんか？）

調査、間違い、発見をウェブ開発者のコ​​ミュニティと共有したい しかし、まず最初に。

私たちは私たちのものであり、新しい世界を築きます

長い間、私たちのポータルには膨大な量の視覚的コンテンツがありました-家の写真、中庭のパノラマ写真、都市の球形撮影。 さらに、建物、レイアウト、インフラストラクチャエリアに関する詳細情報があります。 しかし、このコンテンツはポータル全体に拡散し、多くの場合、不動産を見つけるための補助ツールとして機能するのではなく、娯楽をもたらしました。 私たちの仕事は、情報と視覚コンテンツを組み合わせるだけでなく、新しいサービスを不動産の検索、分析、選択のための独立したツールにすることでもありました。

インターフェースと使いやすさ

地図上の富をレイヤーの形で組み合わせ、当時のサービス「Where Is This House」の受信者を作成することにしました。このサービスでは、地図に家、インフラストラクチャ、球形パノラマの写真が表示されました。 さらに、ビジュアルコンテンツが表示されるコンテキストで、データベースからの不動産広告を追加する必要がありました。 インターフェイスの研究は、2つのプロトタイプのモックアップで簡単に説明できます。バランを使用した古典的なアプローチと、オブジェクトに関する情報が別のブロックに表示されるオプションです。 その結果、古典的なアプローチに落ち着きましたが、小さなバランに大量の情報を配置するという問題を解決する必要がありました-決定したとおり、作業バージョンで確認できます。

これを読んだ後、あなたが（もう一度）あなたの生息地を売買するためだけに私たちを訪れる価値があると思ったら、私たちはあなたを失望させることができます-マップ上の新しいサービスはあなたが家の近くに新しいカフェを見つけて計画するのに役立ちます（バイカーの別の集会（ ナイトオオカミ ）。

Google + Yandex =相互に有益な協力

実際、相互に有益な操作:)オブジェクトはロシア全土に表示する必要があり、GoogleとYandexのマップのカバレッジと品質は異なるため、両方のAPIを使用することにしました。デフォルトでは、手動で変更できるこの地域により適したマップを表示します。 また、何らかの理由で、選択したマップのAPIがユーザーに対してデフォルトでロードされない場合、2番目のオプションが自動的にロードされます。

確かに、なぜこれが必要なのかは完全には理解されていませんが、一部の人々がgoogle.comをブロックしている一方で、他のYandexは何らかの理由で機能しているという事実は残っています。

以下で説明するAPIの基本原則に従って、カードの作業バージョンへの切り替えが自動的に行われます。

中央ロシアの地図作成レイヤーの繁殖

最初のタスクは簡単でした-カードは機能し、カードは適切に機能するはずです。 そしてできればどこでも。

Google Dayの数日後の11月中旬に開発が始まりました。

したがって、私たちのカードは：

1. Googleマップv3

2.最新バージョンのYandexマップ

3.最良かつほぼスマート。

カードの初期バージョンは2週間で準備が整いました。

私たちは実際に彼らに以前知っていたすべてのこととその過程で思いついたすべてのことに投資しました。そして、私たちが実際に真剣な不動産サイトであることを忘れましょう。

どこかの5つのステップ

目標を設定します-マップに基づいてツールを作成し、それを実装しようとします。

ステップ1-最初にマップを開始する必要があります

ステップ2-その後、何らかの方法で初期パラメーターを設定する必要があります

ステップ3-サーバーに何らかのデータを要求する必要がある可能性があります

ステップ4-何らかの方法でそれらを表示する

ステップ5-そして最後に彼らと何かをする



そして今、もう少し



また、関数呼び出し、モジュール間メッセージなどの90％がsetTimeoutを介して起動されることを事前に示す必要があります。 エラーとポッドシソンから保存します。 詳細が必要な場合は、お問い合わせください。

PS：また、このようなタイムアウト（_enterState \ _leaveState \ _callStateの理解）での呼び出しのラップにより、何がどこで開始されたか、どれくらい時間がかかったか、エラーをキャッチできます（ただし、callStackをキャッチできません） window.onerrorのエラーは、これらのerlogを常に収集および分析します。 それはあなたがエラーなしで私たちのサイトで作業するのに役立ちます

ステップ1-APIのダウンロード

まず第一に、事実の前にあなたを置きます-あなたはIPAと直接通信することはできません。 一般的に。 決して。

そして、正直に言うと便利ではありません。

それでは、通信するオブジェクトを作成しましょう。

SuperMapsと呼びましょう。

まず、SetWorker、StartWorker、KillWorkerの3つのメソッドを定義します（ SetMapProviderまたはコンポーネントの目的を示す他のスマートワードを呼び出す必要がある瞬間をスキップしましょう。実際には1つのタスク-WORK！があります ）

最初のものは使用するカードのバージョンを設定し、2番目のものはそれを開始しますが、3番目のものはまさにそのように起こります。

確かに、ここでの「カードのバージョン」は、直接使用するのではなく、最終的なAPIのラッパーを意味することを明確にする必要があります（個人的には、このようなラッパーは200行以下しか占有しません）

正常に起動するには、次の一連のアクションを使用します。

1.開始タイマーの開始

2. APIの接続（遅延）、ここでのGoogleマップの場合、2つのステップがあります-最初に、google.comからgoogle.ruからapiをダウンロードしようとします（うまくいかない場合）。 これは気まぐれではありません （誰もが見ているエラーログ）。

3. API接続チェック

4. IPAを起動します

5. IPAローンチレポート

5+。 他のシステムの起動

（6）ここのどこかで、タイマー1が起動します。カードがない場合は、別のAPIを試す必要があります。 奇妙なことに、これは非常に頻繁に発生します-ファイアウォール、プラグイン、およびわさびの悪いチャンネルは驚異的に機能します。

ステップ2-マップ上の目的の場所で鼻を突く

この段階では、ある時点でカードを開く必要があります。 ここでは特に目立ったものはありません-現在のビューポートのパラメーターはURLに保存され、そこから取得されます。 それらが存在しない場合、「特色のある」アドレスが開かれるか、すでにサイトにアクセスしている場合-サイトの各ドメイン領域の最後のセッションのデータ、Cookieから個別に。 これがそのような機能です。 非常に便利:)

ステップ3-サーバーからデータを取得する

比較的最近、私はタイルのヒープの形でデータをダウンロードする秘 aboutについてすでに話しましたが、今年はタイルが大量にロードされない実装では、1つのリクエストで最大6個がサーバーから転送されます。 より正確には、システムは常に4つのストリームにデータをロードしようとしますが、1つのパケットでNタイルを超えないようにします。

この場合のタイルアドレスは、 / maptiles / 7-l032 / 103/031/311/011; 21〜2; 20〜21; 19〜100; 最も大きな目は、ここで7番目のレイヤーの4つのタイルが要求されていることに気付くことができます。 クライアントにとって、このような最適化は、応答時間が短縮され、トラフィックが節約されることに相当します。ファイルが大きくなりすぎると、gzipがより強くなります。 そしてもちろん、データの「クライアントキャッシング」が意味をなさないことを忘れてはなりません-1日あたりのデータ変更の90％です。 サーバーが既製のファイルを1つのパックにまとめるのは難しくありません。鉄です。

確かに、このアルゴリズムには面白いケースが1つあります。最初は、最適化のために、アドレスの配列を取得し、natsortを実行して、美しいURLに分割しました。

奇妙なことに、このオプションはすべてのブラウザーで完全に機能し、最初の配列に40ブロック以上ある場合、IEをしっかりとハングさせます（1つのレイヤーのフルスクリーンは6-8のデータブロックのリクエストを作成し、クライアントは合計で50のデータレイヤーをアクティブにできます） ）

現時点では、通常の並べ替えを使用していますが、これは最も理想的なオプションではなく、URLが少し長くなる場合があります。

私たちの場合、このサブシステムのロード、保存、および同時に表示制御は中心的であり、 ZTileと呼ばれます 。

ステップ4-何らかの方法でこのデータを表示します

おそらく、主要な建築上の問題のいくつかはディスプレイに関連しています。

そのため、特定のオブジェクトセットはサーバーから取得され、各オブジェクトには独自のベースタイプ（広告、POI、写真など）と独自のレイヤー（実際には、データベースからの選択の定義済みwhere-expressionのシリアル番号）があります。

このデータに基づいて情報を表示する方法。

次の計画についてのコンベヤを入手しました。

zTile-Server-data-zTile-SuperMaps-type factory-type-layer-factory- *ソート、クラスタリング* -SuperMaps-APIworker-API-view-type-render

チェーンは長いので、説明させてください。

zTileはサーバーにデータを要求し、その後データを受信します。

次に、彼はメインコンポーネント-SuperMaps-にオブジェクトのモデルを作成するように依頼します。

SuperMapsは宣言されたハンドラーを調べ、そのうちの1つがオブジェクトの受け入れに同意した場合、このタイプのオブジェクトの作成を委任します。

オブジェクトがロードされたレイヤーの識別子は、受信したオブジェクトに「注がれ」ます。その後、ファクトリーがレイヤーを試行した後、オブジェクトのタイプを変更できます（より正確には、動作を指定します）。

その後、オブジェクトは基本的にそれが何であり、どのように表示されたいかを知っています。

*並べ替え*はステップ5で説明しますが、本質的には、今のところ、オブジェクトを単にシャドウから抜け出し、DOMツリーに自分自身についてのメモを残します。

オブジェクトを表示すると、SuperMapsで再びレンダリングに自分自身を送信します。これにより、現在のワーカーへの呼び出しがドロップされ、メーカーのビュー（コントロール、バルーン）が作成されます。

その後、運が良ければ、彼は再びIPAのニーズに適応するために心を変えることができます。

これはYandexやGoogleマップでは発生しませんが、同じOvi-HTMLをマーカーに描画できないだけ-では、システムはそのように動作します。

このアプローチの利点の1つは、最終的なAPIカードが本質的に有限であることです。

これを変更して、同じフォームで同じオブジェクトのセットを別のマップに表示できます。マップを変更して、クラスターの更新を呼び出します。

ステップ5-通常、データと他のバンズを表示する

データセット、特に大規模なデータセット、特に動的に変化するデータセットを表示する際の最も難しい質問の1つは、マーカーが互いに重なり合っていることです。

私たちのクラスタリングオプション（IMHO）は、私が知っている最高のものであり、機能と速度の両方の点でgooglemarkermanager（v2 \ v3）を超えています。

そして、それは非常に簡単に機能します。

手順3でデータを読み込むのと同じ原理に従って、マップを個別のセルに分割し、それらに含まれるオブジェクトをこれらのセルにアタッチします。

次に、1つのセルのオブジェクトのセット内で、相互のオーバーラップが決定され、平凡な結合が発生します。

ポジティブな点は1つだけです。データセットを変更しなくても、グループを再構築する必要はありません。 あるセル内の別のマーカーオーバーレイのデータは完全に静的であり、セルの変更のみがこのセットを変更できます。

つまり、マップをシフトしていくつかの新しいオブジェクトが表示された場合、新しいセルグループのみが再構築されます。 私は繰り返しますが、古いものは静的です。

完全な再構築は、少なくとも1つの新しいオブジェクトがクラスターグループ内のオブジェクトのセットに表示または非表示になった場合に、レイヤーがオンまたはオフになったときにのみ発生します。

確かに、次のトピックでこの「正方形にネストされた」クラスタリング方法の結果として、さまざまなアーティファクトが表示される可能性があります-結局、グループは自律的に動作し、境界に一見豊富なマーカーを残すことを妨げるものは何もありません。



解決策は簡単です。わずかに異なるクラスターサイズ（もう1ピクセルはもう十分です）で別のclusterManagerを作成し、グリッドをそのサイズの半分だけシフトします。

最初のマーカーをグループ化した結果はそれに分類され、この結果は再びグループ化されます。

彼は重複するバランを1つにつぶします。 また、カードの操作中に完全な再構築を行う必要はありません。

確かに、これらの行を書いてからほぼ半年が経過したことを認識しておく価値がありますが、個人的にはアドバイスをしていません。 シングルカードではない....

その結果、システムは何万ものマーカーで非常に明確に機能します。もう少し魔法をかけると、1.5倍高速化できると思います。

しかし、これは必須ではありません。すでに2つのポイントに直面しています-1. DOMツリーの速度を更新する

2.マップ上のマーカーの数。

私たちは長い間最初の問題を解決し、さまざまなDOMフラグメントを見て、キロのドックを読みましたが、最終的には単純に決定しました-すべての出現と消失はグループ操作であり、トランザクションにラップするだけです（表示：なし、もう少し、要素の取り付け/取り外しなど）何度も何度も地図を表示します）、リフローと再描画を減らすことができます。 DevConfでこの問題について（どうやら）言われたことを知りたいのですが（私はそうではなかったのですが、私はそこにいませんでした）。

この操作は連続したjsコードによって実行されるため、カードの「点滅」は表示されません。



第二に、正直に言うと、私たちは決めていません。

表示するオブジェクトの制限は、鉄の友人の速度に応じて変化する可能性がある場合、マーカーを折りたたむことからマップを驚異的にきれいにすることができるマーカーを折り畳むための半径があります。

しかし、出力でまだマーカーの数が過負荷になっている場合、そのような数のオブジェクトで通常の動作（IE6）を保証することはできません-それらを減らす必要があります。 1つの要因を変更し、自分自身をリフレッシュします。 結果はオブジェクトが少なすぎる可能性があります-もう一度、要因の1つを変更して更新します。

その結果、アルゴリズムは時々8ティックに収束します。 確かに、これは実際にはユーザーには目立ちません。

これで終わりですか？

この物語はおそらくはい、終わりです。 トピックのサイズを大きくしても意味がありません。 最も興味深い瞬間については、別の詳細な資料でもう少し詳しく説明します。

適切なコールバックを適切な場所にインストールする、スライダーでカードのサイズを変更する、「外部バラン」（おそらくマーカーバランなどの単純なものの実装を引き続き検討する）、デバッグ、ロギングなど、さまざまな微妙な点...

より良い、私たちはあなたの質問に答えるだけで、それから表示されます。

次は？

現時点では、「マップ上」のサービスの3番目のバージョンを既にリリースしており、近い将来、表示されるコンテンツとインターフェイスアプローチの両方を拡張する予定です。 ニュースと分析コンテンツはマップに表示され、球体プレーヤーは独立した検索ツールのようなものに変わります-家では不動産のオファー、家自体の情報が表示され、庭や建物自体の内部などを見ることができます。 しかし、それはまったく異なる話になります。 ご清聴ありがとうございました。 コメントで質問に答える準備ができました。



それで、何が面白いのか、なぜ上記の数キロのテキストを読んでサイト e自体を見る必要があるか、または必要だったのか：

1. 2つのAPI（実際には4（+ ovi、+ bing）、切り替えの問題なし）

2.サーバーからデータをダウンロードし、再読み込み

3.マップ上の外部バラン-ただし、バランを開いてマップを移動する方が良い

4.バルーン内のマーカーとデータのクラスター （ www.gdeetotdom.ru/map/#lat=55.72867&lng=37.81804&m=google&z=15&l=7-14 、正確にマップの下部および中央にある）

5. Yandexマップ上にGoogleタイルが表示されます（「ロシア360」ロードトラック）