0

これらの場所を場所の名前(タイトル+緯度と経度)でアプリに保存すると、かなりのスペースが必要になります。アプリのサイズを小さくするにはどうすればよいですか?どんな提案でも私は素晴らしいものになるでしょう。

また、これはおそらくアプリのパフォーマンスを低下させるでしょう、それを考慮した提案はありますか?

編集1:グーグルマップと同じように、すべてをオンラインサーバーに保存し、「注釈のタイル」についてクエリを実行すると、それが解決策になる可能性があることに気づきました。だから私の質問は今です:「注釈のタイル」を照会するための良いアルゴリズムを知っている人はいますか?マップには複数のzoomLevelなどが含まれているため、これは非常に難しい場合があります。まず、既にクエリを実行したタイルを格納する複数のクアッドツリー(zoomLevelごとに1つ)を作成します。

このアプローチは良いかもしれないと思いますか?それとも、3Gで実行するには遅すぎるのでしょうか?

前もって感謝します。

4

2 に答える 2

1

ソリューションに制限を設定しなかったので、次のようにします。

まず最初に、注釈を実際のデータベースに保存します。300k レコードは XML ファイルには少し多く、ある時点でそれらのクエリを開始する必要があり、XML はそれに適していません。

次に、デバイスまたはサーバーに保存します。あなたの選択、私は 300.000 の注釈がどれほど大きいかわかりません。設定された半径のリージョンごとに、サーバーまたはデータベースにクエリを実行します。これはそれほど難しいことではなく、クエリの量 (およびサーバー通信) を適切に制限する必要があります。MKMapViewそれを、インスタンスまたはインスタンスから取得したコールバックと直接組み合わせることができCLLocationManagerます。

それでも通信量が多すぎることが心配な場合は、キャッシュ メカニズムを組み込みます。データの目的が何であれ、クエリの結果を一定時間 (または一定の容量、または使用頻度で) 一時的にディスクに保存します。データベースまたはサーバーに移動する前に、最初にディスクから結果を解決しようとするように、クエリメカニズムを構築します (ローカルデータベースがある場合は、実際のキャッシュメカニズムは必要ありません)。

これらのことを行うことができない (サーバーまたはデータベースを持っている) 場合は、少なくとも XML ファイルを分割して、データの管理とクエリを自分で簡単に行えるようにします。遅延読み込みを行いますが、データ構造が遅延読み込み用に設定されていることを確認してください (XML はそうではありません)。

PS: クエリを実行している場合は、ズームしすぎることを心配する必要はありません。現在地 + オフセット半径を照会するだけです。オフセット半径は、ズームの量によって定義されます。これは、サーバー/データベースに送信する別のパラメーターにすぎません。

于 2012-06-05T23:51:40.477 に答える
0

これらの場所は、バックアップされたサーバーから遅延して (必要なものだけを取得して) ロードする必要があり、アプリ自体をストレージ エンジンとして使用しないでください。

于 2012-06-05T23:04:36.763 に答える