Image Tips for Windows Phone 7

在開發WP7程式過程中，會遇到在UI上使用用大量的Image這種情況。你可能會以為使用Image是一個很簡單的事情，不需要用一篇部落格的篇幅的介 紹：僅僅設定一個Uri給Image的Source屬性就完成了？但是，還有其他的事情需要考慮呢。這裡有許多的小細節如果你知道到的話，會對的你的程式 有協助，特別是當希望開發出的軟體能夠有較好的體驗和較少的記憶體使用量(移動開發這點很重要)。這些小的提示，不僅適用WP7手機開發，同樣也適用 SilverLight傳統型程式。但是在手機開發中，把握住那些能夠把一個好的程式變成一個優秀的程式效能細節是非常重要的技能。為了指出這一點，這裡舉 出一個實現了這些小細節的樣本。

JPG VS PNG

     如果要在JPG和PNG之間做個選擇，那為你的所有不透明的圖片都使用JPG吧。Window Phone 7作業系統上的JPG解碼器相比之下要比PNG解碼器快很多。當然，如果你的圖片需要是透明的，那PNG是你唯一的選擇了。

Resource vs
Content

     在Visual Studio中把“Build
Type”設定成“Resource”或者“Content”，圖片都會編譯成Window Phone
XAP檔案的一部分。由於他們都被打包到XAP中，起初可能你看不出他倆有什麼區別，貌似都是一路貨色。但當你撬開XAP的外殼(重新命名為.zip檔案並
解壓縮)：那是你可以看到所有的“Content”類型檔案，卻找不著“Resource”類型檔案。為什嗎？因為“Resource”類型的檔案嵌到了
程式集裡了(也就是dll檔案裡)。那麼，我們為何又如此關心“Resource”檔案到底是嵌到哪兒去了。這是因為你的程式的DLL包越大，你的程式啟
動就會越慢。但另一方面，跟圖片從磁碟載入相比，嵌入DLL的圖片載入會更快速。

Summary：設定成”Content“會讓程式啟動更快，設定成”Resource“會讓程式更快的響應。

     還有值得一提的就是他們有著不同的URI格式，可以參考下面的例子：

 

           Content: <Image Source="/ImagesAsContent/smiley1.png"/> 

           Resource: <Image Source="..\ImagesAsResource\smiley3.png"/> 

Async vs.Sync Loading of images

如果你專研過Imaging API 你會發現BitmapImage這個類，在建立一個Image的時候BitmapImage會在幕後做很多的工作。它能以兩種模式載入內容：

 
BitmapImage.UriSource = uriSource; // loads the image via URI, asynchronously
  BitmapImage.SetSource(stream);     // loads the image from stream, synchronously

注意到非同步載入圖片並不意味著完全的off-thread。這是因為有關圖片的解碼是發生在UI線程上的。關於在保持UI線程響應的情況下，非同步載入圖片的詳細資料參考David Anson的部落格.

下面是一些關於同步vs非同步載入的知識：

     1.如果同步載入一張不正確的圖片檔案，將會得到一個異常。

     2.如果非同步載入一張不正確的圖片檔案，ImageFailed事件會觸發。

     3.如果非同步載入一張正確的圖片檔案，ImageOpened事件會觸發。

     4.如果同步載入一張正確的圖片檔案，ImageOpened事件不會觸發。

它們的不同可以通過我給出的範例程式碼示範（在Loading頁面裡）

Image Caching 

這是圖片比較重要的一個方面，MSDN對於它的記錄也很少。在WP7
Platform中即使清空了Source屬性並且把Image從visual
tree中去除，Image的記憶體還是不會釋放，其實這時你看到的是圖片的緩衝。這是一個預留的效能最佳化，是為了避免一遍又一遍的載入和解碼相同的圖片。
WP7中在記憶體中開闢了一個緩衝區，我們可以利用它方便快捷的再利用圖片資源。這裡與瀏覽器的緩衝類似。

雖然 圖片緩衝對於提高效能有很大的協助，但是有時候也會增加不必要的記憶體消耗。特別是還回收再利用那些不會再顯示的圖片。在程式的運行過程中，圖片緩衝會一直佔用記憶體空間。不過也可以通過下列代碼刪除緩衝資訊：

  BitmapImage bitmapImage = image.Source as BitmapImage;

  bitmapImage.UriSource = null;

  image.Source = null;

合理的利用上述代碼可以減少記憶體使用量。而減少記憶體使用量在手機開發中對於效能有較大的協助。在樣本程式裡，在“Caching”頁面中監視了顯示和清除緩衝的記憶體使用量情況，在樣本中可以看到有3MB的記憶體差異。

BitmapCreateOptions

這
是
一個快速而且很有意思的部分。建立一個BitmapImage的時候，你有可能會有這樣的疑問：為什麼當你認為已經完成圖片建立時仍不會返回圖片的大小
呢？這是因為CreateOptions
屬性預設被設定成了“DelayCreation”，也就是說當BitmapImage被設定成一個Image的Source屬性上或者是視覺化樹狀結構的
ImageBrush上，這個對象只有在真正需要它的時候才會被建立。這裡就允許在程式開始啟動並執行時候Creating很多的BitmapImage，卻
不消耗任何的資源（CPU或者是記憶體）直到程式需要特定的圖片才會真正建立它們。如果你想強制的立即執行建立操作，把CreateOptions設定成
“None”即可。CreateOptions 還有一個值是“IgnoreImageCache”，這個值在很多的情境中都不是很有用，而且他還需要和
設計工具結合（如Blend）。

在樣本程式裡，在“CreateOptions”頁面中，通過Create/Show/Clear控制CreateOptions的值為DelayCreation，None並監視圖片大小的變化。

Custom Decoding

在
有關映像的API中都是以圖片自身的解析度解碼（除了Downsampling縮減像素採樣，等會兒會介紹到它）。不管怎樣，這已經能滿足在手機上的圖片
顯示了。如果下載一批320X320的圖片，但只以32X32那麼小顯示，那麼還以原解析度解碼就會浪費很對的記憶體資源。

在 Windows Phone平台上提供給程式員們PictureDecoder的應用程式介面，能夠自訂解析度去解碼圖片：

image.Source = PictureDecoder.DecodeJpeg(jpgStream,
192, 256);

Note：在當前發布的API中有一個bug，圖片的高度和寬度屬性值被交換了。因此，得把寬度的值設定到高度上，高度同理。這個問題以後MS肯定會修複，我也是無意間發現的這個問題。

為了查看記憶體增長情況，在樣本程式的“Custom Decoding”頁面中。在兩種的解析度中監視記憶體使用量情況。

Auto Downsampling

這是最後一個在處理WP7平台圖片我們需要知道的事。background是一個特殊的元素，被限定到2048X2048。超過此大小的會被剪裁，這就意味著使用一個長寬超過2048像素的的圖片，該圖片不會完全顯示。為了避免這種情況的發生，WP7平台會自動的降低像素是圖片去適應2048X2048。這一點不同於案頭Silverlight應用，應為silverlight不存在上述限制。

在樣本程式中我使用了一張3000X2102解析度的圖片，最終圖片被像素縮減為1500X1051。

事實上，關於圖片還有很多值得細細研究的，這裡只是起一個拋磚引玉的作用，希望能和大家一起探討這個問題。謝謝你能閱讀這篇文章，希望能對你有所協助。

能力有限，如果有錯誤的地方請指正。