2

私は Windows ストア アプリを構築し、同時に XAML を学習しています。GridView に表示したい http URI にリモート イメージがあります。

私の最初の解決策HttpClientでは、URI からイメージ バイト配列をダウンロードし、 を取得しRandomAccessStreamReference、 を構築しBitmapImage、XAMLImageコントロールのソース プロパティを構築された に設定しましたBitmapImage。ただし、このソリューションはかなり遅いことが判明しました (1 つの画像を取得するのに 1 ～ 2 秒)。

私の次の解決策は、生の URI を XAMLImageコントロールのソース プロパティに直接バインドすることでした。これは、XAML エンジンが解決するためにそれ自体を引き受けるようです。約 8 ～ 10 枚の画像を読み込むのに 10 秒かかっていたものが、突然瞬時に読み込まれました。

ImageXAMLコントロールの既定の URI コンバーターがリモートの画像データを正確に解決する方法を知っている人はいますか? 私の最初の解決策の実装が不十分だった可能性は十分にありますが、その不一致は私の好奇心をそそるほど大きいものです。

4

1 に答える 1

3

クラスから適切なコードを見つけたと仮定するとImageSourceConverter、ソースを文字列として指定すると、コンバーターはこれを実行しようとします。

    if (((value is string) && !string.IsNullOrEmpty((string) value)) || (value is Uri))
    {
        UriHolder uriFromUriContext = TypeConverterHelper.GetUriFromUriContext(context, value);
        return BitmapFrame.CreateFromUriOrStream(uriFromUriContext.BaseUri, uriFromUriContext.OriginalUri, null, BitmapCreateOptions.None, BitmapCacheOption.Default, null);
    }

BitmapFrame次に、 a を使用しBitmapDecoderてイメージをロードします。ソースが の場合、 はUri一連BitmapDecoderのセキュリティおよびサニティ チェックの中で、WpfWebRequestHelper(文書化されていない) を使用してイメージを要求または「ダウンロード」します。結果の応答ストリームが有効なファイルである場合は、ストリームを新しい に直接ロードしますFileStream。

その後、ネイティブの Windows 画像デコード機能が引き継ぎ、画像を取得します。また、 がキャッシュされることにも注意してBitmapDecoderください。したがって、複数の画像を続けてロードする場合、新しい を再初期化するオーバーヘッドはありませんBitmapDecoder。それがパフォーマンスの問題と関係があるかどうかはわかりません。

結論として、WPF が画像をロードするために内部的に使用する方法は、高度に最適化された方法であると推測しています。HttpClientの実装とイメージをダウンロードするための単純な使用の可能性については調べていませんがHttpWebRequest、メソッドのオーバーヘッドが組み込みメソッドのオーバーヘッドよりも大きく、パフォーマンスの低下の原因であると思われます。

どうやってこの情報を解読できたのか疑問に思われているかもしれませんが、Reflectorというツールを使用して、アセンブリのSystem.Windows.Media名前空間内のいくつかのクラスを調べただけです。PresentationCore

于 2012-11-27T18:57:18.047 に答える