Bei der Entwicklung eines Projekts für die Android-Plattform muss sich früher oder später auch das kleinste mit der Entwicklungsumgebung befassen. Zusätzlich zum Android SDK benötigen Sie die neueste Version von Kotlin, Gradle, Plattform-Tools und Build-Tools. Und wenn auf dem Computer des Entwicklers alle diese Abhängigkeiten mithilfe der Android Studio-IDE in größerem Maße gelöst werden, kann jedes Update auf dem CI / CD-Server zu Kopfschmerzen führen. Und wenn Docker in der Webentwicklung zur Standardlösung für das Umgebungsproblem wurde, warum dann nicht versuchen, ein ähnliches Problem damit in der Android-Entwicklung zu lösen?
Für diejenigen, die nicht wissen, was Docker ist - wenn es ganz einfach ist, dann ist dies ein sogenanntes Erstellungswerkzeug. „Container“, in denen der minimale Betriebssystemkern und die erforderliche Software enthalten sind, die wir unter Wahrung der Umgebung bereitstellen können, wo immer wir wollen. Was genau in unserem Container enthalten sein wird, wird in der Docker-Datei definiert, die dann zu einem Image zusammengesetzt wird, das an einer beliebigen Stelle gestartet wird und die Eigenschaft idempotency besitzt.
Der Installationsprozess und die Grundlagen von Docker werden auf seiner
offiziellen Website perfekt beschrieben. Daher haben wir hier ein solches Dockerfile
# .. Android- Gradle, # Docker- # Gradle FROM gradle:5.4.1-jdk8 # Android SDK # ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" \ ANDROID_HOME="/usr/local/android-sdk" \ ANDROID_VERSION=28 \ ANDROID_BUILD_TOOLS_VERSION=28.0.3 # , SDK , # RUN mkdir "$ANDROID_HOME" .android \ && cd "$ANDROID_HOME" \ && curl -o sdk.zip $SDK_URL \ && unzip sdk.zip \ && rm sdk.zip \ # # . . Android # # # && mkdir "$ANDROID_HOME/licenses" || true \ && echo "24333f8a63b6825ea9c5514f83c2829b004d1" > "$ANDROID_HOME/licenses/android-sdk-license" \ && echo "84831b9409646a918e30573bab4c9c91346d8" > "$ANDROID_HOME/licenses/android-sdk-preview-license" # SDK build-tools, platform-tools RUN $ANDROID_HOME/tools/bin/sdkmanager --update RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" \ "platforms;android-${ANDROID_VERSION}" \ "platform-tools"
Wir speichern es mit unserem Android-Projekt im Ordner und starten die Montage des Containers mit dem Befehl
docker build -t android-build:5.4-28-27 .
Die
Option -t gibt das Tag oder den Namen unseres Containers an, der normalerweise aus seinem Namen und seiner Version besteht. In unserem Fall haben wir es Android-Build genannt und in der Version eine Reihe von Versionen von Gradle, Android-SDK und Plattform-Tools angegeben. In Zukunft wird es für uns einfacher sein, mit dieser „Version“ nach dem Bild zu suchen, das wir namentlich benötigen.
Nachdem die Assembly bestanden wurde, können wir unser Image lokal verwenden und es mit dem
Docker-Push-Befehl in ein öffentliches oder privates Image-Repository hochladen, um es auf andere Computer herunterzuladen.
Als Beispiel sammeln wir das Projekt lokal. Führen Sie dazu den Befehl im Projektordner aus
docker run --rm -v "$PWD":/home/gradle/ -w /home/gradle android-build:5.4.1-28-27 gradle assembleDebug
Mal sehen, was es bedeutet:
Docker-Lauf - Der Image-Startbefehl selbst
-rm - bedeutet, dass nach dem Stoppen des Containers alles, was im
Laufe seines Lebens entstanden ist, hinter sich entfernt wird
-v "$ PWD": / home / gradle / - stellt den aktuellen Ordner mit unserem Android-Projekt in den internen Ordner des Containers / home / gradle / ein.
-w / home / gradle -
Legt das Arbeitsverzeichnis des Containers fest
android-build: 5.4.1-28-27 - der Name unseres Containers, den wir gesammelt haben
gradle assembleDebug - eigentlich das Build-Team, das unser Projekt erstellt
Wenn alles gut geht, sehen Sie nach ein paar Sekunden / Minuten auf Ihrem Bildschirm so etwas wie
ERFOLGREICH BAUEN in 8m 3s ! Und im Ordner app / build / output / apk befindet sich die zusammengestellte Anwendung.
Auf die gleiche Weise können Sie andere Gradle-Aufgaben ausführen - das Projekt überprüfen, Tests ausführen usw. Der Hauptvorteil besteht darin, dass Sie sich nicht um die Installation der gesamten Umgebung kümmern müssen, wenn Sie das Projekt auf einem anderen Computer erstellen müssen. Es reicht aus, das erforderliche Image herunterzuladen und die Assembly darin auszuführen.
Der Container speichert keine Änderungen, und jede Assembly beginnt bei Null, was einerseits die Identität der Assembly unabhängig davon garantiert, wo sie gestartet wurde, andererseits jedes Mal, wenn Sie alle Abhängigkeiten herunterladen und den gesamten Code erneut kompilieren müssen. Dies kann manchmal einige Zeit in Anspruch nehmen. Daher haben wir zusätzlich zum üblichen "Kaltstart" die Möglichkeit, die Montage unter Beibehaltung des sogenannten zu starten. "Cache", in dem wir den Ordner ~ / .gradle speichern, indem wir ihn einfach in den Arbeitsordner des Projekts kopieren und ihn zu Beginn des nächsten Builds zurückgeben. Wir haben alle Kopiervorgänge in separate Skripte unterteilt, und der Startbefehl selbst sah nun so aus
docker run --rm -v "$PWD":/home/gradle/ -w /home/gradle android-build:5.4.1-28-27 /bin/bash -c "./pre.sh; gradle assembleDebug; ./post.sh"
Infolgedessen wurde die durchschnittliche Projektmontagezeit für uns mehrmals reduziert (abhängig von der Anzahl der Abhängigkeiten vom Projekt, aber das durchschnittliche Projekt begann sich in 1 Minute anstatt in 5 Minuten zu montieren).
All dies allein ist nur dann sinnvoll, wenn Sie über einen eigenen internen CI / CD-Server verfügen, dessen Unterstützung Sie selbst in Anspruch nehmen. Jetzt gibt es jedoch viele Cloud-Dienste, in denen all diese Probleme behoben wurden. Sie müssen sich darüber keine Gedanken machen und können die erforderlichen Assembly-Eigenschaften auch in den Projekteinstellungen angeben.