Silverlight記憶體泄露（五）MEF等Ioc架構引起記憶體泄露-PartCreationPolicy

文章目錄

•  

 

對象的建立可以使用new，也可以使用IOC架如：castle、MEF等，IOC建立的對象的生命週期，可能IOC負責管理，使用架構的開發人員如果不弄清楚可能會造成記憶體泄露問題。

這些記憶體泄露問題並不是IOC架構的bug，只是開發人員使用不當或者不注意造成的記憶體泄露問題。

以MEF為例說明我碰到的兩種記憶體泄露問題。

記憶體泄露系列閱讀提示：

一摸一樣的對象圖，有時候我們可以認為它是記憶體泄露，有時候又認為它不是記憶體泄露，這一切只是由於上下文不同，這一系列文章中ANTS Memoery Profle都是有特定上下文，單獨看完全沒有意義。如何確定是記憶體泄露？可以參考前面的文章。

對象以圖的形式存在，Ants Memory Profile為了分析方便把這些圖處理為樹，讓我們可以把注意力集中到分析的對象。但我們必須明白記憶體中對象關係構成圖，也就是說ANTS的樹狀圖只是記憶體中對象分布的一個局部，分析記憶體泄露時必須有全域觀念，需要相關的幾張圖一起看，即使一張圖也要整體看，這樣才能分析記憶體泄露問題。

由於看一張圖沒什麼意義，如果把多張圖都貼出來，這文章就太難寫了，即使多張圖都貼出來，也不一定能表達清楚，分析記憶體泄露最重要的是經驗。接下來的幾篇會減少甚至不用這ANTS圖。

PartCreationPolicy使用不當引起記憶體泄露

Shared：對象以Singleton方式建立。

Non Shared：每次請求時建立新對象。

Any： Be default, CompositionContainer will use Shared, unless the ComposablePart or importer requests NonShared。預設值

在使用不同的組合方式時，PartCreationPolicy有不同的預設值，因此盡量不要使用預設值。

看下面的程式：

NavigationCommand：由於多個View頁面都有需要導航，把導航都放到類NavigationCommand中，恰恰是這一做法引出了記憶體泄露問題。

 

[Export(typeof(NavigationCommand))]

public class NavigationCommand

{

private RelayCommand<string> readBookComamand = null;

public RelayCommand<string> ReadBookComamand

{

get

{

if (navigatToContentCommand == null)

{

navigatToContentCommand = new RelayCommand<string>

(

p =>

{

//
},

p => !string.IsNullOrWhiteSpace(p)

);

}

return readBookComamand;

}

}

}

ViewModle

 

[ViewModelExport(typeof(BookPageSearcheViewModle), "BookPageSearche")]
[PartCreationPolicy(CreationPolicy.NonShared)]
public class BookPageSearcheViewModle: NavViewModel
{
public RelayCommand<string> ReadBookComamand
{
get
{
return NavigationCommand. ReadBookComamand;
}
}
}
public abstract class NavViewModel : ViewModelBase, IViewModel
{
/// <summary>
/// The navigation service allows you to navigate to an other ViewModel.
/// </summary>
[Import]
public INavigationService NavigationService { get; set; }
[Import]
public NavigationCommand NavigationCommand
{
get;
set;
}
}

 

View

 

[ViewExport(ViewModelContract = typeof(BookPageSearcheViewModle))]
public partial class BookPageSearcheView: Page, IView
{
public BookPageSearcheView ()
{
InitializeComponent();
}
protected override void OnNavigatedFrom(NavigationEventArgs e)
{
if (this.DataContext is ICleanup)
{
((ICleanup)this.DataContext).Cleanup();
}
}
}
}

 

上例中NavigationCommand預設以Shared方式建立。

ANTS Memory Profiel 產生記憶體泄露的對象圖：

可看出：BookPageSearcheViewModle 、Mef都引用了NavigationCommand，導致NavigationCommand沒有被釋放產生了記憶體泄露，在此只看MEF這一條路徑。

我在處理這個記憶體泄露時太專註於BookPageSearcheViewModle對readBookCommand的引用了，而沒有全面看這些圖，斷開BookPageSearcheViewModle對readBookCommand引用是最簡單的處理方法，但是在處理其他ViewModel的時候會發現太多的Command需要處理，這時候才認識到斷開引用的點錯了。

因此一定要謹慎全面的看對象圖，一個路徑上包含n個點，斷開任何點都能解決這個對象的泄露問題，但是一個程式有N個對象，這種只著眼當前對象的處理方式不能從根本上解決問題，必須找到記憶體泄露的根源。

解決MEF這個泄露問題，最簡單的是加上：[PartCreationPolicy(CreationPolicy.NonShared)]

還可以使NavViewModel類實現所有Command，把組合轉換為繼承，斷開長引用。

結論

a) 不要盲目使用第三方架構。

b) 設計時組合優先於繼承，但組合更容易產生記憶體泄露，因為任何一方如果是長時間存活，記憶體就不會被釋放。繼承則無這個問題。

c) 注意由IOC建立的對象生命週期，如果IOC建立的對象由容器管理生命期，可能需要調用IOC提供的相關方法執行對象的銷毀。

e)MVVM 比Code behind 方式更容易產生記憶體問題。V、VM雙向參考關聯性，更可能造成記憶體不被釋放