最近關注的WP7比較多，眾所周知所有的移動終端設備幾乎對內存都有著令人發指的要求，而我所開發的領域——游戲，卻是對內存要求非常高，一組幾百人的用戶數據字節數可能還沒一張圖片字節數多，而近期我的一些游戲作品也在探討有關內存的優化等問題，最近WP7的lumia 610悄然加入到Apphub的支持機型名單，這個內存只有256MB的機器會拒絕所有內存（memory）超過90MB的app，以至于很多朋友措手不及，下面摘抄總結了一些內存的有關問題。

第一個問題是：看

因為在模擬器里不會對內存有要求，但是要想弄全所有的設備，可是一個不小的開銷，所以如何了解自己的內存是否超了上限是一個重要問題。

Silverlight for WindowsPhone的應用可以直接用

Application.Current.Host.Settings.EnableFrameRateCounter = true;

來開啟應用當前的頁面數據顯示，如下圖

而這些數據的作用詳細請參看這里：

http://msdn.microsoft.com/zh-cn/library/gg588380(v=VS.92).aspx

在早期，我一直以為這是準確的數據，可是后來知道這只是畫面紋理的內存數值，和真實的內存不一樣。而且在XNA for WindowsPhone的應用里沒法直接打開查看，所以，需要另外一個方法取得：

Microsoft.Phone.Info.DeviceStatus.ApplicationCurrentMemoryUsage

類Microsoft.Phone.Info.DeviceStatus里包含了各種對程序內存的靜態屬性，具體的信息可以看

http://msdn.microsoft.com/en-us/library/microsoft.phone.info.devicestatus(v=vs.92).aspx

所以無論在Silverlight還是XNA里，都可以寫一個簡單的計算取得當前應用程序的內存數據：

var value = Microsoft.Phone.Info.DeviceStatus.ApplicationCurrentMemoryUsage / (1024d * 1024d);

第二個問題：縮

你得到了內存數據之后，如果沒有超過還好，如果太大并且需要優化的話，就得考慮怎么來縮它了。

注意點1：實現IDisposable

盡量的對于會重復的數據帶上IDisposable

注意點2：Image.Source = null

一些動態的載入BitmapImage他們悄聲無息的一直站著資源，這個雖然看起很土，但是很管用，曾經讓我的Silverlight網頁游戲內存穩定并總體降低了1/3。

注意點3：小心事件

在我的團隊里，對于一次性的事件一定要求剪掉（-=），甚至在Dispose()里做判斷，這是因為游戲中大量的隨時創建出來的對象，一直帶著幾個事件跑就不會被GC掉，用調試工具查看過，大多是因為事件中帶著全局或者其他的引用造成。

注意點4：用單例

對于設計模式，沒什么好說的，挺怕被噴，只能說單例用好了是英雄，用不好是狗熊。

注意點5：別用數據綁定

據我所知靖南兄、老馬，我們都吃過數據綁定的虧，數據綁定是一個多么好的東西啊，可是內存消耗真不是玩的，尤其不是你自己寫的控件用上玩數據綁定，那才叫——誰用誰知道！

關于XNA的瘦身策略，可以詳細參看http://msdn.microsoft.com/zh-cn/library/hh855082(v=vs.92).aspx

里面詳細介紹了Image圖像在內存的問題，列舉如和使用2次冪優化，降低質換格式的等方法，對于SoundEffect的銷毀和頂點數據優化等內容，十分不錯。

第三個問題：躲

好吧，當我們的應用程序已經瘦身瘦到無法再瘦，所謂惹不起躲得起，咱們干脆就不支持256MB這樣限定90MB的設備了。

 打開app的WMAppManifest.xml 加入如下代碼：

<Requirements>

<Requirement Name="ID_REQ_MEMORY_90" />

</Requirements>

所謂“你有金銀堆北斗，我在江湖度春秋。”，對于現在這狀況也只能“路逢險處須當避，不是才子莫吟詩”。