ipodにアプリがあります。
1.アプリを開き、メモリ機器（アクティビティモニター）を見て、8.95Mです
2.ボタンをクリックすると、大きな画像を含む UIImageView が画面に追加されます。メモリは現在 17.8M です。
3. 画面から UIImageView を削除し、少し待ちます。現在、メモリは 9.09M です。
画面から削除された後、UIImageViewが解放されると確信しています。それは非常に単純なコードです。削除すると、アプリのステータスはUIImageViewを画面に追加する前と同じになるはずですよね？しかし、なぜメモリーが 8.95M ではなく 9.09M なのですか? より複雑なビューを画面に追加すると、違いがより明確になります。
これは正常です。これは、「遅延成長、遅延縮小」アルゴリズムによるものです。つまり、少数の項目または多数の項目のサイズを変更できるデータ構造があるということです。少数のアイテムのサイジングはメモリをほとんど使用しませんが、多数のアイテムを処理する場合は効率的ではありません。多数のサイズ設定は、大量のコレクションを管理するのに非常に効率的ですが、オブジェクトのインデックス作成により多くのメモリを使用します。
「遅延成長、遅延縮小」アルゴリズムは、構造体のインデックスが小さすぎる場合にのみ拡大し、大きすぎる場合にのみ縮小することで、構造体のインデックスのサイズ変更のコストを回避しようとします。たとえば、典型的なアルゴリズムでは、理想的なサイズがその 3 倍以上の場合にのみインデックスを拡大し、理想的なサイズの 3 倍を超える場合にのみインデックスを縮小します。これは、アプリケーションがリソースのコレクションを迅速に割り当てて解放する場合に、多数のサイズ変更操作を防ぐためにも必要です。インデックス サイズを少し「固定」したい場合です。
大きなオブジェクトを開いて GUI オブジェクトを使用すると、インデックスが小さすぎて大きくなります。ただし、大きなオブジェクトを閉じると、インデックスが少し大きくなりすぎるだけなので、縮小しません。
デバイスがメモリ不足になると、インデックスが縮小します。アプリケーションが UI リソースの使用を減らし続けると、インデックスは縮小します。アプリケーションがより多くの UI リソースを使用する場合、インデックスはすぐに再び大きくなる必要はありません。
良い例えは、机の上の紙の山かもしれません。探す必要のある書類が 30 冊ある場合は、それらを 4 つのスタックに保管することができます。しかし、5,000 の論文がある場合、4 つのスタックでは検索が面倒になります。その場合、より多くのスタックが必要になります。そのため、論文の数が 4 スタックには大きくなりすぎた場合は、より多くのスタックにインデックスを再作成する必要があります。しかし、数が少なくなっても、検索は依然としてかなり高速であるため、スタックが多すぎるまで絶えずインデックスを再作成する必要はありません。
これらの書類をすべて処理し終えると、デスクには余分なスタックがいくつかあります。これにより、次に大量の論文を処理する必要が生じたときにインデックスを再作成する必要がなくなります。