Próbuję nauczyć się programowania na Androida i początkowo jestem zdezorientowany różnymi strukturami projektów między Eclipse i Android Studio. Utrudnia to śledzenie samouczków zaprojektowanych dla Eclipse. Czy ktoś mógłby mi powiedzieć, dlaczego istnieją te różnice? Czy powinny istnieć?

Na przykład, gdybym miał zlokalizować plik R.java w dwóch różnych IDE, ścieżki wyglądałyby następująco:

Eclipse: app \ gen \ com.example.app \ R.java

Android Studio: app \ build \ source \ r \ debug \ com.example.app \ R.java

Dlaczego te ścieżki są różne? Dlaczego moja R.java znajduje się w folderze debugowania w Android Studio? Prowadzi to do pewnych błędów na wczesnym etapie i jeśli ktoś ma wgląd w te różnice, byłbym wdzięczny.

Tajemnica: struktura projektu i system kompilacji Android Studio

Nie wiem, czy dzieje się tak z powodu Gradle Build System (założę się, że tak), ale powiem ci, co zrozumiałem do tej pory.

Aktualizacja 4: 11/09/2014 Dodane Ściągawka dla BuildTypes, Flavorsi Variants(I w końcu czuć się pewnie napisać: D)
Update 3: 11.09.2014 Aktualizacja obszarów roboczych i projektów porównawcze dokładniej
Aktualizacja 2: 17.04.2014 Dodano więcej szczegółów do struktury projektu AS
Aktualizacja 1: 2013/07/29 Dodano strukturę projektu IntelliJ

Struktura projektu IntelliJ (pokazana na końcu) jest przeznaczona dla IntelliJ z wtyczką dla Androida. Jednak Android Studio ma strukturę projektu podzieloną w następujący sposób:

Struktura: projekty i moduły

moduł w Android Studio jest jak projekt w Eclipse

projekt w Android Studio jest jak obszar roboczy w Eclipse (a dokładnie obszar roboczy z współzależnymi projektami)

Z dokumentacji (Android Studio bazuje na Intellij IDEA):

Cokolwiek robisz w IntelliJ IDEA, robisz to w kontekście projektu. Projekt to jednostka organizacyjna reprezentująca kompletne rozwiązanie programowe.

Twój gotowy produkt może zostać rozłożony na szereg odrębnych, odizolowanych modułów, ale jest to definicja projektu, która łączy je razem i wiąże w większą całość.

W przypadku systemu Android oznacza to jeden projekt na aplikację i jeden moduł na bibliotekę i aplikację testową.

W przypadku próby utworzenia wielu aplikacji w ramach tego samego projektu występuje wiele problemów. Jest to możliwe, ale jeśli spróbujesz (tak jak ja), zobaczysz, że prawie wszystko jest zaprojektowane do pracy z jedną aplikacją na projekt.

Na przykład istnieje opcja „przebudowy projektu”, która nie ma sensu w przypadku wielu aplikacji, wiele innych ustawień projektu byłoby bezużytecznych, a wbudowany system VCS nie jest świetny, gdy masz wiele repozytoriów.

Struktura: Struktura folderów

Foldery najwyższego poziomu

1. Główny projekt

Byłby to cały kontekst projektu ( Eclipse Land: jak twoja przestrzeń robocza, ale ograniczony do tego, co jest istotne dla twojego projektu). Np .: HelloWorldProjectjeśli podałeś nazwę aplikacjiHelloWorld

2.idea

To miejsce, w którym metadane specyficzne dla projektu są przechowywane przez Android Studio (AS). ( Eclipse Land: project.properties plik)

3. Moduł projektu

To jest rzeczywisty projekt. np. HelloWorldjeśli podałeś nazwę aplikacji HelloWorld

4. gradle

To jest miejsce, w którym opakowanie słoika systemu budowania gradle, tj. Ten jar jest sposobem, w jaki AS komunikuje się z programem Gradle zainstalowanym w systemie Windows (w moim przypadku system operacyjny).

5. Biblioteki zewnętrzne

W rzeczywistości nie jest to folder, ale miejsce, w którym wyświetlane są biblioteki, do których istnieją odniesienia ( Eclipse Land: biblioteki, do których istnieją odniesienia). Tutaj jest wyświetlana platforma docelowa itp.

[ Uwaga dodatkowa: w tym przypadku wielu z nas w Eclipse Land usuwało biblioteki, do których istnieją odniesienia, i naprawiało właściwości projektu w celu naprawiania błędów odniesienia, pamiętasz?]

Folder projektu w szczegółach

To numer 3 na powyższej liście. Ma następujące pod-reż

1. buduj

Zawiera wszystkie kompletne dane wyjściowe makeprocesu, tj. Classes.dex, skompilowane klasy i zasoby itp.

W graficznym interfejsie użytkownika Android Studio wyświetlanych jest tylko kilka folderów. Ważną częścią jest to, że twoja R.java znajduje się tutaj podbuild/source/<flavor>/r/<build type(optional)>/<package>/R.java

2. libs

Jest to standardowy folder libs widać w eclipse ziemi zbyt

3. src

Tutaj zobaczysz tylko folder javai, resktóry odpowiada srcfolderowi i resfolderowi w Eclipse Land . Jest to bardzo mile widziane uproszczenie IMHO.

Uwaga dotycząca modułów:

Moduły są jak projekty Eclipse Land . Pomysł jest taki, że masz jeden projekt aplikacji (Moduł # 3 na powyższej liście) i kilka projektów bibliotek (jako oddzielne moduły w globalnym folderze projektu (nr 1 na powyższej liście)), od których zależy projekt aplikacji. W jaki sposób te projekty biblioteczne można ponownie wykorzystać w innych aplikacjach, wciąż się nie dowiedziałem.

[ Uwaga dodatkowa: Cała reorganizacja ma pewne zalety, takie jak uproszczenia w folderze src, ale tak wiele komplikacji. Komplikacje wynikają głównie z BARDZO BARDZO cienkiej dokumentacji tego nowego układu projektu.]

Nowy system budowania

Podręcznik użytkownika nowego systemu kompilacji

Wyjaśnienie smaków, typów kompilacji itp. - O co chodzi?

Ściągawka dotycząca smaków i typów kompilacji

BuildType: debug i releasesą buildTypesdomyślnie dostępne we wszystkich projektach. Służą do tworzenia / kompilowania TEGO SAMEGO KODU w celu generowania różnych plików APK. Na przykład w releaseplikach APK, które chcesz uruchomić proguard (do zaciemniania), podpisz go swoim kluczem (w porównaniu z kluczem debugowania), uruchom optymalizacje (może za pomocą proguard lub innych narzędzi), użyj nieco innego packageNames(używamy com.company.productdla releasei com.company.product.debugdla debug), itd. Używamy również flagi debugowania ( BuildConfig.DEBUG), aby wyłączyć logowanie do logcat (ponieważ spowalnia aplikację) w releasekompilacjach. Zapewnia to szybszą debugkompilację podczas opracowywania, ale także optymalizację releasedo umieszczenia w sklepie Play.

Smak produktu: Nie ma dostępnych domyślnych smaków (lub mówiąc precyzyjnie, domyślny smak jest pusty / bez nazwy). Flavorsmoże być wersją bezpłatną lub płatną, w której mają INNY KOD . Dzielą ten sam Mainkod, ale różne wersje (lub brak wersji) kilku plików lub zasobów kodu źródłowego.

BuildVariant: A buildVariantjest tym, czemu faktycznie odpowiada wygenerowany plik APK. Nazywają się tak (w kolejności) Product Flavor+ Build Type=Build Variant .
Przykład 1: jeśli masz freei paidjako dwa smaki. Warianty kompilacji, które można uzyskać, to:
Bezpłatne - debugowanie
Darmowe - wydanie
Płatne - debugowanie
Płatne - wydanie
Czyli to 4 możliwe konfiguracje APK. Kilka konfiguracji może nie mieć sensu w konkretnym projekcie, ale są one dostępne.

Przykład 2: (dla nowych projektów / bez smaków) Masz dostępne 2 buildVariantslub APK, ponieważ domyślny smak jest bezimienny / pusty: wersja
debugowania

Porównaj to ze strukturą projektu Intellij, jeśli to pomoże:

Folder .idea (1) zawiera wiele podfolderów, głównie z wewnętrznymi informacjami IntelliJ IDEA.

Folder src (2) zawiera kod źródłowy pliku MyActivity.java (3), który implementuje funkcjonalność Twojej aplikacji. Plik należy do pakietu com.example.

Folder res (4) zawiera różne zasoby wizualne.

Plik layout / main.xml (5) definiuje wygląd aplikacji złożonej z zasobów różnego typu.

Folder wartości (6) jest przeznaczony do przechowywania plików .xml, które opisują zasoby różnych typów. Obecnie folder zawiera plik strings.xml z definicjami zasobów typu String. Jak zobaczysz w sekcji Dodawanie koloru, folder układu może również zawierać, na przykład, deskryptor kolorów.

Folder do rysowania (7) zawiera obrazy.

Folder gen (8) zawiera plik R.java (9) , który łączy zasoby wizualne i kod źródłowy Java. Jak zobaczysz w poniższych sekcjach, IntelliJ IDEA obsługuje ścisłą integrację między zasobami statycznymi a R.java. Gdy tylko zostaną dodane lub usunięte jakiekolwiek zasoby, odpowiednie klasy i pola klas w R.java są automatycznie generowane lub odpowiednio usuwane. Plik R.java również należy do pakietu com.example.

Android Studio: app \ build \ source \ r \ debug \ com.example.app \ R.java

Dlaczego te ścieżki są różne? Dlaczego moja R.java znajduje się w folderze debugowania w Android Studio? Prowadzi to do pewnych błędów na wczesnym etapie i jeśli ktoś ma wgląd w te różnice, byłbym wdzięczny.

Mówiąc najprościej, Android Studio jest skonfigurowany tak, aby zbudować debugowania Typ kompilacji w systemie.

Eclipse / ADT zostało zaprojektowane do obsługi jednej kompilacji naraz (z tego, co wiem). Jeden z głównych celów nowego systemu kompilacji ( z podręcznika użytkownika ):

Make it easy to create several variants of an application, 
either for multi-apk distribution or for different flavors of an application

Tak więc tam, gdzie Eclipse / ADT może wygenerować jeden R.javaplik, Android Studio obsługuje wiele plików. Wygenerowany plik R.javaznajduje się w debugfolderze, ponieważ domyślnie nowy system kompilacji obsługuje debugi releaseod razu obsługuje typy kompilacji. Jeśli zmieniłeś wariant kompilacji (przycisk, lewy dolny róg AS) na wydanie, AS wygeneruje się R.javaw releasekatalogu.

Może to nic nie znaczyć w przypadku prostych projektów, ale obsługa wariantów kompilacji oznacza drastyczne uproszczenie procesu kompilacji dla wielu programistów, w tym projektu, nad którym pracuję.

Nasz projekt obsługuje 4 smaki z 2 typami kompilacji (debugowanie i wydanie), aby obsłużyć łącznie 8 różnych kombinacji APK. Każda z tych kombinacji ma nieco inną konfigurację, więc ten system kompilacji naprawdę nam się sprawdził. Moje studio Android jest zainstalowane na innym komputerze, ale jeśli pamięć mnie obsługuje, R.javaplik istnieje w build/source/<flavor>/r/<build type>/package/R.java. Kiedy nasz serwer CI tworzy pliki APK, używa każdego z tych R.javaplików do generowania oddzielnych pakietów.

Google zaprzestaje wsparcia dla Android Developer Tools (ADT) w Eclipse, zgodnie z naszym ogłoszeniem. Należy jak najszybciej przeprowadzić migrację projektów tworzenia aplikacji do Android Studio. Aby uzyskać więcej informacji na temat przejścia do Android Studio, zobacz Migracja do Android Studio.

Więc najlepsze narzędzie programistyczne dla Androida tylko dla Android Studio dla całej przyszłej obsługi Androida M ---

W przypadku Androida Studio 3.0.1 i wybranych funkcji:

• Android O najnowszy
• Android Auto
• Android rzeczy
• Android Wear
• Android TV
• Obsługa C ++
• Wsparcie Kotlin

Struktura w wersji 3.0.1 nie wygląda jak wszystkie inne odpowiedzi.

Najnowsza struktura jest taka, jak pokazano w 2018 r., Android Studio 3.0.1 01/2018.

Początkujący znalazł coś podobnego do używanego w podfolderze funkcji:

Zaktualizuj Android Studio 3.0.1 01_2018:

Wskazówka: