第一步開始分析 Phone 7.1 的記憶體使用情況
手機行動裝置的開發 和 一般程式或網站比較起來
有限的資源控制是很重要的一個議題
尤其是現在 Mango 手機有分 256 mb 和 512 mb 的版本
而且每一隻 App 都會區分最大的記憶體使用量
若您的 App 超過 90 mb 的話，那麼就會無法在 256mb的手機上使用
或是 手機一直造成 Memory leak (記憶體一直被吃掉)
也很容易造成系統變慢或是資源釋放過久的情況發生
這都是使用經驗很不好的地方
CPU 最佳化可能還可以自已寫 Health Module 的方式處理
但記憶體就沒那麼簡單了
還好現在 Visual Studio 2010 有提供現成的機制來幫助我們分析
選擇好 256 或是 512 後就可以開始做分析
注意，此分析只能在模擬器中分析，沒有辦法讓您放到手機中執行分析
這裡可以針對「程式的執行效能」以及 「記憶體配置情況」進行收集的動作
我們這次的是選擇記憶體
按下啟動後就可以看到程式會將 App 配置在 模擬器中執行
工具會顯示程式碼正在剖析中
記得要選擇對應的 模擬器 ( 可以選擇 256 或是 512 )
上方圖形分別提供時間軸、記憶體的使用量、圖形載入的時間點 以及 GC 回收時間點 都可以依依看得出來
在最右上角可以放大縮小圖形的比例尺
在圖形上按下右鍵—>全選 就可以看到下面會出現「開始分析」
當然您也可以在圖形中選擇想要分析的範圍。
分析完成後就可以看到下方出現「效能警告」的項目
這裡是會依選擇的範圍中分析程式碼可能的效能問題。 ( 範圍太小的話會導致資料太少無法分析出 )
效能警告右邊有個黑色三角可以依序展開「堆積摘要」
這裡有各種「堆積摘要」(Heap)可以選擇
但效能分析出來後，此程式只有產生以下三種
分別是所有產生新的記憶體配置的「新的配置」
執行過程中所有收集到的記憶體配置的「收集到的配置」
以及程式執行結束後保留下來的記憶體配置的「結束時保留的配置」
各種資訊都可以讓您們做分析判斷，請務必都各自點開來分析
接下來我們先選擇「結束時保留的配置」將 堆積摘要點開後—>選擇「型別」
這時候 VS 2010 就會將目前所有使用的記憶體使用的情況全部列出來
從資料分析來看 String 是裡面佔的比例最高，這一點和程式上是完全一致的
由於 EasyDrink 裡面有 1000 左右的資料，而 DTO 物件 又產生了 6 組
所以光是 String 就有 6000 個以上，這對於整體記憶體來說會有一定的衝擊
選擇了 EasyDrink.Store 這個 DTO 物件後
便可以看到系統所有產生該物件記憶體使用的情況，因為 EasyDrink 的資料量都是一致的
所以這裡產生的位元組都是36 ，而且都是在第一個 GC 1 中
若是對其中的執行個體有任何疑問，再展開「物件圖形」
便可以看到此複雜型別中又包含了那些型別和記憶體使用情況
這一點對於我們了解程式在記憶體中的分配非常重要
另外，除了 DTO 物件外，當然連 Page 都可以解析成「物件圖形」
從這裡可以看到 Page 所有用到的資源和載入的時間點
往下捲可以看到剛剛 DTO 物件在 Page 和 其他物件的使用情況
這裡的大小是指 包含到子物件中所有的記憶體配置
專用大小則是 該物件的記憶體配置 ( 不含子物件 )
參考計數 可以定義為這次配置中的次數
產生 就是說是配置在 GC 中的那些區域位置，越前面越早被釋放
建置時間 和 終結時間就是該物件的生命週期時間
配置方法則是由「XAML」中就配置好的固定成員，這時就會顯示該物件是由誰配置的
雖然真正把記憶體吃掉大半的還是「地圖的圖資」
以程式記憶體最佳化來看，目前有改善的空間還是在程式本身
最後再次提醒，為了不要造成分析上的困擾
請針對單一功能或模組分別執行效能分析
不相干的功能就不要一起執行，分析上也比較有效率
希望這些對於手機有限的資源上會有幫助