ios開発のメモリ管理に奇妙なこと

Question

私のiPodにはアプリがあります。

1.Openアプリ、および（アクティビティモニタ）メモリ楽器を見て、それが画面に大きな画像でUIImageViewを追加し、8.95M

2.clickボタンだ、メモリがあります17.8Mになりました。

3. UIImageViewを画面から削除し、1秒待ってから、メモリは9.09Mになりました。

私はUIImageViewがスクリーンから削除された後にリリースされると確信しています。それは非常に単純なコードです。 それを削除すると、アプリケーションの状態は、UIImageViewの追加を画面に追加する前と同じになるはずです。そうですか？しかしなぜメモリは8.95Mではなく9.09Mですか？より複雑なビューを画面に追加すると、その違いがより明らかになります。

Answer 1

これは正常です。これは、「遅延成長、怠惰な縮小」アルゴリズムによるものです。つまり、少数のアイテムや多数のアイテムのサイズに合わせたデータ構造を持つことができます。少数のアイテムのサイジングはメモリをほとんど使用しませんが、多数のアイテムを処理する場合は効率的ではありません。大規模なサイジングは、大規模なコレクションを管理するのに非常に効率的ですが、オブジェクトを索引付けするためにより多くのメモリーを使用します。

"lazy grow、lazy shrink"アルゴリズムは、構造のインデックスのサイズを変更するコストを回避しようとします。サイズが非常に小さい場合はインデックスを大きくし、大きすぎる場合は縮小するだけです。たとえば、典型的なアルゴリズムでは、理想的なサイズが理想サイズの3倍を超える場合にのみ、そのサイズが少なくとも3倍大きくなった場合にのみ索引を伸ばすことができます。これは、アプリケーションが素早くリソースのコレクションを割り当てたり解放したりする場合に、インデックスサイズをちょっとしたものにしたい場合に、大量のリサイズ操作を防ぐためにも必要です。

ラージオブジェクトを開いてGUIオブジェクトを使用すると、インデックスが非常に小さくなりすぎてしまいます。しかし、大きなオブジェクトを閉じると、索引が大きすぎるだけなので索引は縮小しません。

デバイスがメモリ不足の場合、インデックスは縮小されます。アプリケーションがUIリソースの使用を引き続き削減する場合、インデックスは縮小されます。アプリケーションがより多くのUIリソースを使用する場合、インデックスはすぐに再成長する必要はありません。

良いアナロジーは、あなたの机の上に紙の束があるかもしれません。あなたが見つけなければならないかもしれない30の論文を持っているなら、4つのスタックにそれらを保持するかもしれません。しかし、もしあなたが5,000の論文を持っていれば、4つのスタックが面倒な検索になります。その場合、スタックがさらに必要になります。したがって、用紙の数が4枚のスタックでは大きすぎる場合は、より多くのスタックに再インデックスする必要があります。しかし、数字が小さくなると、検索がまだまだ高速であるため、スタックが多すぎるようになるまで、常にインデックスを再作成する必要はありません。

これらの用紙をすべて処理すると、机の中に余分なスタックがいくつかあります。これにより、次回に多くの論文を処理する必要があるときに、再度インデックスを作成する必要がなくなります。