Android: какво е, системна архитектура и разработка в Kotlin

Какво е Android?

Android е мобилна операционна система, базирана на ядрото Linux, разработвана от Google от 2007 г. Изходният код е отворен под лиценз Apache 2.0 в рамките на проекта Android Open Source Project (AOSP). Всеки производител може да модифицира системата и да я инсталира на своите устройства.

Според StatCounter (2026), Android заема около 72% от световния пазар на мобилни операционни системи. Най-големите производители са Samsung, Xiaomi, Oppo, Vivo, Google Pixel. Фрагментацията е ключов проблем на платформата: хиляди модели с различни версии на операционната система се използват едновременно.

Архитектурата на Android е изградена на принципа на разрешенията (permissions): всяко приложение работи под отделен Linux UID и има достъп само до своите данни. Достъпът до системни ресурси (камера, микрофон, контакти) се иска чрез Android Permissions по време на изпълнение, започвайки от Android 6 (API 23).

История на версиите на Android

Android 1.0 излезе през 2008 г. на HTC Dream. Ключови етапи: Android 4.0 Ice Cream Sandwich (унифициран потребителски интерфейс за телефони и таблети), Android 5.0 Lollipop (Material Design), Android 6.0 (разрешения по време на изпълнение), Android 10 (тъмна тема, жестове), Android 12 (Material You). От 2023 г. Google премина към ежегодни големи версии без имена на десерти.

Архитектура на Android: четири ключови слоя

Архитектурата на Android се състои от четири основни слоя, които изолират хардуера от потребителските приложения. Всеки слой използва услугите на долния слой чрез строго определени интерфейси.

Ядрото Linux и HAL

Най-долният слой е модифицирано ядро Linux (LTS, версия 6.x в Android 15). То управлява паметта, процесите, мрежовия стек и драйверите. Hardware Abstraction Layer (HAL) предоставя унифициран API за взаимодействие с хардуера: камера, Bluetooth, Wi-Fi, сензори. Производителите имплементират HAL модули, без да засягат горните слоеве.

Android Runtime (ART)

ART изпълнява DEX байткода на приложенията. Започвайки от Android 5.0, ART замени Dalvik и използва компилация Ahead-of-Time (AOT) за подобряване на производителността. Всяко приложение има свой собствен процес с отделен екземпляр на ART. Събирането на боклук (GC) работи с минимални паузи — типична GC пауза е 2–4 ms.

Application Framework

Framework е слоят, с който разработчикът работи директно. Той включва Activity Manager (стек от екрани), Content Providers (достъп до данни), Resource Manager (локализация, ресурси), Notification Manager, Location Manager. Всички системни услуги се извикват чрез Binder IPC — механизмът за междупроцесна комуникация на Android.

// Пример за работа с Binder чрез AIDL интерфейс
interface IDataService : android.os.IInterface {
    fun getData(): List<DataItem>
    fun saveData(item: DataItem): Boolean
}

// Имплементация на услуга
class DataService : Service() {
    private val binder = object : IDataService.Stub() {
        override fun getData(): List<DataItem> = repository.getAll()
        override fun saveData(item: DataItem): Boolean = repository.save(item)
    }

    override fun onBind(intent: Intent?): IBinder = binder
}

Системни приложения

Най-горният слой се състои от стандартни системни приложения: Телефон, Контакти, Камера, Настройки, Браузър. Те нямат по-високи привилегии от потребителските приложения, но могат да бъдат заменени от приложения на трети страни. В Android 15 системните приложения се актуализират чрез Google Play System Updates независимо от OTA актуализациите на производителя.

Kotlin — основният език за Android разработка

Kotlin е статично типизиран език за програмиране от JetBrains, работещ на JVM. Google обяви Kotlin за официален език на Android през 2017 г. на Google I/O. Kotlin е напълно съвместим с Java, но премахва нейните недостатъци: нулева сигурност, класове данни, функции за разширение и корутини.

Нулева сигурност и типове

Основната характеристика на Kotlin е вградената защита срещу NullPointerException. Типовете са разделени на nullable (String?) и non-null (String). Компилаторът проверява nullable достъпа по време на компилация. Операторът safe call (?.) и операторът Elvis (?:) опростяват работата с опционални стойности без вложени проверки.

// Пример за Kotlin код с корутини и Flow
data class User(
    val id: Long,
    val name: String,
    val email: String
)

class UserRepository(
    private val api: UserApi,
    private val dao: UserDao
) {
    suspend fun getUser(id: Long): Result<User> {
        return try {
            val cached = dao.getUser(id)
            if (cached != null) {
                return Result.success(cached)
            }
            val remote = api.fetchUser(id)
            dao.insertUser(remote)
            Result.success(remote)
        } catch (e: Exception) {
            Result.failure(e)
        }
    }

    fun observeUsers(): Flow<List<User>> {
        return dao.observeAll()
            .map { list -> list.sortedBy { it.name } }
            .flowOn(Dispatchers.Default)
    }
}

Примерът демонстрира корутини (suspend функция) за асинхронен достъп до мрежа и база данни, Flow за реактивно наблюдение на промени в данните и Result за безопасно обработване на грешки. Корутините заместват callbacks и RxJava без допълнително натоварване на нишки.

Корутини на Kotlin и Flow

Корутините на Kotlin са леки нишки, работещи в споделен пул от нишки. Dispatchers.IO за мрежа и диск, Dispatchers.Main за потребителски интерфейс, Dispatchers.Default за задачи, интензивни за процесора. viewModelScope и lifecycleScope автоматично отменят корутините при унищожаване на компонента.

// ViewModel с корутини и StateFlow
class UserViewModel(
    private val repository: UserRepository
) : ViewModel() {

    private val _users = MutableStateFlow<List<User>>(emptyList())
    val users: StateFlow<List<User>> = _users.asStateFlow()

    private val _loading = MutableStateFlow(false)
    val loading: StateFlow<Boolean> = _loading.asStateFlow()

    init {
        viewModelScope.launch {
            repository.observeUsers().collect { userList ->
                _users.value = userList
            }
        }
    }

    fun refresh() {
        viewModelScope.launch {
            _loading.value = true
            repository.getUser(42).onSuccess { user ->
                _users.value = listOf(user)
            }
            _loading.value = false
        }
    }
}

Android Studio и инструменти за разработка

Android Studio е официалната IDE, базирана на IntelliJ IDEA, разработена от Google. Тя включва редактор на код, Layout Inspector, емулатор на устройства, APK Analyzer, Profiler (CPU, Памет, Мрежа, Енергия) и интеграция с Firebase. Android Studio 2024 (Ladybug) поддържа Kotlin 2.0 с мултиплатформен режим KMP.

Android емулатор

Android емулаторът използва KVM (Linux) или Hyper-V (Windows) за хардуерно ускорение. Поддържа симулация на GPS, сензори, камера, обаждания и SMS. Google Pixel 9 Pro е препоръчителната конфигурация за тестване с API 35 и 8 GB RAM на емулатора.

Android Profiler и отстраняване на грешки

Profiler показва в реално време натоварването на CPU, разпределението на паметта, мрежовите заявки и консумацията на енергия. Memory Profiler позволява изхвърляне на heap и анализ на течове чрез референтно дърво. Network Inspector записва всички HTTP/HTTPS заявки с тяло и заглавки. За задълбочен анализ се използва Android Studio Canary.

Компоненти на Android приложение

Android приложение се състои от четири типа компоненти, всеки със собствена входна точка и жизнен цикъл. Компонентите се регистрират във файла AndroidManifest.xml.

Activity и Intent

Activity е основният компонент на потребителския интерфейс. Всеки екран е отделна Activity или Fragment в рамките на Activity. Навигацията между екраните се осъществява чрез Intent — обект, съдържащ действие (ACTION_VIEW, ACTION_SEND) и данни (URI). В Jetpack Navigation Graph навигацията се описва в XML.

Service и WorkManager

Service изпълнява фонови задачи, но от Android 8 нататък фоновите услуги са ограничени. WorkManager е препоръчителната библиотека за отложени и гарантирани фонови задачи с поддръжка на вериги, ограничения (например само при зареждане) и рестартиране след срив.

Jetpack Compose срещу XML Layouts

Изборът между Jetpack Compose и традиционните XML оформления е основното архитектурно решение при стартиране на Android проект. XML оформленията (RecyclerView, ConstraintLayout, FrameLayout) са стандарт от 2008 г. Jetpack Compose беше представен през 2021 г. като декларативна алтернатива.

Google препоръчва Jetpack Compose за всички нови проекти. XML оформленията остават актуални за поддръжка на наследени проекти и за случаи, когато е необходима максимална персонализация на View (Canvas, SurfaceView). Compose кодът е средно с 40% по-кратък от еквивалентния XML + ViewBinding.

// Jetpack Compose — екран на потребителски профил
@Composable
fun ProfileScreen(
    user: User,
    onEditClick: () -> Unit,
    modifier: Modifier = Modifier
) {
    Column(
        modifier = modifier
            .fillMaxSize()
            .padding(16.dp),
        horizontalAlignment = Alignment.CenterHorizontally
    ) {
        AsyncImage(
            model = user.avatarUrl,
            contentDescription = "Аватар пользователя",
            modifier = Modifier
                .size(120.dp)
                .clip(CircleShape)
        )

        Spacer(modifier = Modifier.height(16.dp))

        Text(
            text = user.name,
            style = MaterialTheme.typography.headlineMedium
        )

        Text(
            text = user.email,
            style = MaterialTheme.typography.bodyLarge,
            color = MaterialTheme.colorScheme.onSurfaceVariant
        )

        Spacer(modifier = Modifier.height(24.dp))

        Button(onClick = onEditClick) {
            Icon(Icons.Default.Edit, contentDescription = null)
            Spacer(modifier = Modifier.width(8.dp))
            Text("Редактировать профиль")
        }
    }
}

@Preview(showBackground = true, showSystemUi = true)
@Composable
fun ProfileScreenPreview() {
    MaterialTheme {
        ProfileScreen(
            user = User(1, "Анна Петрова", "anna@example.com"),
            onEditClick = {}
        )
    }
}

Функцията ProfileScreen е декларирана като @Composable — тя описва потребителския интерфейс декларативно, без създаване на инстанции на View. Compose автоматично актуализира екрана, когато user се промени. @Preview показва резултата директно в IDE без компилиране и стартиране на емулатора.

Жизнен цикъл на Activity и Fragment

Всяка Activity в Android преминава през шест състояния на жизнения цикъл: onCreate, onStart, onResume, onPause, onStop, onDestroy. Fragment добавя onAttach, onCreateView, onViewCreated. Разбирането на жизнения цикъл е критично за управлението на паметта и предотвратяването на течове.

Основни състояния на Activity

onCreate — извиква се веднъж при създаване на Activity. Тук се извършва инициализация: setContentView, настройка на адаптери, абонамент за LiveData. onResume — Activity е на преден план и взаимодейства с потребителя. onPause — Activity губи фокус (диалог, друга Activity). onStop — Activity не е видима. onDestroy — Activity се унищожава.

// Activity с обработка на жизнения цикъл чрез LifecycleScope
class MainActivity : ComponentActivity() {
    private val viewModel: UserViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContent {
            MaterialTheme {
                lifecycleScope.launch {
                    repeatOnLifecycle(Lifecycle.State.STARTED) {
                        viewModel.users.collect { users ->
                            updateUi(users)
                        }
                    }
                }
            }
        }
    }

    override fun onSaveInstanceState(outState: Bundle) {
        super.onSaveInstanceState(outState)
        outState.putString("last_search", searchQuery)
    }

    override fun onRestoreInstanceState(savedInstanceState: Bundle) {
        super.onRestoreInstanceState(savedInstanceState)
        searchQuery = savedInstanceState.getString("last_search", "")
    }
}

Използването на repeatOnLifecycle гарантира, че събирането на данни спира, когато Activity премине на заден план, и се възобновява, когато се върне на преден план. Това предотвратява течове и ненужни мрежови заявки. onSaveInstanceState запазва временното състояние при завъртане на екрана.

Google Play: публикуване и изисквания

Google Play е официалният магазин за Android приложения. Регистрацията на акаунт за разработчик струва $25 еднократно. Всяко приложение преминава автоматична проверка на Google Play Integrity за злонамерен код, нарушения на политиките и неправилно използване на разрешения.

Изисквания за публикуване

Google изисква подписване на приложението чрез Android App Bundle (AAB) или APK. AAB е препоръчителният формат, позволяващ генериране на оптимизирани APK за всяка конфигурация на устройство. Приложението трябва да бъде подписано с ключ (keystore) с валиден сертификат. Google Play App Signing е опционално криптиране на ключа от страна на Google.

Политика за поверителност

Всички приложения, които искат достъп до лични данни, трябва да предоставят Политика за поверителност. От 2024 г. Google изисква декларация за Data Safety — формуляр, посочващ видовете събрани данни и целите на обработката. Приложенията, насочени към Android 14+, трябва да използват Declarations API за деклариране на разрешения.