DynamicResource而不是StaticResource是否有顯着的性能成本？

我們的設計師正在使用Blend來設計我們的WPF應用程序。當他選擇當地資源作爲物業時，Blend將把它們作爲{DynamicResource}而不是{StaticResource}。我的猜測是Blend會這樣做，因爲它可以讓應用程序在運行時重新進行主題化，而無需重新啓動它。DynamicResource而不是StaticResource是否有顯着的性能成本？

我的問題是：這個額外的查找是否有顯着的性能成本？我們是否應該要求設計師回去手動將這些Dynamics改爲靜力學？

這是一個偉大的SO問題，說明各類型之間的區別：What's the difference between StaticResource and DynamicResource in WPF?

來源

2010-02-12 scobi

不幸的是，這是一種很難直接比較相對性能的情況，因爲在WPF引擎中會出現任何降級的地方。在WPF早期，StaticResource的使用是推薦的標準性能調整變化之一，我們傾向於在組織中嚴格遵循它，並將其推薦給其他人。我真的很煩惱Blend做了Dynamic，儘管它幫助它在設計時正確地渲染其他文件的資源。

隨着時間的推移，我對此的看法已經發生了變化，這歸因於個人經驗，還有微軟Blend團隊人員的反饋。正如你可能知道的，Blend完全是用WPF編寫的，並且有一個完整的替代主題（Light），可以在應用程序運行時隨時切換。這是可能的，因爲他們使用DynamicResource幾乎所有的樣式。據他們說，這並沒有真正引起他們任何真正的性能問題。鑑於Blend可能是目前使用最廣泛的WPF應用程序，我傾向於重視他們的觀點。

要考慮的另一件事是DynamicResource的實際用處。動態更改樣式是其中的一部分，但它在構建資源層次結構時的靈活性可以使管理共享樣式變得更加容易。我相信你遇到了StaticResource引用在運行時崩潰的情況，因爲它指向的資源將被加載到層次結構的不同分支中。

顯然，StaticResource對指向您知道在適當時間可用的特定鍵非常有用。當手寫XAML時，我仍然傾向於一直使用它。但是，考慮到設計者在Blend中生成XAML所帶來的生產效率，您可能獲得的任何小的性能增益可能不值得將所有內容手動維護爲Static的開銷。

來源

2010-02-12 01:24:14

關於您的語句「很顯然，StaticResource對於指向特定的鍵非常有用，你知道會在正確的時間提供。「這是否意味着DynamicResource會丟失編譯時類型檢查並將其移至運行時？ – scobi 2010-02-12 05:44:17

是的。在大多數情況下，一個未解析的DynamicResource引用只會得到一個默認值（比如Black for Brushes），然後等待它尋找顯示的密鑰。編譯器沒有任何方法可以自行驗證這種情況。 – 2010-02-12 13:42:53

這是非常有益的，謝謝！ – 2012-05-24 06:45:11

有被說成是一個性能上的差異，但無論是「顯著」將取決於許多動態查找正在發生。除非有成千上萬的DynamicResource引用，否則它可能不會被注意到;如果動態資源的表現比靜態資源差得多，我懷疑Blend在生成它們時會更加保守。

事實上，當我跑了天真的測試中，我發現了違反直覺的結果是DynamicResource跑快比靜態資源（3000個資源引用，我看到身邊200ms的加載時間，當我用DynamicResource一切與400毫秒左右爲靜態資源）。

這是一個不切實際的測試，原因很多：所有引用都是同一個東西，我在調試器下運行，等等等等。但是它表明現在嘗試改變Blend輸出結果爲時尚早在情況下「 - 並且如果你注意到減速，它可能不一定是DynamicResource參考的錯誤 - 總是測量！

來源

2010-02-12 01:23:13 itowlson

我認爲DynamicResouces加載在一個backgrond線程上，並且只在使用它們的項目變得易於使用時才加載，因此非常難以測試速度 – 2010-02-12 12:21:14

不幸的是，如果您將動態資源更改回靜態，它將打破Blend。這似乎是真實的，尤其是當使用引用動態資源的UserControl時，如果將它們更改爲靜態，則當在Blend中的另一個控件內託管時，控件將不會呈現。

來源

2010-02-12 06:01:26

DynamicResource而不是StaticResource是否有顯着的性能成本？

回答

相關問題