快捷導(dǎo)航

C# WinForm應(yīng)用程序降低系統(tǒng)內(nèi)存占用方法總結(jié)

更新時(shí)間：2014年10月24日 15:29:44 投稿：junjie

這篇文章主要介紹了C# WinForm應(yīng)用程序降低系統(tǒng)內(nèi)存占用方法總結(jié),本文總結(jié)了9個方法,同時(shí)給出了一個定期清理執(zhí)行垃圾回收代碼,需要的朋友可以參考下

背景：

微軟的 .NET FRAMEWORK 現(xiàn)在可謂如火如荼了。但是，.NET 一直所為人詬病的就是“胃口太大”，狂吃內(nèi)存，雖然微軟聲稱 GC 的功能和智能化都很高，但是內(nèi)存的回收問題，一直存在困擾，尤其是 winform 程序，其主要原因是因?yàn)?NET程序在啟動時(shí)，是需要由JIT動態(tài)編譯并加載的，這個加載會把所有需要的資源都加載進(jìn)來，很多資源是只有啟動時(shí)才用的。

以XP 系統(tǒng)為例子，程序啟動后，打開任務(wù)管理器，會看到占用的內(nèi)存量比較大，你把程序最小化，會發(fā)現(xiàn)該程序占用的內(nèi)存迅速減小到一個很小的值，再恢復(fù)你的程序，你會發(fā)現(xiàn)內(nèi)存占用又上升了，但是比你剛啟動時(shí)的內(nèi)存占用值還是小的，這就是一個資源優(yōu)化的過程，這個過程是操作系統(tǒng)主動完成的。

結(jié)論與展望：

創(chuàng)新設(shè)計(jì)大賽的項(xiàng)目已經(jīng)快到交付的日期了，都說Winform占用內(nèi)存大，于是想著看看自己寫的基于手機(jī)郵件的遠(yuǎn)程關(guān)機(jī)軟件（Mail_Based_Remote_Shutdown）占用內(nèi)存情況，整個開發(fā)過程自己也在盡量寫一些比較優(yōu)美的代碼來減少系統(tǒng)內(nèi)存占用，今天看了下，剛打開時(shí)占用20M內(nèi)存，然后一點(diǎn)點(diǎn)增加，最后到80多M，真是無法忍受，每次都是寫了之后回過頭來才發(fā)現(xiàn)自己的代碼很丑，系統(tǒng)架構(gòu)師的作用就體現(xiàn)出來了。

這里整理了一些網(wǎng)上關(guān)于Winform如何降低系統(tǒng)內(nèi)存占用的資料，供參考：

1、使用性能測試工具dotTrace 3.0，它能夠計(jì)算出你程序中那些代碼占用內(nèi)存較多
2、強(qiáng)制垃圾回收
3、多dispose，close
4、用timer，每幾秒鐘調(diào)用：SetProcessWorkingSetSize(Process.GetCurrentProcess().Handle, -1, -1);具體見附錄。
5、發(fā)布的時(shí)候選擇Release
6、注意代碼編寫時(shí)少產(chǎn)生垃圾，比如String + String就會產(chǎn)生大量的垃圾，可以用StringBuffer.Append
7、this.Dispose(); this.Dispose(True); this.Close(); GC.Collect();
8、注意變量的作用域，具體說某個變量如果只是臨時(shí)使用就不要定義成成員變量。GC是根據(jù)關(guān)系網(wǎng)去回收資源的。
9、檢測是否存在內(nèi)存泄漏的情況，詳情可參見：內(nèi)存泄漏百度百科

附錄：定期清理執(zhí)行垃圾回收代碼：

復(fù)制代碼代碼如下:

//在程序中用一個計(jì)時(shí)器，每隔幾秒鐘調(diào)用一次該函數(shù)，打開任務(wù)管理器，你會有驚奇的發(fā)現(xiàn)

#region 內(nèi)存回收

[DllImport("kernel32.dll", EntryPoint = "SetProcessWorkingSetSize")]

public static extern int SetProcessWorkingSetSize(IntPtr process, int minSize, int maxSize);

/// <summary>

/// 釋放內(nèi)存

/// </summary>

public static void ClearMemory()

{

GC.Collect();

GC.WaitForPendingFinalizers();

if (Environment.OSVersion.Platform == PlatformID.Win32NT)

{

App.SetProcessWorkingSetSize(System.Diagnostics.Process.GetCurrentProcess().Handle, -1, -1);

}

}

#endregion