0

ここ数週間、iPhone でタイリング メカニズムを動作させようと、頭を悩ませてきました。スクロール ビューで要求されるタイルとして保存できるように、約 150 MB の画像をスケーリングおよびトリミングする必要があり、ユーザーは画像を高解像度で表示できます。

問題は、これらの画像が iPhone の処理能力の限界を押し広げていることです。これらの巨大な画像を 1000 程度に縮小してタイリングするのは非常に簡単に思えますが、ズーム レベルが大きい場合は途中で、たとえば 4000 に拡大する必要があり、それは大きすぎます。そこで、フルサイズの画像から中サイズのブロックを作成し、それらのそれぞれと中ズームをタイリングするというアイデアを思いつきました。

内側のループの周りに autoreleasepool を作成し、各サイクルの後にそれを排出することで、ほとんどの場合、メモリを制御下に置くことができますが、ランダムに見えることがあり、メモリがリークするか、少なくとも排出されません。私はこれをすべてセカンダリ スレッドで行っており、そのスレッドの最初の関数に戻ったら、スレッド自体の autoreleasepool を解放してから、最後のメモリ アーティファクトをクリアします。シミュレーターには問題ないようですが、iPhone の許容度ははるかに低く、タイリング プロセス全体を完了する前にクラッシュします。私が使用しているクロッピング コードは Hive05 のものです

http://www.hive05.com/2008/11/crop-an-image-using-the-iphone-sdk/

これほど大量の画像を扱う必要があった人は他にいますか? タイルを事前に生成するのが最善の方法ですか? 一部のループがメモリを増加させ、一部を増加させない理由、または外側のプールを待つ代わりに内側のプールですべての自動解放されたものを強制的にクリアする方法についての提案はありますか?

ここまで読んでくれてありがとう。

追加しなければならないのは、これらの画像はTIFであるため、ビットマップ情報を直接読み取る方が、全体をスケーリングしてトリミングするよりも優れている可能性があることです。

4

2 に答える 2

0

まず第一に、3GSについて話しているとしても、150MBの画像がデバイスのメモリに収まるのではないかという深刻な疑問があります。これには、サードパーティアプリ用に最大で約128MBの使用可能なメモリがあります。デバイスコンソールのメッセージを確認し、メモリの警告を探します。クラッシュする前に、アプリが画像を読み込もうとしたときにメッセージを出力することがわかると思います。一度に小さなセクションを管理するので、ビットマップ情報をチャンクで読み取る方が賢明に思えます。CocoaにはランダムアクセスファイルAPIがないと思うので、C関数に頼る必要があります。

于 2009-12-12T00:13:10.930 に答える
0

1024x1024 のタイルを循環するループを書くことができ、私の iPhone 3G は処理を終了することができました。30 分以上かかるので、あまり良くはありませんが、携帯電話で 150 MB の TIF を使用する場合は、これで十分です。

メモリ使用量を低く抑えるために、反復ごとに AutoReleasepool を排出する必要がありました。Apple テクニカル サポートは、iPhone はガベージ コレクション環境ではなく参照カウント環境であるため、前に作成するよりも、各内部ループの開始時に新しい AutoReleasePool を作成し、各ループの終了時に排出する方が良いと指摘しました。ループが開始され、何度も排出され、ループが完了したら解放されます。その変更を行うまで、アプリは iPhone をクラッシュさせますが、シミュレーターでは問題なく動作します。

于 2010-01-08T03:49:08.910 に答える