Respostas:
Com recursos, há suporte interno para fornecer alternativas para diferentes idiomas, versões de SO, orientações de tela etc., conforme descrito aqui . Nada disso está disponível com ativos. Além disso, muitas partes da API suportam o uso de identificadores de recursos. Por fim, os nomes dos recursos são transformados em nomes de campo constantes que são verificados no momento da compilação, para que haja menos oportunidades de incompatibilidade entre o código e os próprios recursos. Nada disso se aplica aos ativos.
Então, por que ter uma pasta de ativos? Se você deseja calcular o ativo que deseja usar em tempo de execução, é muito fácil. Com os recursos, você teria que declarar uma lista de todos os IDs de recursos que poderiam ser usados e computar um índice na lista. (Isso é meio estranho e apresenta oportunidades de erro se o conjunto de recursos mudar no ciclo de desenvolvimento.) (EDIT: você pode recuperar um ID de recurso por nome usando getIdentifier
, mas isso perde os benefícios da verificação em tempo de compilação.) também ser organizado em uma hierarquia de pastas, que não é suportada por recursos. É uma maneira diferente de gerenciar dados. Embora os recursos abranjam a maioria dos casos, os ativos têm seu uso ocasional.
Outra diferença: os recursos definidos em um projeto de biblioteca são importados automaticamente para projetos de aplicativos que dependem da biblioteca. Para ativos, isso não acontece; os arquivos de ativos devem estar presentes no diretório de ativos dos projetos de aplicativos. [EDIT: Com o novo sistema de compilação baseado no Gradle do Android (usado com o Android Studio), isso não é mais verdade. Os diretórios de ativos para projetos de bibliotecas são compactados nos arquivos .aar; portanto, os ativos definidos nos projetos de bibliotecas são mesclados em projetos de aplicativos (para que eles não precisem estar presentes no /assets
diretório do aplicativo se estiverem em uma biblioteca referenciada).]
EDIT: Existe outra diferença se você deseja compactar uma fonte personalizada com seu aplicativo. Existem chamadas de API para criar a Typeface
partir de um arquivo de fonte armazenado no sistema de arquivos ou no assets/
diretório do seu aplicativo . Mas não há API para criar a Typeface
partir de um arquivo de fonte armazenado no res/
diretório (ou de um InputStream
, o que permitiria o uso do res/
diretório). [ NOTA: Com o Android O (agora disponível na visualização alfa), você poderá incluir fontes personalizadas como recursos. Veja a descrição aqui deste recurso atrasado. No entanto, desde que o seu nível mínimo de API seja 25 ou menos, você terá que empacotar fontes personalizadas como ativos e não como recursos.]
raw/
diretório?
/res
diretórios e '/ assets' é somente leitura, pois são empacotados no arquivo .apk.
Ambos são bem parecidos. A principal diferença real entre os dois é que no res
diretório cada arquivo recebe uma pré-compilação ID
que pode ser acessada facilmente R.id.[res id]
. É útil para acessar rápida e facilmente imagens, sons, ícones ...
O assets
diretório é mais como um sistema de arquivos e oferece mais liberdade para colocar qualquer arquivo que você quiser lá. Você pode acessar cada um dos arquivos nesse sistema como faria ao acessar qualquer arquivo em qualquer sistema de arquivos por meio de Java. Este diretório é bom para coisas como detalhes de jogos, dicionários, etc. Espero que ajude.
Assets
pasta, o sistema Android agora contém o fonts
diretório e podemos colocar nosso arquivo de fontes personalizadas lá ou podemos fazer o download do Android studio para nós.
Eu sei que isso é antigo, mas apenas para deixar claro, há uma explicação de cada um na documentação oficial do Android:
em http://developer.android.com/tools/projects/index.html
assets/
Isto está vazio. Você pode usá-lo para armazenar arquivos de ativos brutos. Os arquivos que você salva aqui são compilados em um arquivo .apk como estão e o nome do arquivo original é preservado. Você pode navegar neste diretório da mesma maneira que um sistema de arquivos típico usando URIs e ler arquivos como um fluxo de bytes usando o AssetManager. Por exemplo, este é um bom local para texturas e dados de jogos.
res/raw/
Para arquivos de ativos brutos arbitrários. Salvar arquivos de ativos aqui em vez de no diretório assets / difere apenas na maneira como você os acessa. Esses arquivos são processados pelo aapt e devem ser referenciados no aplicativo usando um identificador de recurso na classe R. Por exemplo, este é um bom lugar para mídia, como arquivos MP3 ou Ogg.
A seguir estão alguns pontos-chave:
Conclusão
Se você precisar encaminhá-los para algum lugar do código Java, deverá colocar seus arquivos no diretório "res".
E todos os arquivos na pasta res serão indexados no arquivo R, o que torna muito mais rápido (e muito mais fácil!) Carregá-los.
Ted Hopp respondeu isso muito bem. Eu tenho usado res / raw para meus arquivos de textura e sombreamento opengl. Eu estava pensando em movê-los para um diretório de ativos para fornecer uma organização hierárquica.
Essa discussão me convenceu a não fazê-lo. Primeiro, porque gosto do uso de um ID de recurso exclusivo. Segundo, porque é muito simples usar InputStream / openRawResource ou BitmapFactory para ler o arquivo. Terceiro, porque é muito útil poder usar em uma biblioteca portátil.
Os ativos fornecem uma maneira de incluir arquivos arbitrários como texto, xml, fontes, música e vídeo em seu aplicativo. Se você tentar incluir esses arquivos como "recursos", o Android os processará em seu sistema de recursos e você não poderá obter os dados brutos. Se você deseja acessar dados intocados, os Ativos são uma maneira de fazê-lo.
res/raw
, poderá acessar os dados brutos usando openRawResource(resourceName)
.
res
significa recursos, então o queassets
significa?