O mistério: Estrutura do projeto e sistema de compilação do Android Studio
Não sei se é por causa do Gradle Build System (aposto que é), mas direi o que entendi até agora.
Atualização 4: 2014/09/11 Adicionada folha de referências para BuildTypes, Flavorse Variants(finalmente me sinto confiante para escrever isto: D)
Atualização 3: 2014/09/11 Atualizado os espaços de trabalho e projetos de comparação para ser preciso
Atualização 2: 2014/04/17 Adicionados mais detalhes à estrutura
do projeto AS Atualização 1: 2013/07/29 Adicionada a estrutura do projeto IntelliJ
A estrutura do projeto do IntelliJ (mostrada no final) é para IntelliJ com o plugin do Android. O Android Studio, entretanto, possui uma estrutura de projeto dividida da seguinte forma:
Estrutura: Projetos e Módulos
módulo no Android Studio é como um projeto no Eclipse
projeto no Android Studio é como um espaço de trabalho no Eclipse (para ser preciso, um espaço de trabalho com projetos interdependentes)
Da documentação (o Android Studio é baseado no Intellij IDEA):
O que quer que você faça no IntelliJ IDEA, você o faz no contexto de um projeto. Um projeto é uma unidade organizacional que representa uma solução de software completa.
Seu produto acabado pode ser decomposto em uma série de módulos discretos e isolados, mas é uma definição de projeto que os reúne e os liga em um todo maior.
Para Android, significa um projeto por aplicativo e um módulo por biblioteca e por aplicativo de teste.
Existem vários problemas se você tentar construir vários aplicativos dentro do mesmo projeto. É possível, mas se você tentar (como eu fiz), verá que quase tudo foi projetado para funcionar com um único aplicativo por projeto.
Por exemplo, há uma opção para "reconstruir o projeto", o que não faz sentido com vários aplicativos, muitas outras configurações do projeto seriam inúteis e o sistema VCS integrado não é ótimo quando você tem vários repositórios.
Estrutura: Estrutura da Pasta
Pastas de nível superior
1. Projeto Principal
Isso seria todo o contexto do projeto ( Eclipse Land: como sua área de trabalho, mas limitado ao que é relevante para seu projeto). Ex: HelloWorldProjectse o nome do aplicativo que você deu eraHelloWorld
2. ideia
É onde os metadados específicos do projeto são armazenados pelo Android Studio (AS). ( Eclipse Land: project.properties arquivo)
3. Módulo de Projeto
Este é o projeto real. ex: HelloWorldse o nome do aplicativo que você forneceu foi HelloWorld
4. gradle
É aqui que está o invólucro jar do sistema de compilação do gradle, ou seja, esse jar é como o AS se comunica com o gradle instalado no Windows (o sistema operacional no meu caso).
5. Bibliotecas externas
Esta não é realmente uma pasta, mas um local onde Bibliotecas Referenciadas ( Eclipse Land: Bibliotecas Referenciadas) são mostradas. É aqui que a plataforma direcionada é exibida, etc.
[ Nota lateral: aqui é onde muitos de nós em Eclipse Land costumávamos excluir as bibliotecas referenciadas e Corrigir propriedades do projeto para corrigir erros de referência, lembra?]
Pasta do projeto em detalhes
Este é o número # 3 na lista acima. Tem os seguintes sub dirs
1. construir
Isso tem toda a saída completa do makeprocesso, ou seja, classes.dex, classes e recursos compilados, etc.
Na GUI do Android Studio, apenas algumas pastas são mostradas. O importante é que seu R.java se encontra aqui sobbuild/source/<flavor>/r/<build type(optional)>/<package>/R.java
2. libs
Esta é a pasta libs padrão que você vê no Eclipse Land também
3. src
Aqui, você só vê a pasta javae resque correspondem à srcpasta e à respasta no Eclipse Land . Isso é IMHO simplificação muito bem-vinda.
Nota sobre os módulos:
Módulos são como projetos Eclipse Land . Aqui, a ideia é que você tenha um projeto de aplicativo (Módulo # 3 na lista acima) e vários projetos de biblioteca (como Módulos separados na pasta de projeto global (# 1 na lista acima)) dos quais o projeto de aplicativo depende. Ainda não descobri como esses projetos de biblioteca podem ser reutilizados em outros aplicativos.
[ Nota lateral: toda a reorganização tem alguns benefícios, como simplificações na pasta src, mas muitas complicações. As complicações são principalmente devido à documentação MUITO, MUITO fina sobre este novo layout de projeto.]
O novo sistema de compilação
Guia do usuário para o novo Build System
Explicação de sabores e buildTypes, etc - Sobre o que é essa confusão?
CheatSheet para sabores e buildTypes
BuildType: debug e releaseestão buildTypesdisponíveis por padrão em todos os projetos. Eles são para construir / compilar o MESMO CÓDIGO para gerar APKs diferentes. Por exemplo, em releaseAPKs que você deseja executar o proguard (para ofuscação), assine-o com sua chave (em oposição à chave de depuração), execute otimizações (talvez via proguard ou outras ferramentas), use um pouco diferente packageNames(usamos com.company.productpara releasee com.company.product.debugpara debug), etc. Também usamos um sinalizador de depuração ( BuildConfig.DEBUG) para desligar o log para logcat (uma vez que torna o aplicativo lento) em releasecompilações. Isso torna a debugcompilação mais rápida durante o desenvolvimento, mas também otimizada releasepara colocar na Play Store.
Sabor do produto: Não há sabores padrão disponíveis (ou para ser preciso, o sabor padrão é em branco / sem nome). Flavorspode ser uma versão gratuita ou uma versão paga onde eles têm CÓDIGO DIFERENTE . Eles compartilham o mesmo Maincódigo, mas versões diferentes (ou nenhuma versão) de alguns arquivos de código-fonte ou recursos.
BuildVariant: A buildVarianté a que um APK gerado realmente corresponde. Eles são nomeados assim (na ordem) Product Flavor+ Build Type=Build Variant .
Exemplo 1: se você tem freee paidcomo dois sabores. As variantes de compilação que você obteria são:
Grátis - depuração
grátis - liberação
paga - depuração
paga - liberação São
4 configurações possíveis de APK. Algumas configurações podem não fazer sentido em um projeto específico, mas estão disponíveis.
Exemplo 2: (para novos projetos / sem variações) você tem 2 buildVariantsou APKs disponíveis, uma vez que a variação padrão é sem nome / em branco:
versão de
depuração
A pasta .idea (1) contém várias subpastas, principalmente com informações internas do IntelliJ IDEA.
A pasta src (2) contém o código-fonte do arquivo MyActivity.java (3) que implementa a funcionalidade do seu aplicativo. O arquivo pertence ao pacote com.example.
A pasta res (4) contém vários recursos visuais.
O arquivo layout / main.xml (5) define a aparência da aplicação constituída de recursos de vários tipos.
A pasta de valores (6) destina-se a armazenar arquivos .xml que descrevem recursos de vários tipos. Atualmente, a pasta contém um arquivo strings.xml com definições de recursos de String. Como você verá na seção Adicionando uma cor, a pasta de layout também pode conter, por exemplo, um descritor de cores.
A pasta drawable (7) contém imagens.
A pasta gen (8) contém o arquivo R.java (9) que vincula os recursos visuais e o código-fonte Java. Como você verá nas seções abaixo, o IntelliJ IDEA oferece suporte à integração estreita entre recursos estáticos e R.java. Assim que quaisquer recursos são adicionados ou removidos, as classes e campos de classe correspondentes em R.java são gerados automaticamente ou removidos de acordo. O arquivo R.java também pertence ao pacote com.example.
