ユーザーが開いたファイルを監視する必要がある Notepad++ や UltraEdit によく似たミニ エディター コンポーネントを作成しています。
開いているファイルを監視するために FileSystemWatcher の複数のインスタンスを使用することは賢明ですか? Notepad++ や UltraEdit のように、またはこれらを管理するためのより良い方法はありますか?
ドキュメントが閉じられると、それらは適切に破棄されます。
申し訳ありませんが、もう1つ、ドライブ用の汎用FileSystemWatcherを作成して監視し、適切なファイルであることがわかったら、ファイルをリロードするようにメッセージを表示する方が賢明でしょうか? それとも遅刻ですか？
複数のFileSystemWatcherで問題が発生することはなく、これを実現する方法は他にありません。
パフォーマンスのために、できるだけ狭いフィルターを指定してください。
FileSystemWatcher には欠点があり、監視フォルダーをロックするため、たとえば、リムーバブル ストレージ上のファイルを監視している場合、「安全なデバイスの取り外し」が妨げられます。
SHChangeNotifyRegisterを介してシェル通知を使用してみることができます。この場合、すべての変更に対して 1 つのエントリ ポイント (必要に応じて複数のエントリ ポイント) が用意されますが、この場合、ネイティブ シェルの相互運用が必要になります。
可能性のあるユースケースによって異なります。
ユーザーが同じディレクトリで複数のファイルを開き、他に何も変更しない可能性が高い場合、ファイルの数が多い場合、そのディレクトリの単一のウォッチャーは、ファイルごとに 1 つよりも負担が少ない可能性があります。
あなたが見つける唯一の方法は、ベンチマークすることです. 確かに、ファイルごとに 1 つを実行すると、ウォッチャーの寿命が大幅に短縮されるため、最初のアプローチにする必要があります。ウォッチャーはシステム スレッド プールでイベントを起動するため、複数のウォッチャーが同時に起動できることに注意してください (設計に影響を与える可能性があります)。
私は確かにドライブごとにウォッチャーを実行しません。積極的なフィルタリングを使用しても、そのようにするとはるかに多くの労力が必要になります。
必要に応じて、複数のウォッチャーを使用しても問題ありません。コメント ShuggyCoUk が言うように、すべてのファイルが同じフォルダーにある場合は、ファイル ウォッチャーを 1 つにまとめることで最適化できます。
はるかに上位のフォルダー (ドライブのルートなど) にファイル ウォッチャーを作成するのはおそらく賢明ではありません。これは、ファイル システムで発生する他の変更から発生するより多くのイベントをコードで処理する必要があり、バッファーに入るのがかなり簡単になるためです。コードがイベントを処理するのに十分な速度でない場合は、オーバーフローします。
filesystemwatcher はネイティブ オブジェクトであり、メモリを固定します。したがって、アプリの寿命とサイズによっては、次のようにメモリの断片化の問題が発生する可能性があります。
コードは、ファイルを開くたびに長時間 (数時間または数日) 実行され、メモリ内にデータのチャンクが作成され、ファイル ウォッチャーがインスタンス化されます。次に、この一時データをクリーンアップしますが、ファイル ウォッチャーはまだそこにあります。それを複数回繰り返した場合 (ファイルを閉じないか、ウォッチャーを破棄するのを忘れた場合)、CLR で移動できない仮想メモリに複数のオブジェクトを作成しただけです。メモリの輻輳が発生する可能性があります。数人のウォッチャーがいる場合、これは大したことではありませんが、数百人以上になる可能性があると思われる場合は、大きな問題になることに注意してください.