2

PRISM MEF を使用して、地域内のさまざまなゲームを選択できるゲーム マネージャーを作成します。「MainRegion」には静的シェルと動的コンテンツがあります。各ゲームは個別のモジュール (アセンブリ) であり、インスタンスを取得すると、ゲームごとに約 20 ～ 30 MB が割り当てられます。

各ゲームに次のようなコンポーネントがあります。

  • MainView [CreationPolicy.Shared]
    • View1 [CreationPolicy.Shared]
    • ViewN [CreationPolicy.Shared]
  • MainViewModel [CreationPolicy.Shared]
    • ViewModel1 [CreationPolicy.Shared]
    • ViewModelN [CreationPolicy.Shared]

呼び出しによって作成された各「ビュー」(メイン、1st、2nd...)

_serviceLocator.GetInstance<MainView>();

各「ビュー」には次のプロパティがあります

[Import(AllowRecomposition = false)]
public MainViewModel ViewModel //example for MainView
{
    get { return this.DataContext as MainViewModel; }
    set { this.DataContext = value; }
}

ゲームを変更したい場合は から削除MainViewしますが、が に設定されてMainRegionいるため新しいインスタンスは作成されませんが、使用するとインスタンスが削除された後にメモリ リークが発生します。PartCreationPolicySharedNonShared

アプリケーションでこのメモリ リークを修正するにはどうすればよいですか?

4

1 に答える 1

0

リークを解決するための鍵は、メモリ プロファイラーを使用して、オブジェクトがメモリ内に保持されている理由と、それらへの参照を保持しているオブジェクトを特定することによって、最初にリークを理解することです。

質問でそのような情報を提供していないので、このリークの非常に考えられる理由の1つは、オブジェクトが実装していることIDisposableです。MEF が破棄可能なオブジェクトへの参照を保持し、それらを解放しないという既知の問題があります。実際にそうである場合は、この質問で詳細と考えられる解決策を確認できます: MEF は NonShared IDisposable パーツの参照を保持し、 GC による収集を許可しません。もう 1 つの可能性は、インポートの 1 つが再構成を許可するように構成されていることです。この場合、MEF はオブジェクトへの参照も保持します。

また、GC は必要な場合にのみガベージ コレクションを実行し、インスタンスを削除した直後に実行するとは限りません。ガベージ コレクターを自分で呼び出して、オブジェクトが実際にメモリに保持されていることを確認できます。

GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();

オブジェクトが使い捨てではなく、再構成を可能にするインポートがない場合、それらへの参照は自分のコードによって保持されている可能性が高く、アプリケーションをプロファイリングして誰が作成したかを調べる必要があります。そのためには、ANTS Memory Profilerを使用することをお勧めします。

于 2013-07-19T20:42:47.083 に答える