Unterschied zwischen den Verzeichnissen /res und /assets

Ich weiß, dass Dateien in der res Verzeichnis zugänglich sind R.class Während sich Assets wie ein Dateisystem verhalten, würde ich im Allgemeinen gerne wissen, wann es am besten ist, das eine und das andere zu verwenden.
Kann mir jemand helfen, die wirklichen Unterschiede zwischen Res und Assets zu kennen?

Bei den Ressourcen gibt es eine integrierte Unterstützung für die Bereitstellung von Alternativen für verschiedene Sprachen, Betriebssystemversionen, Bildschirmausrichtungen usw., wie beschrieben Hier. Nichts davon ist mit Vermögenswerten verfügbar. Außerdem unterstützen viele Teile der API die Verwendung von Ressourcenkennungen. Schließlich werden die Namen der Ressourcen in konstante Feldnamen umgewandelt, die zur Kompilierzeit überprüft werden, sodass die Wahrscheinlichkeit von Nichtübereinstimmungen zwischen dem Code und den Ressourcen selbst geringer ist. Nichts davon gilt für Vermögenswerte.

Warum also überhaupt einen Assets-Ordner haben? Wenn Sie das Asset berechnen möchten, das Sie zur Laufzeit verwenden möchten, ist dies ziemlich einfach. Bei Ressourcen müssten Sie eine Liste aller Ressourcen-IDs deklarieren, die möglicherweise verwendet werden, und einen Index in die Liste berechnen. (Dies ist etwas umständlich und führt zu Fehlermöglichkeiten, wenn sich der Satz von Ressourcen im Entwicklungszyklus ändert.) (BEARBEITEN: Sie können eine Ressourcen-ID nach Namen abrufen, indem Sie getIdentifier, aber dadurch gehen die Vorteile der Überprüfung zur Kompilierzeit verloren.) Assets können auch in einer Ordnerhierarchie organisiert werden, was von Ressourcen nicht unterstützt wird. Es ist eine andere Art, Daten zu verwalten. Obwohl Ressourcen die meisten Fälle abdecken, werden Vermögenswerte gelegentlich verwendet.

Ein weiterer Unterschied: In einem Bibliotheksprojekt definierte Ressourcen werden automatisch in Anwendungsprojekte importiert, die von der Bibliothek abhängen. Bei Vermögenswerten passiert das nicht; Asset-Dateien müssen im Assets-Verzeichnis der Anwendungsprojekte vorhanden sein. [EDIT: With Android’s new Gradle-based build system (used with Android Studio), this is no longer true. Asset directories for library projects are packaged into the .aar files, so assets defined in library projects are merged into application projects (so they do not have to be present in the application’s /assets directory if they are in a referenced library).]

BEARBEITEN: Ein weiterer Unterschied ergibt sich, wenn Sie eine benutzerdefinierte Schriftart mit Ihrer App verpacken möchten. Es gibt API-Aufrufe ein zu erstellen Typeface aus einer Schriftartdatei, die im Dateisystem oder in Ihrer App gespeichert ist assets/ Verzeichnis. Aber es gibt keine API, um eine zu erstellen Typeface aus einer Schriftartdatei, die in der res/ Verzeichnis (oder aus einer InputStreamwas die Verwendung von ermöglichen würde res/ Verzeichnis). [NOTE: With Android O (now available in alpha preview) you will be able to include custom fonts as resources. See the description here of this long-overdue feature. However, as long as your minimum API level is 25 or less, you’ll have to stick with packaging custom fonts as assets rather than as resources.]

Beide sind ziemlich ähnlich. Der wirkliche Hauptunterschied zwischen den beiden ist der in der res Verzeichnis erhält jede Datei eine vorkompilierte Datei ID die leicht zugänglich sind R.id.[res id]. Dies ist nützlich, um schnell und einfach auf Bilder, Sounds, Symbole usw. zuzugreifen.

Der assets Verzeichnis ist eher wie ein Dateisystem und bietet mehr Freiheit, jede gewünschte Datei dort abzulegen. Sie können dann auf jede der Dateien in diesem System zugreifen, als ob Sie über Java auf eine beliebige Datei in einem beliebigen Dateisystem zugreifen würden. Dieses Verzeichnis ist gut für Dinge wie Spieldetails, Wörterbücher usw. Hoffentlich hilft das.

Ich weiß, dass dies alt ist, aber um es klarzustellen, gibt es eine Erklärung für jedes in der offiziellen Android-Dokumentation:

von http://developer.android.com/tools/projects/index.html

assets/

Das ist leer. Sie können es verwenden, um Raw-Asset-Dateien zu speichern. Dateien, die Sie hier speichern, werden unverändert in eine APK-Datei kompiliert, und der ursprüngliche Dateiname bleibt erhalten. Sie können in diesem Verzeichnis wie in einem typischen Dateisystem mit URIs navigieren und Dateien mit dem AssetManager als Byte-Stream lesen. Dies ist beispielsweise ein guter Speicherort für Texturen und Spieldaten.

res/raw/

Für beliebige Raw-Asset-Dateien. Das Speichern von Asset-Dateien hier statt im Verzeichnis assets/ unterscheidet sich nur in der Art und Weise, wie Sie darauf zugreifen. Diese Dateien werden von aapt verarbeitet und müssen von der Anwendung unter Verwendung einer Ressourcenkennung in der R-Klasse referenziert werden. Dies ist beispielsweise ein guter Ort für Medien wie MP3- oder Ogg-Dateien.

Nachfolgend einige Kernpunkte:

1. Raw-Dateien müssen Namen haben, die gültige Java-Kennungen sind, während Dateien in Assets keine Standort- und Namensbeschränkungen haben. Mit anderen Worten, sie können in beliebigen Verzeichnissen gruppiert werden
2. Raw-Dateien Auf diese kann sowohl von Java als auch von XML aus leicht verwiesen werden (dh Sie können eine Datei in Raw aus dem Manifest oder einer anderen XML-Datei referenzieren).
3. Das Speichern von Asset-Dateien hier statt im Verzeichnis assets/ unterscheidet sich nur in der Art und Weise, wie Sie darauf zugreifen, wie hier dokumentiert
   http://developer.android.com/tools/projects/index.html.
4. In einem Bibliotheksprojekt definierte Ressourcen werden automatisch in Anwendungsprojekte importiert, die von der Bibliothek abhängen. Bei Vermögenswerten passiert das nicht; Asset-Dateien müssen im Assets-Verzeichnis der Anwendungsprojekte vorhanden sein
5. Das Assets-Verzeichnis ähnelt eher einem Dateisystem, das mehr Freiheit bietet, jede beliebige Datei dort abzulegen. Sie können dann auf jede der Dateien in diesem System zugreifen, als ob Sie über Java auf jede Datei in einem beliebigen Dateisystem zugreifen würden. wie Spieldatendateien, Schriftarten, Texturen usw.
6. Im Gegensatz zu Ressourcen können Assets in Unterordnern im Assets-Verzeichnis organisiert werden. Das einzige, was Sie mit einem Asset tun können, ist jedoch, einen Eingabestrom zu erhalten. Daher ist es nicht sehr sinnvoll, Ihre Zeichenfolgen oder Bitmaps in Assets zu speichern, aber Sie können Daten in benutzerdefinierten Formaten wie Eingabekorrekturwörterbücher oder Spielkarten speichern.
7. Raw kann Ihnen eine Überprüfung der Kompilierungszeit geben, indem es Ihre R.java-Datei generiert. Wenn Sie Ihre Datenbank jedoch in ein privates Verzeichnis kopieren möchten, können Sie Assets verwenden, die für das Streaming erstellt wurden.

Fazit

1. Die Android-API enthält ein sehr komfortables Ressourcen-Framework, das auch für die meisten typischen Anwendungsfälle für verschiedene mobile Apps optimiert ist. Sie sollten Ressourcen beherrschen und versuchen, sie wo immer möglich zu nutzen.
2. Wenn Sie jedoch mehr Flexibilität für Ihren speziellen Fall benötigen, bietet Ihnen Assets eine API auf niedrigerer Ebene, die es Ihnen ermöglicht, Ihre Ressourcen mit einem höheren Freiheitsgrad zu organisieren und zu verarbeiten.

Wenn Sie irgendwo im Java-Code auf sie verweisen müssen, legen Sie Ihre Dateien lieber in das Verzeichnis “res” ab.

Und alle Dateien im res-Ordner werden in der R-Datei indiziert, was das Laden viel schneller (und viel einfacher!) macht.

Verwenden Sie Assets wie ein Dateisystem, um jede Art von Dateien zu sichern. Und verwenden Sie res, um zu speichern, wofür es gemacht wurde, Layouts, Bilder, Werte.

Ted Hopp hat das ganz nett beantwortet. Ich habe res/raw für meine OpenGL-Textur- und Shader-Dateien verwendet. Ich habe darüber nachgedacht, sie in ein Assets-Verzeichnis zu verschieben, um eine hierarchische Organisation bereitzustellen.

Dieser Thread hat mich davon überzeugt. Erstens, weil ich die Verwendung einer eindeutigen Ressourcen-ID mag. Zweitens, weil es sehr einfach ist, InputStream/openRawResource oder BitmapFactory zu verwenden, um die Datei einzulesen. Drittens, weil es sehr nützlich ist, es in einer tragbaren Bibliothek verwenden zu können.