針對WindowsPhone開發的一些優化

今天在看一個博客,裏面提到了一些有關性能優化的方法。現在在此記下以備後用。大家也可以去

http://www.cnblogs.com/magicboy110/archive/2010/12/13/1905019.html

看一下整個文章,學習學習!

 

1)

選擇JPG還是PNG格式

一個最簡單的提高性能的方法就是使用合適的圖片格式。Windows Phone 中支持兩種圖片格式:JPG和PNG。通常,JPG格式解碼速度比PNG更快,所以所有情況下都應該優先考慮JPG圖片,除非,圖片要使用透明的情況,此時必須用PNG,因爲JPG不支持透明。

 

 

2)

將多媒體文件的BuildAction設置爲Content

WP7上的多媒體處理針對文件和網絡流做了優化,但是內存流沒有。這就意味着包含在程序中的多媒體文件,如聲音效果等,應當設置其Build ActionContent而不是Resource(關於Content和Resource的區別請參考《BuildAction之Content與Resource》)。當多媒體文件設置爲Content時,安裝後將直接以獨立文件形式存儲在應用程序安裝目錄中。而設置爲Resource時,將存在於Dll文件中,一般使用時還要先將其從Dll文件中釋放出來才能使用。也就說當一個多媒體文件編譯爲Content時可以直接播放。而編譯爲Resource時,在播放前要先將其從Dll中拷貝到一個文件中然後才能播放,這將很大的降低應用程序性能。下面的示意圖展示瞭如何在VS中設置文件的BuildAction。

 

3)

Visibility屬性

當設置一個元素的P:System.Windows.UIElement.Visibility屬性(可見性)爲Collapsed時,Silverlight不會在內存中保持該元素的任何視圖數據,並且不會對元素做任何其他處理。因而,當通過將元素的Visibility設置爲Visible,將元素重新顯示到屏幕上時,必須在視圖樹中重新繪製該元素的視圖。

 

Opacity屬性與位圖緩存

當啓用位圖緩存時,可以通過操作元素的P:System.Windows.UIElement.Opacity(透明度)屬性來控制元素顯示/隱藏以提高程序性能。啓用位圖緩存的方法是設置UI元素的CacheMode屬性爲T:System.Windows.Media.BitmapCache。位圖緩存允許UI元素在首次渲染後將其視圖數據緩存爲位圖。之後再次顯示元素時就可以繞過渲染圖形的過程,直接顯示緩存的位圖。編程中應避免在沒有啓用位圖緩存的情況下操作Opacity屬性,因爲這會降低程序的性能。

當設置一個啓用位圖緩存的UI元素的Opacity爲0時,Silverlight將會在內存中保存一個該元素的顯示位圖。當Opacity被重新設置爲一個非0值時,將會應用標準的填充率。

 

 一般來說使用開啓位圖緩存的Opacity進行控件的隱藏和顯示有更好的性能,但是具體也要通過兩種方法都使用一遍來測試。

另外一提的是,關閉位圖緩存,雖然性能有所削弱,但是由於必須重繪,圖片顯示效果提高。所以我們要在兩者之間權衡。

 

4)

最小化應用程序集的大小

另一個提高應用程序啓動性能的方法是最小化應用程序集的大小。當向Windows Phone應用商店提交應用時,應用中的程序集會被生成簽名,以後程序每次啓動時都會檢查這個簽名。檢查程序集簽名所用的時間會隨着應用程序大小的增加而增加。因爲簽名檢查的結果會被緩存,所以簽名檢查不會影響之後的程序加載速度,程序的第一次加載速度會受到影響。以下一些技巧可以減小程序集的大小。

  • 如果可能,儘量不要將程序中圖片、多媒體、XML文件之類的的資源的BuildAction設置爲Resurce,因爲這樣會使資源編譯到應用程序集中,從而增加程序集大小。一般設置BuildAction爲Content。
  • 通過斜線開頭的路徑設置圖片的URI,如使用“/folder/myImage.jpg”替代“folder/myImage.jpg”。 
  • 使用JPG圖片替代PNG圖片,除非需要使用透明。 
  • 如果程序中使用了本地化,不要將本地化資源包含在主程序集中。爲每種語言創建一個獨立的附加程序集。

5)

將應用程序分解爲多個小程序集 

可以考慮將程序分解爲多個按需加載的小程序集以進一步縮短啓動時間。要實現這個目的,可以在解決方案中新建一個Windows Phone類庫項目專門承載按需加載的頁面。之後在主程序項目中引用該類庫項目。通過HyperLink控件或Navigate方法可以導航到這些頁面。以下代碼示範瞭如何導航到PageInExternalAssembly程序集中的ExternalPage.xaml頁面。

private void button1_Click(object sender, RoutedEventArgs e)

{    

        // Use the name of the separate assembly when generating the Uri for the page    

        NavigationService.Navigate(new Uri("/PageInExternalAssembly;component/ExternalPage.xaml",           

        UriKind.Relative));

}

這就像我在以前博文中說如何改動DatePicker和TimePicker的英文一樣。

 

6)

減少構造函數和Loaded事件中的代碼

所有構造函數和Loaded事件中的代碼都會在應用程序顯示第一幀之前運行。頁面和控件的構造函數解析XAML、實例化XAML中定義的對象是很耗時間的。因此應當限制在這些方法中再執行其他的耗時的操作。如果需要執行載入文件或其他的複雜處理,應當將其延遲到稍後的事件中,或在一個後臺線程中延遲執行。一種方案是在LayoutUpdated的事件處理程序中執行這些耗時的操作。LayoutUpdated事件會在應用程序的第一幀顯示之後才執行。以下示例演示瞭如何操作。

private bool _onNavigatedToCalled = false;

public Page()
{
    InitializeComponent();
    LayoutUpdated += new EventHandler(Page_LayoutUpdated);
}

protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
{
    _onNavigatedToCalled = true;
}

private void Page_LayoutUpdated(object sender, EventArgs e)
{
    if (_onNavigatedToCalled == true)
    {
        _onNavigatedToCalled = false;
        Dispatcher.BeginInvoke(() =>
            {
                // 添加你要做的事
            }
        );
    }           
}

但是大家不能一味地減少兩個函數中的代碼,畢竟一些控件的初始化和數據載入要在首頁面載入之前進行。

7)

監控獨立存儲的使用

P:System.IO.IsolatedStorage.IsolatedStorageSettings.ApplicationSettings對象在第一次使用時(通常是應用程序啓動時)從存儲中加載並反序列化。可以在程序中創建一個包含計時器的幫助屬性以測量反序列化應用程序設置所消耗的時間。如果數據序列化所用時間超過了100毫秒,就應該考慮將該過程移動到一個後臺線程中執行。

如果要用來自獨立存儲的數據填充一個頁面,應該在頁面中創建一個ObservableCollection對象用以保存數據,並立即將該對象綁定到UI元素。然後用來自獨立存儲的數據填充這個ObservableCollection。如果需要,可以通過使用M:System.Windows.Threading.Dispatcher.BeginInvoke(System.Action)方法將數據填充工作分解到多個調用中。

8)

使用Manipulation 事件代替Mouse和Touch事件

Manipulation 事件是推薦的用戶輸入處理方式。從性能和硬件兼容性方面考慮,如果沒有特殊的需求,應當避免在WP7上的Silverlight應用程序中使用Mouse事件。相反,應當用Manipulation 事件來替代。

T:System.Windows.Input.Touch類提供了E:System.Windows.Input.Touch.FrameReported事件用以獲得每個單獨的觸摸點。儘管該事件在Windows Phone 7中仍然支持,但是不推薦用他來處理手勢,如縮放之類。如果不需要獲得每個單獨觸摸點,則應使用Manipulation 事件。

關於如何使用Manipulation 事件的更多信息,請參考How to: Handle Manipulation Events

 

9)

使用PerformanceProgressBar 代替ProgressBar

爲了解決ProgressBar的性能問題,微軟創建了一個替代的PerformanceProgressBar。PerformanceProgressBar將動畫從UI線程移到了構圖線程。

 

 

原作者的博客裏還有許多東西,推薦大家去看看!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章