- Tuotevarianttien ja koontityyppien edistynyt hallinta Gradlen avulla käyttöönoton optimoimiseksi.
- SDK:n, nimiavaruuksien ja sovellustunnusten yksityiskohtainen hallinta yhteensopivuuden ja yksilöllisyyden varmistamiseksi Google Playssa.
- IDE:n ja koontijärjestelmän suorituskyvyn optimointi resurssirajoitteisissa ympäristöissä.
- Natiivien C++-kirjastojen integrointi ja BuildConfig-luokan käyttö dynaamisissa ympäristöissä.
Jos olet aloittamassa mobiilikehitystä, olet luultavasti huomannut, että buildin määrittäminen ei ole vain suorituspainikkeen painamista. Androidin build-järjestelmä on moottori, joka muuntaa kaiken koodisi ja resurssisi APK-tiedostoksi tai Android App Bundleksi (AAB), jotka ovat paketteja, jotka lopulta päätyvät käyttäjien laitteille.
Jotta kaikki tämä sujuisi ongelmitta, Android Studio käyttää Gradlea ja sen omaa laajennusta , jonka avulla voimme mukauttaa kaikkea sovelluksen allekirjoituksesta tuettuihin käyttöjärjestelmäversioihin. Aluksi se ei ole helppoa, mutta kun olet oppinut järjestämään variantit ja riippuvuudet, voit julkaista ilmaisia, maksullisia tai kokeiluversioita ilman, että projektiasi tarvitsee kopioida.
Rakennuksen ydin: Gradle ja sen tiedostot
Rakennusprosessin hallitsemiseksi meidän on käsiteltävä useita tekstitiedostoja, jotka käyttävät ohjelmointikieliä, kuten Kotlin DSL tai Groovy. Ensinnäkin meillä on Gradle Wrapper (gradlew) , joka on loistava, koska se varmistaa, että koko tiimi käyttää samaa Gradlen versiota, estäen tyypillisen "se toimii minun koneellani" -skenaarion.
Projektin juuresta löytyy settings.gradle.kts -tiedosto , jossa kerromme Gradlelle, mitkä moduulit ovat osa sovellusta ja konfiguroimme repositoriot. Sitten on ylimmän tason build.gradle-tiedosto , joka määrittelee kaikkien moduulien kesken jaettavat plugin-versiot. Mutta todellinen helmi on moduulitason build.gradle-tiedosto , jossa määritämme sovelluskohtaiset tiedot, kuten SDK:n ja riippuvuudet.
Android SDK:n hallinta
SDK:n konfigurointi on elintärkeää, jotta sovelluksesi ei kaadu vanhemmilla laitteilla tai vanhene. compileSdk määrittää , mitkä Android-API:t ovat käytettävissä koodia kirjoitettaessa. Ihannetapauksessa sinun tulisi aina käyttää uusinta versiota hyödyntääksesi uusimpia ominaisuuksia. Toisaalta minSdk on punainen viiva: laite, jonka versio on tätä vanhempi, ei voi asentaa sovellusta.
Emme voi unohtaa targetSdk:ta , joka pohjimmiltaan kertoo käyttöjärjestelmälle, että olemme jo testanneet sovellusta kyseisessä versiossa. Jos laitteessa on uudempi Android-versio kuin kohdelaitteessamme, järjestelmä aktivoi yhteensopivuustilan estääkseen sovelluksen virheellisen toiminnan.
Tuotevariantit ja rakennustyypit
Tässä kohtaa asiat muuttuvat mielenkiintoisiksi. Rakennustyypit Ne auttavat erottamaan kehitysvaiheet toisistaan. Oletusarvoisesti meillä on debugjoka mahdollistaa virheenkorjauksen ja käyttää yleistä avainta, ja release, joka on yleisölle optimoitu, obfuskoitu ja allekirjoitettu versio.
Jos haluat käynnistää "Lite"- ja "Pro"-versiot, sinun on käytettävä Tuotteen mautNämä mahdollistavat yleisen koodin uudelleenkäytön, mutta resurssien tai toimintojen muuttamisen versiosta riippuen. Kun yhdistämme koontityypin tuotevarianttiin, saamme kokoelmavariantti (esimerkiksi demoDebugTämän hallitsemiseksi käytämme varianttien mitatjoiden avulla voit ryhmitellä eri makuja sovelluksesta ja sekoittaa niitä.
ID- ja nimiavaruushallinta
El sovellustunnus Tämä on sovelluksesi tunnus Google Playssa; jos muutat sitä julkaisun jälkeen, kauppa luulee sitä täysin uudeksi sovellukseksi. Voit käyttää applicationIdSuffix jotta debug-versiolla on eri tunniste ja se voidaan asentaa molemmat versiot samassa matkapuhelimessa törmäämättä.
Nimiavaruus puolestaan määrittelee paketin, jossa R- ja BuildConfig-luokat luodaan. Vaikka nimiavaruuden ja applicationId:n käyttöä suositellaan samaksi komplikaatioiden välttämiseksi, ne voidaan erottaa, jos lähdekoodia on järjesteltävä uudelleen muuttamatta sovelluksen identiteettiä kaupassa.
Allekirjoitus- ja suojauskonfiguraatio
Julkaistua sovellusta ei voida jakaa, jos sitä ei ole allekirjoitettu. Tätä varten tarvitsemme avainsäilön ja yksityisen avaimen. On erittäin tärkeää, ettei salasanoja kirjoiteta suoraan Gradle-tiedostoon; paras käytäntö on ladata ne ympäristömuuttujista tai paikallisesta ominaisuustiedostosta, jota ei ole ladattu versionhallintaan.
IDE-suorituskyvyn optimointi
Android Studio voi kuluttaa paljon RAM-muistia. Tämän estämiseksi voit muokata studio.vmoptions -tiedostoa ja suurentaa keon enimmäiskokoa (Xmx). Jos tietokoneesi resurssit ovat vähissä, on parasta ottaa käyttöön virransäästötila , poistaa käytöstä tarpeettomat nukkatarkistukset ja ennen kaikkea suorittaa debuggaus fyysisellä laitteella emulaattorin käytön sijaan.
Windowsissa virustorjuntaohjelmisto voi hidastaa käännösprosessia skannaamalla jokaisen Gradlen luoman tiedoston. Ratkaisu on jättää Gradle-kansiot , Android SDK ja projektit pois reaaliaikaisesta skannauksesta, mikä nopeuttaa prosessia merkittävästi.
BuildConfigin ja natiivikirjastojen käyttö
Luokka BuildConfig Se on Gradlen automaattisesti luoma olennainen työkalu. Se kertoo meille, olemmeko tilassa DEBUG o RELEASE koodin kautta, mikä sopii erinomaisesti piilota lokit tuotannossa tai vaihda palvelimen URL-osoitetta kehitysympäristön ja käyttöympäristön välillä.
Raakaa tehoa tarvitseville Android Studio mahdollistaa integroinnin C++ käyttäen CMakea tai ndk-buildiaVoimme linkittää ulkoisia projekteja ja hallita mitä. ABI:t (binäärirajapinnat)Haluamme pakata käyttämällä abiFiltersestämällä lopullisen tiedoston koon kasvamisen liian suureksi lisäämällä siihen arkkitehtuureja, joita emme tarvitse.
Lähdejoukkojen järjestäminen
Gradle järjestää koodin seuraavasti: alkuperäjoukotHakemisto src/main/ Se sisältää kaikkien jakaman sisällön, mutta voimme luoda kansioita, kuten src/debug/ o src/full/ lisätä koodia, joka on olemassa vain kyseisessä versiossa. Yksi vaihtoehto on olemassa prioriteettihierarkia: koontiversion tiedostoilla on etusija koontityypin tiedostoihin nähden, ja näillä on etusija tuotevariantin ja pääkoodin tiedostoihin nähden.
Tämän koko konfiguraatiotiedostojen, muistinhallinnan ja versioiden viipaloinnin ekosysteemin avulla on mahdollista muuttaa yksinkertainen projekti ammattimaiseksi infrastruktuuriksi, joka pystyy skaalautumaan ja mukautumaan mihin tahansa Android-laitteeseen varmistaen, että pakkausprosessi on tehokas ja jakelu kaupassa turvallinen.