Пълно ръководство за конфигуриране на компилации в Android Studio

Алфа ръководство » Android » Пълно ръководство за конфигуриране на компилации в Android Studio

Ако се занимавате с мобилна разработка, вероятно сте осъзнали, че настройването на компилация не е просто въпрос на натискане на бутон за изпълнение. Системата за компилация на Android е двигателят, който взема целия ви код и ресурси и ги трансформира в APK файл или Android App Bundle (AAB), които в крайна сметка достигат до устройствата на потребителите.

За да работи всичко това гладко, Android Studio разчита на Gradle и неговия специален плъгин , което ни позволява да персонализираме всичко - от сигнатурата на приложението до версиите на операционните системи, които ще поддържаме. В началото не е лесно, но след като усвоите как да организирате вариантите и зависимостите си, можете да пускате безплатни, платени или пробни версии, без да се налага да дублирате проекта си.

Сърцето на компилацията: Gradle и неговите файлове

За да управляваме процеса на изграждане, трябва да взаимодействаме с няколко текстови файла, които използват езици като Kotlin DSL или Groovy. Първо, имаме Gradle Wrapper (gradlew) , който е фантастичен, защото гарантира, че целият екип използва една и съща версия на Gradle, предотвратявайки типичния сценарий „работи на моята машина“.

В основата на проекта намираме файла settings.gradle.kts , където казваме на Gradle кои модули са част от приложението и конфигурираме хранилищата. След това е файлът от най-високо ниво build.gradle , който определя версиите на плъгините, които ще бъдат споделяни между всички модули. Но истинският скъпоценен камък е файлът build.gradle на модулно ниво , където конфигурираме специфичните за приложението детайли, като SDK и зависимости.

Овладяване на Android SDK

Конфигурирането на SDK е жизненоважно, за да предотвратите сривове на приложението ви на по-стари устройства или остаряване. compileSdk определя кои Android API са налични, докато пишете код; в идеалния случай винаги трябва да използвате най-новата версия, за да се възползвате от най-новите функции. От друга страна, minSdk е червената линия: всяко устройство с версия по-стара от тази няма да може да инсталира приложението.

Не можем да забравим и targetSdk , който по същество казва на операционната система, че вече сме тествали приложението на тази конкретна версия. Ако устройството има по-нова версия на Android от целевата ни версия, системата ще активира режим на съвместимост , за да предотврати нестабилното поведение на приложението.

Варианти на продукта и видове сглобки

Тук нещата стават интересни. Видове изграждане Те служат за разграничаване на етапите на развитие. По подразбиране имаме debugкоето позволява дебъгване и използва генеричен ключ, и release, което е оптимизираната, обфусцирана и подписана версия за обществеността.

Ако искате да стартирате „Lite“ и „Pro“ версия, трябва да използвате Вкусове на продуктаТе позволяват повторно използване на общ код, но промяна на ресурси или функционалности в зависимост от версията. Когато комбинираме тип компилация с вариант на продукт, получаваме вариант на компилация (например demoDebugЗа да управляваме това, използваме размери на вариантитекоито ви позволяват да групирате различни вкусове от приложението и да ги смесвате.

Управление на идентификатори и пространства от имена

El идентификатор на приложение Това е идентификационният номер на вашето приложение в Google Play; ако го промените след публикуването, магазинът ще го сметне за напълно ново приложение. Възможно е да се използва applicationIdSuffix така че версията за отстраняване на грешки да има различен идентификатор и да може да бъде инсталирана и двете версии на един и същ мобилен телефон без да се сблъскат.

Именуването , от друга страна, определя пакета, където се генерират класовете R и BuildConfig. Въпреки че се препоръчва именуването и applicationId да са едни и същи, за да се избегнат усложнения, е възможно да ги разделите, ако е необходимо да реорганизирате изходния код, без да променяте идентичността на приложението в магазина.

Конфигурация на подпис и защита

Приложение за издание не може да бъде разпространявано, ако не е подписано. За тази цел се нуждаем от хранилище за ключове и частен ключ. Изключително важно е да не записвате паролите директно във файла на Gradle; най-добрата практика е да ги заредите от променливи на средата или локален файл със свойства, който не е качен в системата за контрол на версиите.

Оптимизация на производителността на IDE

Android Studio може да е голям потребител на RAM памет. За да предотвратите това, можете да редактирате файла studio.vmoptions и да увеличите максималния размер на heap паметта (Xmx). Ако компютърът ви работи с малко ресурси, най-добре е да активирате режима за пестене на енергия , да деактивирате ненужните проверки за lint и най-вече да отстранявате грешки на физическо устройство, вместо да използвате емулатора.

В Windows антивирусният софтуер може да забави процеса на изграждане, като сканира всеки файл, създаден от Gradle. Решението е да се изключат папките на Gradle , Android SDK и проектите от сканирането в реално време, за да се постигне значително увеличение на скоростта.

Използване на BuildConfig и Native Libraries

клас BuildConfig Това е основен инструмент, който Gradle генерира автоматично. Той ни уведомява дали сме в режим DEBUG o RELEASE чрез код, което е идеално за скриване на лог файлове в производствения режим или променете URL адреса на сървъра между средата за разработка и реалната среда.

За тези, които се нуждаят от сурова мощност, Android Studio позволява интеграция C++ с помощта на CMake или ndk-buildМожем да свързваме външни проекти и да контролираме какво. ABI (бинарни интерфейси)Искаме да опаковаме, използвайки abiFiltersпредотвратяване на твърде големия размер на крайния файл чрез включване на архитектури, от които не се нуждаем.

Организиране на набори от източници

Gradle организира кода в набори от произходДиректорията src/main/ Съдържа това, което се споделя от всички, но можем да създаваме папки като src/debug/ o src/full/ да вмъкнете код, който съществува само в тази версия. Има един йерархия на приоритетите: файловете във варианта на компилация имат предимство пред тези от типа компилация, а тези от варианта на продукта и основния код.

Чрез цялата тази екосистема от конфигурационни файлове, управление на паметта и разделяне на версиите е възможно да се трансформира един прост проект в професионална инфраструктура, способна да се мащабира и адаптира към всяко Android устройство, като се гарантира, че процесът на опаковане е ефективен, а разпространението в магазина е сигурно.