私たちのデザイナーは、Blendを使用してWPFアプリケーションのスタイルを設定しています。彼がプロパティにローカルリソースを選択すると、Blendはそれらをの{DynamicResource}代わりに適用します{StaticResource}。私の推測では、Blendがこれを行うのは、アプリを再起動しなくても、実行時にアプリのテーマを変更できるためです。
私の質問は、この追加のルックアップにかなりのパフォーマンスコストがかかるかどうかです。設計者に戻って、それらのダイナミクスを静的に手動で変更するように依頼する必要がありますか？
タイプ間の違いを説明する素晴らしいSOの質問があります：WPFのStaticResourceとDynamicResourceの違いは何ですか？
残念ながら、これは、劣化が現れる場所がWPFエンジンの奥深くにあるため、相対的なパフォーマンスを直接比較することが非常に難しい場合です。WPFの初期には、StaticResourceの使用は推奨された標準のパフォーマンス調整の変更の1つであり、組織内ではかなり厳密にそれに従い、他の人にも推奨する傾向がありました。Blendが設計時に他のファイルからリソースを適切にレンダリングするのに役立ったとしても、Blendがすべてを動的に実行することに本当に腹を立てました。
個人的な経験だけでなく、MicrosoftのBlendチームの人々からのフィードバックもあり、時間の経過とともにこれに対する私の見方は変わりました。ご存知かもしれませんが、Blendは完全にWPFで記述されており、アプリケーションの実行中にオンザフライで切り替えることができる完全な代替テーマ（Light）があります。これが可能なのは、ほとんどすべてのスタイリングにDynamicResourceを使用しているためです。彼らによると、これは実際には実際のパフォーマンスの問題を引き起こしませんでした。Blendがおそらく存在する中で最も広く使用されているWPFアプリケーションであることを考えると、私は彼らの見解にかなりの重みを与える傾向があります。
考慮すべきもう1つのことは、DynamicResourceの実際の有用性です。その場でスタイルを変更する機能はその一部ですが、リソース階層を構築する際の柔軟性により、共有スタイルの管理がはるかに簡単になります。StaticResource参照が指定したリソースが階層の別のブランチにロードされるため、実行時にStaticResource参照が爆発する状況に遭遇したと確信しています。
明らかに、StaticResourceは、適切なタイミングで使用可能になることがわかっている特定のキーを指すのに非常に役立ちます。XAMLを手書きするとき、私はまだそれをいつも使う傾向があります。ただし、デザイナーにBlendでXAMLを生成させることで得られる生産性を考えると、パフォーマンスを少しでも向上させることは、すべてを静的として手動で維持するオーバーヘッドの価値がない可能性があります。
パフォーマンスの違いがあると言われていますが、それが「重要」であるかどうかは、発生している動的ルックアップの数によって異なります。何千ものDynamicResource参照がない限り、どちらの方法でも目立たないでしょう。動的リソースのパフォーマンスが静的リソースよりもはるかに悪い場合、Blendはそれらの生成に関してより保守的であると思います。
実際、単純なテストを実行したところ、DynamicResourceがStaticResourceよりも高速に実行されるという直感に反する結果が見つかりました（3000のリソース参照を使用すると、すべてにDynamicResourceを使用した場合のロード時間は約200ミリ秒でしたが、StaticResourceの場合は約400ミリ秒でした）。
これは多くの理由で非現実的なテストでした。すべての参照が同じものであった、デバッガーで実行していたなどです。しかし、「万が一に備えて」ブレンド出力の変更に力を注ぐのは時期尚早であることを示唆しています。 -そして、速度低下に気付いた場合、それは必ずしもDynamicResource参照のせいではないかもしれません-常に測定してください！
残念ながら、動的リソースを静的に戻すと、Blend が壊れます。これは特に、動的リソースを参照する UserControls を使用する場合に当てはまるようです。それらを静的リソースに変更すると、Blend の別のコントロール内でホストされているときにコントロールがレンダリングされません。