1

ユーザーがGoogleマップの上に画像をロードできるアプリケーションがあります。これは2.3用に開発されたため、MapActivity、MapView、および画像を表示するカスタムOverlayクラスがあります。オーバーレイクラスのdraw-methodでは、毎回Matrixを再計算するため、画像は正しいサイズと位置になります。また、ユーザーが基準点をドラッグして画像を調整できるキャリブレーションモードもあります。

アプリケーションにいくつかの機能を追加し、フラグメントの使用などの更新から始めたいと思います。MapActivityをMapFragmentに置き換えると、自分で描画を実装できるオーバーレイがサポートされていないように見えるため、いくつかの疑問が生じます。GroundOverlaysまたはTileOverlayを使用する必要があるようです。（間違っている場合は訂正してください。）

これらはどちらも、追加後のオーバーレイの変更をサポートしていないようであるため、画像のキャリブレーションは機能しません。その部分の私の計画は、キャリブレーションモードのMapFragmentの上に通常のImageViewを配置することです。（これにより、すべてのマーカーが非表示になりますが、キャリブレーション中は関係ありません。）これを機能させるには、次の2つが必要です。*キャリブレーションポイントに影響するすべてのタッチイベントを受信し、残りを転送して通常のズームなどを可能にします。*いつでも検出できます。位置/回転/ズームレベルが変わるので、画像を調整できます。質問1：それに関する大きな問題は予想できますか？

次に、GroundOverlaysとTileOverlayのどちらが望ましいかを判断する必要があります。

GroundOverlay：画像全体をロードするので、これは最小限の作業で済むようです。また、画面の向きの変更なども自動的に処理できると思います。質問2：GroundOverlayは大きな画像（最大2000 * 2000ピクセル）でうまく機能しますか？関係する画像のコピーはありますか？画像が非常に大きいため、メモリ内に複数のコピーを保存する余裕はありません。

TileOverlay：ある意味、これは実際に必要な部分のみを使用し、後で複数のマップ画像ソースを同時に使用するためのサポートを導入できるため、より専門的なソリューションのように見えます。おそらく、事前にタイルを生成し、それぞれに個別のファイルを保存する必要があります。それをメモリに保持し、オンデマンドでタイルを作成すると、多くのメモリが必要になる可能性があります。（または、別のタイル提供サービスを作成することもできますが、それは少し汚いようです。）質問＃3：タイルキャッシュが使用するメモリの量を制御できますか？通常の制限は適用されますか？キャッシュが使用を許可されているメモリの大部分を占めているという理由だけで、アプリケーションのどこかでメモリが不足したくありません。質問4：ドキュメントには、「他のオーバーレイとは異なり、マップが再作成された場合、これは、ファイルを再度読み取る必要があり、ロードの遅延が顕著になることを意味します。これを回避する良い方法はありますか？質問5：getTileが呼び出されてnullを返した場合（タイルはファイルに保存されており、読み取り中にUIスレッドをブロックしたくないため）、再度要求されるまでどのくらいかかりますか？（個々のタイルを手動でロードする方法はないようです。）質問6：1つのタイル画像の適切な画像解像度を（パフォーマンスと品質に関して）判断するにはどうすればよいですか？これは、ファイルを再度読み取る必要があり、ロードの遅延が顕著になることを意味します。これを回避する良い方法はありますか？質問5：getTileが呼び出されてnullを返した場合（タイルはファイルに保存されており、読み取り中にUIスレッドをブロックしたくないため）、再度要求されるまでどのくらいかかりますか？（個々のタイルを手動でロードする方法はないようです。）質問6：1つのタイル画像の適切な画像解像度を（パフォーマンスと品質に関して）判断するにはどうすればよいですか？

4

1 に答える 1

6

たくさんの質問。私はいくつかに対処しようとします。

  1. 一般に、Maps API v2 は v1 よりもはるかに寛容ではないことに注意してください。そして、それは良いことです。v2 には、v1 にはなかった多くの組み込み関数と最適化があり、API が制限されているため、その最適化を使用する必要があります。

  2. たとえば、GroundOverlay を使用して画像を表示していた場合 [画像を回転したり歪めたりする必要がないと仮定して]、画像の緯度/経度の境界を指定するだけで、Maps v2 によって画像が引き伸ばされます。2000x2000 は 2000x2000x4 バイトになるため、メモリ内に 16M バイトが必要です。ただし、GroundOverlayOptions は BitmapDescriptor を使用するため、画像をメモリに完全にロードすることはできません。私は GroundOverlay にあまり詳しくありません。

    もう 1 つのオプションは、最初に画像をロードするときに画像をタイルに分割してローカル ストレージに保存することです。TileOverlay で使用するのは非常に簡単です。2kx2k 画像からタイルを直接読み取ることは合理的ではありません。これは、すべてを読み取る必要があるためです (圧縮されている場合は、圧縮されていると思います)。画像の変更されたバージョンを表示する必要がある場合は、変更可能であることを確認した後、ビットマップ上にキャンバスを作成するだけでよいことに注意してください。

  3. 私はよく使う TileOverlay に慣れています。タイル キャッシュは私には十分に公平に見えます。大量の 256x256 タイルをロードし、常に 13M から 20M ヒープの間に留まりました。Google マップ タイルと同じように使用していると思います。ローカル ストレージ メモリに一部をキャッシュしますが、多すぎることはなく、表示されていないメモリ タイルにはまったくキャッシュしません。タイルがリロードされていることをパディングするときに確認できます。

    内部ストレージのファイルを一覧表示することで、GMaps タイルのキャッシュ戦略を簡単に確認できます。GMaps キャッシュ タイルが表示されます。

  4. はい、GoogleMap を停止/開始すると、表示中のタイルごとに getTile(x, y, zoom) が呼び出されます。getTile への各呼び出しには独自のスレッドがあるように見えるため、読み込み時間は問題になりません。タイルが既にデバイスに保存されている場合、読み込みは非常に高速です。データをスマートな方法で保存すれば、実際には問題ありません。

  5. null を返したことはありません。この場合、何が起こるかわかりません。無視される例外が発生する可能性があります。getTile 内のコードによって生成された実行時例外または java.lang.error でさえも、GoogleMap 呼び出しによって無視されることに注意してください。 //code.google.com/p/gmap...

    あなたの質問に答えるために、私は「NO_TILE」オブジェクトを返しました。その後、GMap は他のタイルと同様にそれをキャッシュします。TileOverlay.clearTileCache()を呼び出すことで、タイルのリロードを強制できます。

  6. 私はそれについて考えてきましたが、私は 256x256 タイルしか使用しておらず、高 DPI の Nexus 10 でも十分に機能しているようです。この問題についてこれ以上調査していませんが、GMaps が最適なタイルを既に選択している可能性があります。 256p が非常に標準的なタイル サイズである場合、ズーム レベルに応じて表示されます。

于 2013-03-06T20:38:50.597 に答える