Active Compilation Conditions ilova ishlab chiqishda: asosiy tushunchalar va qo'llash

Active Compilation Conditions nima

Active Compilation Conditions — qurish bosqichida faol preprosessor direktivalari to'plamini aniqlaydigan kompilyatsiya bayroqlari. Runtime bayroqlaridan (if (isDebug) tekshiruvi) farqli o'laroq, kompilyatsiya shartlari faol bo'lmagan kodni binar fayldan jismoniy ravishda chiqarib tashlaydi, bu esa ishlashni yaxshilaydi va ilova hajmini kamaytiradi.

Mexanizm preprosessor yoki kompilyatsiyaning dastlabki bosqichlari darajasida ishlaydi: kompilyator faol nomlar ro'yxatini oladi va #if NAME direktivasiga duch kelganda NAME ushbu ro'yxatda bor yoki yo'qligini tekshiradi. Agar nom bo'lmasa — blok ichidagi kod e'tiborga olinmaydi va kompilyatsiya qilinmaydi.

Swift.org Blog (2025) ma'lumotlariga ko'ra, Active Compilation Conditions dan runtime bayroqlari o'rniga foydalanish rivojlangan loglash tizimi va nosozliklarni tuzatish vositalariga ega loyihalarda release binar fayli hajmini o'rtacha 12-18% ga kamaytiradi. Bu, ayniqsa, o'rnatish fayli hajmi cheklangan mobil ilovalar uchun juda muhimdir.

C/C++ preprosessori darajasidagi shartli kompilyatsiyadan asosiy farq — Swift va Kotlin dagi Active Compilation Conditions AST (Abstract Syntax Tree) darajasida ishlaydi, matnli almashtirish darajasida emas. Bu ularni xavfsizroq va bashorat qilinadigan qiladi: #if ning faol bo'lmagan tarmog'idagi har qanday sintaksis xatosi tahlil bosqichida aniqlanadi va ishga tushirish vaqtida namoyon bo'lmaydi.

Yana bir muhim farq — Swift da #if os(iOS) || os(macOS) sharti kompilyatsiya bosqichida tekshiriladi va preprosessor makrolari bilan emas, balki platforma nomlari bilan ishlaydi. Bu C/C++ preprosessorida mumkin bo'lgan #define orqali matnni noto'g'ri kiritish bilan bog'liq xatolarning butun sinfini yo'q qiladi. Swift kompilyatori almashtirilgan matnni emas, balki AST ni ko'radi, bu shartli kompilyatsiyani tuzatishni sezilarli darajada osonlashtiradi.

Swift da Active Compilation Conditions

Swift Active Compilation Conditions ni #if direktivasi orqali qo'llab-quvvatlaydi. U &&, || va ! mantiqiy operatorlari bilan birlashtirilgan bayroq nomlari ro'yxatini qabul qiladi. Kompilyator #if ... #endif ichidagi kodni faqat shart to'g'ri bo'lganda kiritadi.

Swift ning o'rnatilgan shartlari

Swift bir nechta o'rnatilgan shartlarni taqdim etadi: DEBUG (debug yig'ishda avtomatik faol), swift(>=5.0) (kompilyator versiyasini tekshirish), canImport(UIKit) (modul mavjudligini tekshirish) va targetEnvironment(simulator) (muhitni tekshirish). Bu shartlar qo'shimcha sozlashni talab qilmaydi.

// Swift ning o'rnatilgan shartlari
#if DEBUG
    print("Debug yig'ish — loglash faol")
#endif

#if canImport(UIKit)
    import UIKit
    let screen = UIScreen.main.bounds
#elseif canImport(AppKit)
    import AppKit
    let screen = NSScreen.main?.frame
#endif

Xcode da foydalanuvchi bayroqlari

Dasturchi Xcode da OTHER_SWIFT_FLAGS Build Setting i orqali o'z bayroqlarini qo'shishi mumkin. Bayroq -D prefiksi bilan ko'rsatiladi, masalan -DBETA yoki -DANALYTICS_ENABLED. Turli konfiguratsiyalar (Debug, Release, Staging) uchun turli bayroq to'plamlari o'rnatilishi mumkin.

// BETA bayrog'ini qayta ishlash
#if BETA
    let apiEndpoint = "https://beta.api.com"
    let isLoggingEnabled = true
#else
    let apiEndpoint = "https://api.com"
    let isLoggingEnabled = false
#endif

func trackEvent(_ name: String) {
    #if ANALYTICS_ENABLED
        Analytics.log(name)
    #endif
}

#if os() platforma shartlari

Swift platforma shartlarini qo'llab-quvvatlaydi: os(iOS), os(macOS), os(tvOS), os(watchOS), os(Linux), os(Windows). Bu shartlar maqsadli qurish platformasini tekshiradi va platforma-spesifik bloklar bilan bir nechta Apple platformalari uchun umumiy kod yozish imkonini beradi.

import Foundation

func getDeviceName() -> String {
    #if os(iOS)
        return UIDevice.current.name
    #elseif os(macOS)
        return Host.current.name ?? "Unknown"
    #else
        return "Other platform"
    #endif
}

Android va Kotlin dagi analoglar

Android ekotizimida Active Compilation Conditions BuildConfig tizimi, productFlavors va build.gradle.kts dagi bayroqlar orqali amalga oshiriladi. Kotlin til darajasida #if direktivasining to'g'ridan-to'g'ri analogiga ega emas, ammo muqobil mexanizmlarni taqdim etadi.

BuildConfig maydonlari bayroq sifatida

Eng keng tarqalgan usul — har bir bayroq uchun buildConfigField qo'shish: buildConfigField("boolean", "BETA", "true"). Bu maydonlar har bir Build Variant uchun alohida BuildConfig sinfida yaratiladi. DEBUG maydoni allaqachon o'rnatilgan va debug yig'ishlari uchun avtomatik ravishda true hisoblanadi.

// build.gradle.kts
android {
    buildTypes {
        debug {
            buildConfigField("boolean", "BETA", "true")
        }
        release {
            buildConfigField("boolean", "BETA", "false")
        }
    }
}

// Kotlin kodida foydalanish
if (BuildConfig.BETA) {
    enableBetaFeatures()
}

Source Sets va productFlavors

Gradle har bir flavor uchun alohida sourceSets kataloglarini yaratishga imkon beradi. Masalan, src/demo/ va src/full/. Turli sourceSets dagi bir xil nomli sinflar tegishli flavor qurilganda bir-birini almashtiradi. Bu bayroqlardan kuchliroq mexanizm, chunki butun sinflarni bekor qilish mumkin.

// src/demo/java/com/example/Config.kt
object Config {
    const val API_URL = "http://demo.api.com"
    const val IS_BETA = true
}

// src/full/java/com/example/Config.kt
object Config {
    const val API_URL = "https://full.api.com"
    const val IS_BETA = false
}

Kotlin Multiplatform (KMP) uchun expect/actual direktivi mavjud bo'lib, u umumiy kodda kutilgan deklaratsiyalarni e'lon qilish va platforma implementatsiyalarini taqdim etish imkonini beradi. Bu kompilyatsiya darajasidagi mexanizm bo'lib, ta'siri bo'yicha Active Compilation Conditions ga o'xshaydi — faol bo'lmagan kod mos kelmaydigan platformalar uchun kompilyatsiya qilinmaydi.

Foydalanish stsenariylari va eng yaxshi amaliyotlar

Active Compilation Conditions to'rtta asosiy stsenariyda qo'llaniladi: nosozliklarni tuzatish (loglar, inspektorlar), A/B test (funksiya bayroqlari), platforma moslashuvi (iOS/macOS umumiy kodi) va litsenziyalash (bepul/pulli versiyalar).

Nosozliklarni tuzatish loglashi

Eng keng tarqalgan stsenariy — shartli loglash. Debug yig'ishda barcha loglar konsolga yoziladi, release da — hech narsa. #if DEBUG yoki BuildConfig.DEBUG dan foydalanish release binar faylida hech qanday logger chaqiruvi, hatto inline qilinganlarining ham yo'qligini kafolatlaydi.

func logRequest(_ url: URL, _ statusCode: Int) {
    #if DEBUG
        Logger.debug("Request to \(url.absoluteString) returned \(statusCode)")
    #endif
}

Qurish bosqichida Feature Flags

Agar yangi funksionallik ishlab chiqarish uchun hali tayyor bo'lmasa, lekin kodda allaqachon mavjud bo'lsa, uni kompilyatsiya bayrog'i orqasida yashirish mumkin. Runtime feature flags dan farqli o'laroq, kompilyatsiya bayroqlari ilovani tekshiruvlar bilan yuklamaydi va foydalanuvchi tomonidan yoqilmaydi.

• Yangi xususiyatlar — kodni o'chirmasdan tugallanmagan funksionallikni keyingi relizgacha yashirish
• Analitika — faqat beta testchilar uchun qo'shimcha metrikalarni yig'ishni yoqish
• Uchinchi tomon SDK lari — og'ir kutubxonalarni ilovaning bepul versiyasidan chiqarib tashlash
• UI komponentlari — eksperimental ekranlarni faqat staging yig'ishda ko'rsatish

Eng yaxshi amaliyotlar

Active Compilation Conditions mo''tadil ishlatilishi kerak. Haddan tashqari ko'p bayroqlar kodni tushunishni qiyinlashtiradi: dasturchi hozirgi vaqtda qaysi tarmoqlar kompilyatsiya qilinishiga ishonch hosil qila olmaydi. Har bir bayroqni README yoki maxsus CONFIG.md faylida hujjatlashtirish tavsiya etiladi.

Katta loyihalarda taqsimlangan jamoa bilan CI da bayroqlarni avtomatik tekshirishni joriy qilish foydalidir. Har bir pull request Active Compilation Conditions ning barcha mumkin bo'lgan kombinatsiyalari bilan qurilishi kerak. Bu faol bo'lmagan bayroq ostidagi kod qayta tuzish sababli buzilmaganligini va hech qanday shartli kompilyatsiya tarmog'i relizgacha tekshirilmagan holda qolmaganligini kafolatlaydi. xcresulttool (iOS uchun) va Gradle Build Scan (Android uchun) kabi vositalar bu jarayonni avtomatlashtirishga yordam beradi.

• Minimal bayroqlar — loyiha uchun 5-7 faol shartdan oshmasligi kerak. Har bir bayroq murakkablik nuqtasidir.
• Nomlash konvensiyasi — barcha bayroqlar UPPER_CASE, loyiha prefiksi bilan: MYAPP_BETA, MYAPP_ANALYTICS.
• Code review — har bir #if yoki buildConfigField qo'shilishi alohida ko'rib chiqilishi kerak.
• Test — CI kuniga kamida bir marta barcha mumkin bo'lgan bayroq kombinatsiyalarini qurishi kerak.