Sé que los archivos en el directorio son accesibles desde mientras que los activos se comportan como un sistema de archivos, pero me gustaría saber, en general, cuándo es mejor usar uno y otro.
¿Alguien puede ayudarme a conocer las diferencias reales entre res y assets?res
R.class
Solución
Con los recursos, hay soporte incorporado para proporcionar alternativas para diferentes idiomas, versiones del sistema operativo, orientaciones de pantalla, etc., como se describe aquí. Nada de eso está disponible con los activos. Además, muchas partes de la API admiten el uso de identificadores de recursos. Finalmente, los nombres de los recursos se convierten en nombres de campo constantes que se comprueban en tiempo de compilación, por lo que hay menos oportunidades de desajustes entre el código y los propios recursos. Nada de eso se aplica a los activos.
Entonces, ¿por qué tener una carpeta de activos? Si desea calcular el activo que desea usar en tiempo de ejecución, es bastante fácil. Con los recursos, tendría que declarar una lista de todos los identificadores de recursos que se podrían usar y calcular un índice en la lista. (Esto es un poco incómodo e introduce oportunidades de error si el conjunto de recursos cambia en el ciclo de desarrollo). (EDITAR: puede recuperar un ID de recurso por nombre mediante getIdentifier
, pero esto pierde las ventajas de la comprobación en tiempo de compilación). Los activos también se pueden organizar en una jerarquía de carpetas, que no es compatible con los recursos. Es una forma diferente de administrar los datos. Aunque los recursos cubren la mayoría de los casos, los activos tienen su uso ocasional.
Otra diferencia: los recursos definidos en un proyecto de biblioteca se importan automáticamente a proyectos de aplicación que dependen de la biblioteca. Para los activos, eso no sucede; los archivos de activos deben estar presentes en el directorio de activos de los proyectos de aplicación. [EDITAR: Con el nuevo sistema de compilación basado en Gradle de Android (utilizado con Android Studio), esto ya no es cierto. Los directorios de activos para proyectos de biblioteca se empaquetan en los archivos .aar, por lo que los activos definidos en los proyectos de biblioteca se combinan en proyectos de aplicación (por lo que no tienen que estar presentes en el directorio de la aplicación si están en una biblioteca referenciada).]/assets
EDITAR: Otra diferencia surge si desea empaquetar una fuente personalizada con su aplicación. Hay llamadas a la API para crear un archivo de fuente almacenado en el sistema de archivos o en el directorio de la aplicación. Pero no hay una API para crear un a partir de un archivo de fuente almacenado en el directorio (o desde un , que permitiría el uso del directorio). [NOTA: Con Android O (ahora disponible en versión preliminar alfa) podrás incluir fuentes personalizadas como recursos. Vea la descripción aquí de esta característica largamente esperada. Sin embargo, siempre que su nivel mínimo de API sea de 25 o menos, tendrá que seguir con el empaquetado de fuentes personalizadas como activos en lugar de como recursos.]Typeface
assets/
Typeface
res/
InputStream
res/
Otras respuestas
Sé que esto es antiguo, pero solo para dejarlo claro, hay una explicación de cada uno en la documentación oficial de Android:
desde http://developer.android.com/tools/projects/index.html
assets/
Esto está vacío. Puede usarlo para almacenar archivos de activos sin procesar. Los archivos que guarda aquí se compilan en un archivo .apk tal cual y se conserva el nombre de archivo original. Puede navegar por este directorio de la misma manera que un sistema de archivos típico mediante URI y leer archivos como una secuencia de bytes mediante AssetManager. Por ejemplo, esta es una buena ubicación para texturas y datos de juegos.
res/raw/
Para archivos de activos sin procesar arbitrarios. Guardar archivos de activos aquí en lugar de en el directorio assets/ solo difiere en la forma en que accede a ellos. Estos archivos son procesados por aapt y deben ser referenciados desde la aplicación utilizando un identificador de recursos en la clase R. Por ejemplo, este es un buen lugar para los medios, como archivos MP3 u Ogg.