JavaScript モジュールの OS.File には、メインスレッド外でファイルを操作するためのプリミティブが含まれています。
よくある質問 (FAQ)
- OS.File とは何か?
- OS.File は、効率的に、メインスレッド外で、特権つき JavaScript コードによりファイルを操作するために設計された新しい API です。この API は、JavaScript コードによるほとんどの XPCOM ベースのファイル操作 (nsIFile、nsIIOService のサブセット、他) を置き換える目的でつくられています。
- HTML5 File API との関係は？
- 全く関係ありません。File API は、Web アプリケーションによる高レベルで制限の多いファイル操作向けに設計されています。OS.File は、Firefox 自身やアドオンにより、効率的に制限なくファイルを操作するために設計されています。
- なぜメインスレッド外の File I/O (入出力) が重要なのか？
-
すべての開発者が覚えておくべきことの一つは、File I/O 操作の遅延に制限がないことです。この遅延は、現在のカーネルの負荷や現在のディスク動作、現在のバスの負荷、現在のディスクの回転速度、バッテリーの残り容量など、それぞれの操作にかかる時間に依存します。私たちは、ファイルを閉じたり最終更新日時を確認したりするなど、些細に見える操作を実行する数秒間についての話をしています。
このファイル操作がメインスレッドで呼び出された場合、すべてのユーザ体験がそこで数秒間つっかえることになり、全く良くありません。 - なぜ I/O 効率が重要なのか？
-
I/O 効率は、実際の I/O 呼び出し回数を最少化することがすべてです。一部のプラットフォーム (スマートフォンやタブレット) が極端に遅いストレージを抱えていることや、あなたのアプリケーションだけでなく潜在的にシステムで実行されているすべてのアプリケーションで I/O 操作が多いことは、プラットフォームに関係なく致命的です。これはユーザ体験のために全く良くありません。最後に、I/O はエネルギー効率の面でも不経済なため、I/O を多用することはバッテリー消費を増やすことになります。
必然的に、OS.File を設計の鍵の一つとして取り入れることは、すべてのプラットフォームが、同じ機能を持っていたり、開発者がそのプラットフォーム向けにアルゴリズムの最適化に使用できるようなシステム固有の情報を与えているとは限らないため、OS.File を使用することにより、開発者にどの I/O も隠さない十分な低レベルの操作を提供する (開発者がより多くの I/O 操作をできるようになる) ことができます。
OS.File の使用方法
... メインスレッドから
OS.File は、多くの場合メインスレッドから使用します。このモードでは、メインスレッドのクライアントが API を使用して、メインスレッド外のファイル I/O を要求します。
- メインスレッドから OS.File を呼び出す
- 非同期、メインスレッド外のファイル I/O、メインスレッド API。
- メインスレッドから OS.File.DirectoryIterator を呼び出す
- 非同期、メインスレッド外のファイルディレクトリへのアクセス、メインスレッド API。
... ワーカースレッドから
場合によっては、OS.File のメインスレッド API の使用は適切ではありません。多くのメッセージ受け渡しを必要とする場合や、ファイル I/O を必要とするコードがワーカースレッド上ですでに実行されている場合があるためです。このような理由で、API のクライアントは、自身のワーカースレッドを生成し、OS.File をそれらのスレッドから直接使用するようにできます。
- ワーカースレッド用の OS.File
- ワーカースレッド用の同期ファイル I/O。
- ワーカースレッド用の OS.File.DirectoryIterator
- ワーカースレッドから直接同期的にディレクトリにアクセスします。
... 共有コンポーネント
- OS.Path と OS.Constants.Path
- パスの操作。
- OS.File.Error
- フィル関連のエラーを提供します。
- OS.File.Info
- ファイル情報 (サイズ、作成日、他) を提供します。
- OS.File.DirectoryIterator.Entry
- ディレクトリへのアクセス中に取得できるファイル情報。