- Mas masusing pamamahala ng mga variant ng produkto at mga uri ng build gamit ang Gradle upang ma-optimize ang deployment.
- Detalyadong kontrol sa SDK, mga namespace, at mga application ID upang matiyak ang compatibility at pagiging natatangi sa Google Play.
- Pag-optimize sa pagganap ng IDE at ng build system para sa mga kapaligirang limitado ang mapagkukunan.
- Pagsasama ng mga katutubong C++ library at paggamit ng BuildConfig class para sa mga dynamic na kapaligiran.
Kung nagsisimula ka pa lang sa mobile development, malamang napagtanto mo na na ang pag-set up ng isang build ay hindi lang basta pagpindot sa run button. Ang Android build system ang engine na kumukuha ng lahat ng iyong code at resources at binabago ang mga ito sa isang APK file o Android App Bundle (AAB), na siyang mga package na sa huli ay nakakarating sa mga device ng mga user.
Para maging maayos ang lahat ng ito, umaasa ang Android Studio sa Gradle at sa nakalaang plugin nito , na nagbibigay-daan sa amin na i-customize ang lahat mula sa signature ng app hanggang sa kung aling mga bersyon ng operating system ang susuportahan namin. Hindi ito madali sa simula, ngunit kapag natuto ka na kung paano isaayos ang iyong mga variant at dependency, maaari ka nang maglabas ng libre, bayad, o trial na mga bersyon nang hindi kinakailangang kopyahin ang iyong proyekto.
Ang puso ng pagbuo: Gradle at ang mga file nito
Para mapamahalaan ang proseso ng pagbuo, kailangan nating makipag-ugnayan sa ilang text file na gumagamit ng mga wikang tulad ng Kotlin DSL o Groovy. Una, mayroon tayong Gradle Wrapper (gradlew) , na kamangha-mangha dahil tinitiyak nitong gagamitin ng buong team ang parehong bersyon ng Gradle, na pumipigil sa karaniwang senaryo na "gumagana ito sa aking makina".
Sa ugat ng proyekto, matatagpuan natin ang settings.gradle.kts file , kung saan sinasabi natin sa Gradle kung aling mga module ang bahagi ng app at kino-configure ang mga repository. Pagkatapos ay mayroong top-level build.gradle file , na tumutukoy sa mga bersyon ng plugin na ibabahagi sa lahat ng module. Ngunit ang tunay na hiyas ay ang module-level build.gradle file , kung saan kino-configure natin ang mga detalyeng partikular sa app, tulad ng SDK at mga dependency.
Pag-master ng Android SDK
Mahalaga ang pag-configure ng SDK upang maiwasan ang pag-crash ng iyong app sa mga lumang device o pagiging lipas na. Tinutukoy ng compileSdk kung aling mga Android API ang available habang nagsusulat ka ng code; sa isip, dapat mong palaging gamitin ang pinakabagong bersyon upang samantalahin ang mga pinakabagong feature. Sa kabilang banda, ang minSdk ay ang pulang linya: anumang device na may bersyong mas mababa kaysa dito ay hindi makakapag-install ng application.
Hindi natin maaaring kalimutan ang targetSdk , na siyang nagsasabi sa operating system na nasubukan na natin ang app sa partikular na bersyong iyon. Kung ang device ay may mas bagong bersyon ng Android kaysa sa ating target, ia-activate ng system ang compatibility mode upang maiwasan ang hindi regular na paggana ng app.
Mga variant ng produkto at mga uri ng pagbuo
Dito nagiging interesante ang mga bagay-bagay. Mga Uri ng Paggawa Nagsisilbi ang mga ito upang maiba ang mga yugto ng pag-unlad. Bilang default, mayroon tayo debugna nagpapahintulot sa pag-debug at gumagamit ng generic na key, at release, na siyang na-optimize, pinalabo, at nilagdaang bersyon para sa publiko.
Kung gusto mong maglunsad ng bersyong "Lite" at bersyong "Pro", dapat mong gamitin ang Mga Lasa ng ProduktoPinapayagan nito ang muling paggamit ng karaniwang code ngunit binabago ang mga mapagkukunan o functionality depende sa bersyon. Kapag pinagsama natin ang isang uri ng build na may variant ng produkto, nakakakuha tayo ng variant ng compilation (halimbawa, demoDebugPara pamahalaan ito, ginagamit namin ang mga sukat ng mga variantna nagbibigay-daan sa iyong pangkatin ang iba't ibang lasa mula sa app at paghaluin ang mga ito.
Pamamahala ng ID at Namespace
El applicationId Ito ang ID ng iyong app sa Google Play; kung babaguhin mo ito pagkatapos i-publish, iisipin ng tindahan na isa itong ganap na bagong app. Posible itong gamitin applicationIdSuffix para ang bersyon ng debug ay may ibang ID at maaaring mai-install parehong bersyon sa iisang mobile phone nang hindi nagbabanggaan.
Sa kabilang banda, ang namespace ang tumutukoy sa package kung saan nabubuo ang mga klase ng R at BuildConfig. Bagama't inirerekomenda na ang namespace at applicationId ay pareho upang maiwasan ang mga komplikasyon, posible pa ring paghiwalayin ang mga ito kung kailangan mong muling isaayos ang source code nang hindi binabago ang pagkakakilanlan ng app sa store.
Konpigurasyon ng lagda at seguridad
Hindi maaaring ipamahagi ang isang release app kung hindi ito naka-sign. Para dito, kailangan natin ng keystore at private key. Mahalagang huwag direktang isulat ang mga password sa Gradle file; ang pinakamahusay na kasanayan ay i-load ang mga ito mula sa mga environment variable o isang local properties file na hindi na-upload sa version control.
Pag-optimize ng pagganap ng IDE
Ang Android Studio ay maaaring maging isang malaking pasanin sa RAM. Para maiwasan ito, maaari mong i-edit ang studio.vmoptions file at dagdagan ang maximum heap size (Xmx). Kung ang iyong computer ay tumatakbo sa mababang resources, pinakamahusay na paganahin ang Power Saving Mode , i-disable ang mga hindi kinakailangang lint check, at, higit sa lahat, mag-debug sa isang pisikal na device sa halip na gamitin ang emulator.
Sa Windows, maaaring mapabagal ng antivirus software ang proseso ng pagbuo sa pamamagitan ng pag-scan sa bawat file na nililikha ng Gradle. Ang solusyon ay ibukod ang mga folder ng Gradle , ang Android SDK, at mga proyekto mula sa real-time na pag-scan upang makakuha ng malaking tulong sa bilis.
Paggamit ng BuildConfig at mga Native Library
Klase BuildConfig Ito ay isang mahalagang tool na awtomatikong binubuo ng Gradle. Ipinapaalam nito sa atin kung nasa mode tayo. DEBUG o RELEASE sa pamamagitan ng code, na mainam para sa itago ang mga log sa produksyon o baguhin ang URL ng server sa pagitan ng development environment at ng live environment.
Para sa mga nangangailangan ng raw power, pinapayagan ng Android Studio ang integrasyon C++ gamit ang CMake o ndk-buildMaaari nating iugnay ang mga panlabas na proyekto at kontrolin kung ano. Mga ABI (binary interface)Gusto naming mag-package gamit ang abiFilterspinipigilan ang pagiging masyadong malaki ng pangwakas na file sa pamamagitan ng pagsasama ng mga arkitektura na hindi natin kailangan.
Pagsasaayos ng mga Set ng Pinagmulan
Inaayos ng Gradle ang code sa mga hanay ng pinagmulanAng direktoryo src/main/ Naglalaman ito ng mga bagay na ibinabahagi ng lahat, ngunit maaari tayong lumikha ng mga folder tulad ng src/debug/ o src/full/ para maglagay ng code na umiiral lamang sa bersyong iyon. May isa hirarkiya ng prayoridad: ang mga file sa build variant ay inuuna kaysa sa mga nasa build type, at ang mga ito kaysa sa mga nasa product variant at main code.
Sa pamamagitan ng buong ecosystem na ito ng mga configuration file, pamamahala ng memorya, at paghihiwalay ng bersyon, posibleng baguhin ang isang simpleng proyekto tungo sa isang propesyonal na imprastraktura na may kakayahang mag-scale at umangkop sa anumang Android device, na tinitiyak na ang proseso ng packaging ay mahusay at ang pamamahagi sa tindahan ay ligtas.