/ resと/ assetsディレクトリの違い

アセットがファイルシステムのように動作する一方で、resディレクトリ内のファイルにアクセスできることは知っていますが、R.class一般的に、どちらを使用するのが最適かを知りたいのです。
誰かが解像度とアセットの本当の違いを知るのを手伝ってくれる？

ここで説明するように、リソースには、さまざまな言語、OSバージョン、画面の向きなどの代替を提供するための組み込みサポートがあります。アセットでは利用できません。また、APIの多くの部分でリソース識別子の使用がサポートされています。最後に、リソースの名前は、コンパイル時にチェックされる定数フィールド名に変換されるため、コードとリソース自体が一致しない可能性が低くなります。それは資産には当てはまりません。

それでは、なぜアセットフォルダがあるのでしょうか。実行時に使用するアセットを計算する場合、それは非常に簡単です。リソースの場合、使用される可能性のあるすべてのリソースIDのリストを宣言し、リストへのインデックスを計算する必要があります。（これは一種の厄介な問題であり、開発サイクルで一連のリソースが変更された場合にエラーが発生する可能性があります。）（編集：を使用して名前でリソースIDを取得できますが、getIdentifierコンパイル時チェックの利点が失われます。）また、リソースではサポートされていないフォルダ階層に編成されます。これは、データを管理する別の方法です。リソースはほとんどのケースをカバーしますが、アセットは時折使用されます。

もう1つの違い：ライブラリプロジェクトで定義されたリソースは、ライブラリに依存するアプリケーションプロジェクトに自動的にインポートされます。資産の場合、それは起こりません。アセットファイルは、アプリケーションプロジェクトのアセットディレクトリに存在する必要があります。[編集：Androidの新しいGradleベースのビルドシステム（Android Studioで使用）では、これは当てはまりません。ライブラリプロジェクトのアセットディレクトリは.aarファイルにパッケージ化されているため、ライブラリプロジェクトで定義されたアセットはアプリケーションプロジェクトにマージされます（そのため/assets、参照されているライブラリにある場合、アプリケーションのディレクトリに存在する必要はありません）。]

編集：カスタムフォントをアプリにパッケージ化する場合は、さらに別の違いが生じます。ファイルシステムまたはアプリのディレクトリに保存されているフォントファイルからを作成するAPI呼び出しがありTypefaceますassets/。ただしTypeface、res/ディレクトリに格納されているフォントファイルから（またはInputStream、res/ディレクトリの使用を許可するから）を作成するAPIはありません。[ 注： Android O（アルファプレビューで利用可能になりました）を使用すると、カスタムフォントをリソースとして含めることができます。説明を参照してくださいここでは、この長期延滞機能の。ただし、最小APIレベルが25以下である限り、カスタムフォントのパッケージ化はリソースとしてではなくアセットとして行う必要があります。]

どちらもかなり似ています。2つの本当の主な違いは、resディレクトリ内の各ファイルには、ID を介して簡単にアクセスできる事前コンパイルされたファイルが与えられることR.id.[res id]です。これは、画像、サウンド、アイコンにすばやく簡単にアクセスするのに役立ちます...

assetsディレクトリには、より多くのファイルシステムのようなもので、あなたがそこに希望の任意のファイルを置くためのより多くの自由を提供します。その後、Javaを介して任意のファイルシステム内の任意のファイルにアクセスする場合と同じように、そのシステム内の各ファイルにアクセスできます。このディレクトリは、ゲームの詳細、辞書などに適しています。お役に立てば幸いです。

私はこれが古いことを知っていますが、明確にするために、公式のAndroidドキュメントにそれぞれの説明があります：

http://developer.android.com/tools/projects/index.htmlから

assets/

これは空です。これを使用して、未加工のアセットファイルを保存できます。ここで保存したファイルは、そのまま.apkファイルにコンパイルされ、元のファイル名は保持されます。URIを使用して通常のファイルシステムと同じ方法でこのディレクトリをナビゲートし、AssetManagerを使用してバイトのストリームとしてファイルを読み取ることができます。たとえば、これはテクスチャやゲームデータに適した場所です。

res/raw/

任意の未加工アセットファイルの場合。assets /ディレクトリではなく、ここにアセットファイルを保存する方法は、アクセス方法が異なるだけです。これらのファイルはaaptによって処理され、Rクラスのリソース識別子を使用してアプリケーションから参照する必要があります。たとえば、これはMP3やOggファイルなどのメディアに適した場所です。

以下は、いくつかの重要なポイントです。

1. 生ファイルには有効なJava識別子である名前が必要ですが、アセット内のファイルには場所と名前の制限はありません。言い換えれば、私たちが望むディレクトリにグループ化することができます
2. 生ファイルxmlだけでなくJavaからも簡単に参照できます（つまり、マニフェストまたは他のxmlファイルから生のファイルを参照できます）。
3. assets /ディレクトリではなく、ここにアセットファイルを保存する方法は、http://developer.android.com/tools/projects/index.htmlに記載されているように、それらにアクセスする方法のみが異なり ます。
4. ライブラリプロジェクトで定義されたリソースは、ライブラリに依存するアプリケーションプロジェクトに自動的にインポートされます。資産の場合、それは起こりません。アセットファイルは、アプリケーションプロジェクトのアセットディレクトリに存在する必要があります
5. アセットディレクトリは、ファイルシステムのようなもので、必要なファイルを自由に配置できます。その後、Javaを介して任意のファイルシステム内の任意のファイルにアクセスする場合と同じように、そのシステム内の各ファイルにアクセスできます。ゲームデータファイル、フォント、テクスチャなど
6. リソースとは異なり、アセットはアセットディレクトリ内のサブフォルダーに整理できます。ただし、アセットで実行できるのは、入力ストリームを取得することだけです。したがって、文字列やビットマップをアセットに保存することはあまり意味がありませんが、入力修正辞書やゲームマップなどのカスタム形式のデータを保存できます。
7. RawはR.javaファイルを生成することでコンパイル時間をチェックできますが、データベースをプライベートディレクトリにコピーする場合は、ストリーミング用に作成されたアセットを使用できます。

結論

1. Android APIには、快適なリソースフレームワークが含まれており、さまざまなモバイルアプリのほとんどの一般的なユースケースにも最適化されています。リソースをマスターし、可能な限りそれらを使用してみてください。
2. ただし、特別なケースにさらに柔軟性が必要な場合は、アセットを使用して、より自由度の高い方法でリソースを整理および処理できる低レベルのAPIを利用できます。

Javaコードのどこかでそれらを参照する必要がある場合は、ファイルを「res」ディレクトリに配置する必要があります。

また、resフォルダー内のすべてのファイルはRファイルでインデックスが作成されるため、ファイルの読み込みがはるかに高速（かつ簡単）になります。

ファイルシステムなどのアセットを使用して、あらゆる種類のファイルをダンプします。そして、resを使用して、レイアウト、画像、値を保存します。

テッド・ホップはこれをかなりうまく答えました。openglテクスチャとシェーダーファイルにres / rawを使用しています。階層構造を提供するために、それらをアセットディレクトリに移動することを考えていました。

このスレッドは私にしないと確信しました。まず、一意のリソースIDを使用するのが好きだからです。2つ目は、InputStream / openRawResourceまたはBitmapFactoryを使用してファイルを読み取るのが非常に簡単であるためです。3つ目は、ポータブルライブラリで使用できると非常に便利だからです。

アセットは、テキスト、xml、フォント、音楽、ビデオなどの任意のファイルをアプリケーションに含める方法を提供します。これらのファイルを「リソース」として含めようとすると、Androidがそれらをリソースシステムに処理し、生データを取得できなくなります。手つかずのデータにアクセスしたい場合、アセットはそのための1つの方法です。