非同期ファイル I/O 操作によって .NET の UI スレッドがブロックされるのはなぜですか (およびその修正方法)?

非同期ファイル I/O 操作における UI スレッドのブロックへの対処

GUI アプリケーションにおける非同期プログラミングの目標は、UI スレッドのブロックを防ぎ、応答性の高いユーザー エクスペリエンスを保証することです。 ただし、.NET Core 3.1 以前のバージョンでは、非同期ファイル システム API は常にベスト プラクティスに従っているとは限りませんでした。

具体的には、File.ReadAllLinesAsync() は非同期設計にもかかわらず、UI スレッドをブロックする可能性があります。これは、メソッドが推奨される非同期パターン、つまりタスクを返す前の最小限の同期作業を完全に遵守していないためです。

古い .NET バージョンでこの問題を回避するには、GUI アプリケーション内で非同期ファイル システム API を直接使用しないようにしてください。代わりに、同期 API を Task.Run() 内にカプセル化します。 例:

var lines = await Task.Run(() => File.ReadAllLines(@"D:\temp.txt"));

パフォーマンスの観察:

テストにより、File.ReadAllLinesAsync() のブロック動作が明らかになります。 SSD 上の 6MB ファイルを処理すると、古い .NET バージョンでは不完全なタスクが返されるまでに 450 ミリ秒の UI スレッド ブロックが発生しました。

.NET 6 の改善点:

.NET 6 では、非同期ファイル システム API が改善され、ブロッキング時間が約 19 ミリ秒に大幅に短縮されました。 ただし、これらの非同期 API は、対応する同期 API よりも依然として低速 (約 2 倍の速度) であり、完全に非同期ではありません。 したがって、最適なパフォーマンスと UI の応答性を実現するには、Task.Run() でラップされた同期 API を使用することが引き続き推奨されるアプローチです。

以上が非同期ファイル I/O 操作によって .NET の UI スレッドがブロックされるのはなぜですか (およびその修正方法)?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。