0

GoogleMapたくさんの小さなマーカーがロードされた状態で使用しています。私たちはおそらく400-500のマーカーを話している。ユーザーとの対話時に、これらのマーカーのサブセット、おそらく100〜300個のマーカーの色を変更したいと思います。これは理想的には30ms以下で達成したいのですが、50〜60msまでは許容範囲です。

今、私は次のようなコードを持っています：

onUserInteraction... {
    changeColors(getTheSubset)
}

changeColors(subset) {
    getMarkersForSubset(subset).removeAllFromMap();
    map.addNewMarkers(subset)
}

そこで、古いマーカーをいくつかの色（たとえば、緑）で削除し、それらの場所に新しいマーカー（たとえば、黒）を追加します。サブセットが関連しなくなったら、反対のプロセスを実行します。

マップの最も忙しい部分では、これには500ミリ秒以上かかることがわかります。また、さまざまなマーカーがさまざまな時間に色を変えるという顕著な遅れがあります。ですから、マーカーを削除/追加せずに、alloc / gcを最小化しながら、地図上に小さな円を描き、色を変更するためのより良い数学ベースの方法があるかどうか興味があります。

4

2 に答える 2

0

sの使用を検討しましたLevelListDrawableか？更新時にすべてのマーカーを削除して再度追加するのではなく、各色をのレベルとしてさまざまなドローアブルを使用できますLevelListDrawable。次にsetLevel()、ピンのセットを更新するときに、呼び出して、必要な色で適切なドローアブルを設定できます。マップピンにを使用できるかどうかは100％わかりませんがLevelListDrawable、一見の価値があります。

API：http ://developer.android.com/reference/android/graphics/drawable/LevelListDrawable.html

例： http： //iserveandroid.blogspot.com/2010/10/progress-bar-implementation-using-level.html

于 2013-02-13T21:01:01.643 に答える
0

したがってLevelListDrawable、Gmapは。を使用しているため、sはオプションではありませんBitmapDescriptorFactory。

私が見つけた解決策の1つは、古いものの上に新しい色で描画しMarker、古いものを下から削除することでした。

それには2つの問題がありました。

  • 1つは、google-maps-android-v2がsのz-indexingをサポートしていないことMarkerです。
  • 2つ目は、色を変更するsがたくさんある場合Marker、そのパフォーマンスによってアーティファクトが発生することです。

さて、最近グーグルMarkerはコモンでsBitmapを描くのをずっと速くするアップデートをリリースしました、しかしあなたはいつでもそれをも​​っと投げMarkersてそれを壊すことができます。

Markerまた、上に描画しようとしましたが、その可視性をに設定し、その場所が「選択」されたときにfalse設定しました。true公平を期すためにベンチマークをしませんでしたが、これはそれほど速くは見えませんでした。

Bitmap結論： sを変更しないでくださいMarker。（今のところ）

于 2013-03-12T20:55:00.920 に答える