挖掘256MB內存的余地：開發者急需鉆研應用優化
針對該問題Windows Phone團隊詳細列出了應用優化指南，幫助開發者高效的實現針對不同版本Windows Phone的應用優化，具體應用優化方案包括以下幾個方面：
優化啟動時間
確保應用的啟動時間能夠大幅度縮減，開發者在應用渲染完成之前盡可能的延緩其他用戶動作發生的可能性。這就意味著開發者需要最小化App/Page框架下的代碼并且保持Launching/OnNavigatedTo 用戶動作最小化。
例如應用初始化將會花費一定的時間或者依賴網絡相應以及文件的輸入或輸出，那么開發者可以利用進度條的形式來傳達動作信息，同時在不影響頁面布局的情況下調整系統托盤不透明度為0以利用系統托盤ProgressIndicator 來保證最佳性能。
當原始框架渲染完成，在異步操作未完成的情況下開發者可以利用獨立的存儲操作來阻塞UI線程的調用，確保調用異步來保證啟動時用戶界面的快速響應。
由于Frame是由操作系統本身繪制并作為啟動序列的一部分，因而可以適度增加閃屏來延長啟動時間。此外還可以通過從頁面中簡化和去除不必要的XAML以減少受XAML分析的影響，也可以顯著延長啟動。
減少內存使用
在資質認證頁面5.2.5中明確提到在低端設備中應用的內存使用量不得超過90MB，隨著像Lumia 610這樣的設備上市，這些優化工作將會顯得至關重要。
開發者可以利用內存分析器和相關API來分析應用程序的內存使用情況。其首要基本原則為保證在用戶需要的時候進行內存處理，以替代在啟動界面預先加載應用數據。例如，根據需求加載頁面的數據，在內容改變時再進行刷新數據而不是一味的進行全局數據的加載。
注意內存泄漏，例如用戶在使用Win鍵切換至主屏幕時應用并未瑞出，這樣就會出現一個循環的導航切換功能，駐留在內存當中，當用戶利用多任務進行切換時很可能會導致應用由于內存不足而崩潰的現象。為了避免這種循環導航的出現，開發者可以替換掉Win鍵的功能或者利用Windows Phone 7.5提供的會展操作API來解決該問題。
此外，還要確保圖像使用效率，因為當應用程序加載高分辨率圖像到UI界面然后通過縮放來適應較小的Container容器，也將會消耗更多的內存。
處理性能下調
為了保證前臺256MB內存的釋放，通用的后臺代理(PeriodicTasks/ResourceIntensiveTasks)將不可用。
當前Windows Phone終端用戶可以再設置選項里面手動關閉后臺功能，當后臺代理超過限額時，操縱系統將自動終結后臺應用，這些功能都是通過InvalidOperationException來實現的，因而開發者有必要針對Tango設備對該功能進行調整。
按照上面給出的思路來禁用掉上述功能以確保應用的用戶體驗最大限度的不受影響，從而在低端設備正常發揮其性能和特征，開發者可以給予最新版的SDK7.1.1進行debug。
此外，開發者如果希望通過減少/修改功能，以便于在低端設備上的內存需求，可以使用WebBrowserTask和BingMapsTask來替代內存密集型的WebBrowser和Map控件。例如，可以卸載應用程序中占用本地內存的進程，避免在人機交互過程中內存不足而導致應用崩潰的現象。的
用戶輸入響應
用戶總是希望應用程序界面能夠反應靈敏，因而保持UI線程的的動作在不需要的情況下盡可能的處于凍結狀態則顯得非常必要。
為了保證頁面加載時間，在應用被完全渲染之前延緩加載時間同樣至關重要，此外，利用TiltEffect的確認用戶輸入也將使應用程序的外觀和感覺具備原生應用程序的用戶體驗。
許多開發者在應用程序通過添加頁面過渡動畫，來延緩加載時間，這是一個非常值得推薦的做法，但是如果過度畫面會影響到應用程序的穩定性時，開發者則需要將其禁用，尤其是針對低端設備，這樣可以顯著的提高應用程序的性能。
總結
通過上述優化指南，開發者可以輕易地保證用戶能夠獲得良好的用戶體驗，而這些簡單的優化并不僅僅針對低端設備，同樣對于當前的Windows Phone設備一樣可以獲得良好的用戶體驗。同時，合理的利用256MB的SDK工具也將會使得開發者的優化工作更為高效。
【編輯推薦】
