0

ユーザーが新しいウィンドウを作成して開くことができる ARC を使用して Cocoa で記述されたアプリケーションがあります。(文書モデルのようなものですが、nsdocument は使用していません。 )

新しいウィンドウごとに大量のメモリが必要です。ユーザーがウィンドウを閉じると、メモリを取り戻したいと思います。

単にウィンドウを非表示にすることは理解して[window close]いますが、私も を使用していますが[[self window] setReleasedWhenClosed:YES]、 とそのウィンドウの両方がNSwindowcontroller閉じた後も存在しています。

ウィンドウの xib ファイル内のオブジェクトには、malloc で割り当てられた多数の大きな c 配列が含まれているため、windowcontroller のwindowWillClose:メソッド内の通知センターに呼び出しを送信して、それらを解放しようとしました。通知は、関連するオブジェクト内のメソッドを呼び出して、ウィンドウが閉じる前に C 配列を解放します。繰り返しますが、これは何の効果もありません。アクティビティ モニターによると、配列を解放しようとするメソッドが呼び出され、配列が解放されたように見えても、メモリは解放されません。で配列を解放しようとしました-(void) deallocが、これはクローズ時に呼び出されることはないようです。

では、ウィンドウが閉じられたときにメモリを取り戻すにはどうすればよいでしょうか?

編集： Benoitによるこのstackoverflowページのコメントによると、

「ただし、ウィンドウ コントローラが所有するウィンドウでは、閉じたときのリリースは無視されます。」

本当？もしそうなら、ARCでそれを回避するにはどうすればよいですか?

4

1 に答える 1

3

解放されたメモリは、常にオペレーティング システムに返されるとは限りません。これは、少なくとも圧縮ガベージ コレクタを持たないシステムでは、現実の事実です。

何を見ているのか正確にわかっていない限り、Activity Monitor の統計に注意を払わないでください。仮想メモリ、メモリのどの部分が共有ライブラリによって占有されているか、使用しているアロケータの動作など、システムに関する十分な知識がない限り、この情報は一般的に役に立ちません。NSArrayおよびクラスはNSMutableArray、割り当てに関してかなり不透明な動作をします。名前が示すように、それらは一般に線形配列ではありません。

提案:ウィンドウが解放されている限り、Activity Monitor の統計は無視してください。インスツルメントを使用してリークをチェックできます。

アクティビティ モニターを無視する必要がある理由の例として、1 KiB チャンクで 500 MiB の割り当てを行い、奇数番号のチャンクを解放すると、ページの粒度が 4 であるため、明らかにオペレーティング システムに返すことができません。最近のほとんどのシステムで最小の KiB。同じ 500 MiB を 1 MiB チャンクに割り当て、奇数番号のチャンクを解放すると、それらは OS に返され、メモリ使用量はアクティビティ モニターで報告されるように 250 MiB 減少します。(4 KiB のしきい値は、この動作が発生するしきい値ではないことに注意してください。 による正確な割り当て動作malloc()と、OS X では CPU と RAM の量に依存するいくつかのパラメータに依存します。)

ただし、おそらく無関係です。いずれの場合も、250 MiB を再度割り当てると、開始した場所に戻ります。プライベート メモリの使用量が少ないのは良いことですが、これはアプリケーションが他のアプリケーションとどの程度うまく機能するかに影響するだけです。

于 2012-11-23T01:31:20.090 に答える