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
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.
