Active Compilation Conditions tətbiq inkişafında: əsas anlayışlar və tətbiq

Active Compilation Conditions nədir

Active Compilation Conditions — qurma mərhələsində aktiv preprosessor direktivlərinin dəstini müəyyən edən kompilyasiya bayraqlarıdır. Runtime bayraqlarından ( if (isDebug) yoxlaması) fərqli olaraq, kompilyasiya şərtləri aktiv olmayan kodu ikili fayldan fiziki olaraq xaric edir, bu da performansı artırır və tətbiq ölçüsünü azaldır.

Mexanizm preprosessor və ya kompilyasiyanın ilkin mərhələləri səviyyəsində işləyir: kompilyator aktiv adların siyahısını alır və #if NAME direktivi ilə qarşılaşdıqda NAME-in bu siyahıda olub-olmadığını yoxlayır. Ad yoxdursa — blok daxilindəki kod nəzərə alınmır və kompilyasiya olunmur.

Swift.org Blog (2025)-a görə, Active Compilation Conditions-un runtime bayraqları əvəzinə istifadəsi geniş loqlama sistemi və sazlama alətləri olan layihələrdə release ikili faylının ölçüsünü orta hesabla 12-18% azaldır. Bu, xüsusilə quraşdırma faylının ölçüsü məhdud olan mobil tətbiqlər üçün vacibdir.

C/C++ preprosessoru səviyyəsində şərti kompilyasiyadan əsas fərq — Swift və Kotlin-də Active Compilation Conditions AST (Abstract Syntax Tree) səviyyəsində işləyir, mətn dəyişdirmə səviyyəsində deyil. Bu, onları daha təhlükəsiz və proqnozlaşdırıla bilən edir: #if-in aktiv olmayan qolunda istənilən sintaksis səhvi təhlil mərhələsində aşkarlanacaq, icra vaxtında üzə çıxmayacaq.

Digər vacib fərq — Swift-də #if os(iOS) || os(macOS) şərti kompilyasiya mərhələsində yoxlanılır və preprosessor makroları ilə deyil, platforma adları ilə işləyir. Bu, C/C++ preprosessorunda mümkün olan #define vasitəsilə səhv mtn daxil edilməsi ilə bağlı bütün səhv sinfini aradan qaldırır. Swift kompilyatoru dəyişdirilmiş mtn deyil, AST görür ki, bu da şərti kompilyasiyanın sazlamasını əhəmiyyətli dərəcədə asanlaşdırır.

Swift-də Active Compilation Conditions

Swift Active Compilation Conditions-u #if direktivi vasitəsilə dəstəkləyir. Bu direktiv &&, || və ! məntiqi operatorları ilə birləşdirilmiş bayraq adlarının siyahısını qəbul edir. Kompilyator #if ... #endif daxilindəki kodu yalnız şərt doğru olduqda daxil edir.

Swift-in daxili şərtləri

Swift bir neçə daxili şərt təmin edir: DEBUG (debug qurmasında avtomatik aktiv), swift(>=5.0) (kompilyator versiyasının yoxlanılması), canImport(UIKit) (modulun əlçatanlığının yoxlanılması) və targetEnvironment(simulator) (mühitin yoxlanılması). Bu şərtlər əlavə konfiqurasiya tələb etmir.

// Swift-in daxili şərtləri
#if DEBUG
    print("Debug qurması — loqlama aktivdir")
#endif

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

Xcode-da istifadəçi bayraqları

Tərtibatçı Xcode-da OTHER_SWIFT_FLAGS Build Setting-i vasitəsilə öz bayraqlarını əlavə edə bilər. Bayraq -D prefiksi ilə göstərilir, məsələn -DBETA və ya -DANALYTICS_ENABLED. Müxtəlif konfiqurasiyalar (Debug, Release, Staging) üçün müxtəlif bayraq dəstləri təyin edilə bilər.

// BETA bayrağının işlənməsi
#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 şərtləri

Swift platforma şərtlərini dəstəkləyir: os(iOS), os(macOS), os(tvOS), os(watchOS), os(Linux), os(Windows). Bu şərtlər hədəf qurma platformasını yoxlayır və platforma-spesifik bloklarla bir neçə Apple platforması üçün ümumi kod yazmağa imkan verir.

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 və Kotlin-də analoqlar

Android ekosistemində Active Compilation Conditions BuildConfig sistemi, productFlavors və build.gradle.kts-də bayraqlar vasitəsilə tətbiq olunur. Kotlin-in dil səviyyəsində #if direktivinin birbaşa analoqu yoxdur, lakin alternativ mexanizmlər təmin edir.

BuildConfig sahələri bayraq kimi

Ən geniş yayılmış üsul — hər bayraq üçün buildConfigField əlavə etmək: buildConfigField("boolean", "BETA", "true"). Bu sahələr hər Build Variant üçün ayrıca BuildConfig sinfində yaradılır. DEBUG sahəsi artıq daxildir və debug qurmaları üçün avtomatik true-dur.

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

// Kotlin kodunda istifadə
if (BuildConfig.BETA) {
    enableBetaFeatures()
}

Source Sets və productFlavors

Gradle hər flavor üçün ayrıca sourceSets kataloqları yaratmağa imkan verir. Məsələn, src/demo/ və src/full/. Müxtəlif sourceSets-də eyni adlı siniflər müvafiq flavor qurularkən bir-birini əvəz edir. Bu, bayraqlardan daha güclü mexanizmdir, çünki bütöv sinifləri ləğv etmək olar.

// 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) üçün expect/actual direktivi mövcuddur. Bu direktiv ümumi koddə gözlənilən bəyannamələr elan etməyə və platforma tətbiqlərini təmin etməyə imkan verir. Bu, təsirinə görə Active Compilation Conditions-a analoji olan kompilyasiya səviyyəli mexanizmdir — aktiv olmayan kod uyğun olmayan platformalar üçün kompilyasiya olunmur.

İstifadə ssenariləri və ən yaxşı təcrübələr

Active Compilation Conditions dörd əsas ssenaridə tətbiq olunur: sazlama (loqlar, inspektorlar), A/B testi (funksiya bayraqları), platforma adaptasiyası (iOS/macOS ümumi kodu) və lisenziyalaşdırma (pulsuz/pullu versiyalar).

Sazlama loqlaması

Ən geniş yayılmış ssenari — şərti loqlama. Debug qurmasında bütün loqlar konsola yazılır, release-də heç nə yazılmır. #if DEBUG və ya BuildConfig.DEBUG istifadəsi release ikili faylında heç bir loqqer çağırışının, hətta inlined olanların belə olmamasını təmin edir.

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

Qurma mərhələsində Feature Flags

Yeni funksionallıq istehsal üçün hələ hazır deyilsə, lakin kodda artıq varsa, onu kompilyasiya bayrağı arxasında gizlətmək olar. Runtime feature flags-dən fərqli olaraq, kompilyasiya bayraqları tətbiqi yoxlamalarla yükləmir və istifadəçi tərəfindən aktivləşdirilə bilməz.

• Yeni xüsusiyyətlər — kodu silmədən yarımçıq funksionallığı növbəti buraxılışa qədər gizlətmək
• Analitika — yalnız beta-testçilər üçün əlavə metrik toplanmasını qoşmaq
• Üçüncü tərəf SDK-ları — ağır kitabxanaları tətbiqin pulsuz versiyasından xaric etmək
• UI komponentləri — eksperimental ekranları yalnız staging qurmasında göstərmək

Ən yaxşı təcrübələr

Active Compilation Conditions mülayim şəkildə istifadə edilməlidir. Həddindən artıq bayraq sayı kodu anlamağı çətinləşdirir: tərtibatçı hazırda hansı qolların kompilyasiya olunacağına əmin ola bilməz. Hər bayrağı README və ya xüsusi CONFIG.md faylında sənədləşdirmək tövsiyə olunur.

Paylanmış komanda ilə böyük layihələrdə CI-də bayraqların avtomatik validasiyasını tətbiq etmək faydalıdır. Hər pull request Active Compilation Conditions-un bütün mümkün kombinasiyaları ilə qurulmalıdır. Bu, aktiv olmayan bayraq altındakı kodun refaktoring səbəbindən sınmadığını və heç bir şərti kompilyasiya qolunun buraxılışa qədər yoxlanılmamış qalmadığını təmin edir. xcresulttool (iOS üçün) və Gradle Build Scan (Android üçün) kimi alətlər bu prosesi avtomatlaşdırmağa kömək edir.

• Minimum bayraq — layihə üçün 5-7 aktiv şərtdən çox olmamalıdır. Hər bayraq mürəkkəblik nöqtəsidir.
• Adlandırma konvensiyası — bütün bayraqlar UPPER_CASE, layihə prefiksi ilə: MYAPP_BETA, MYAPP_ANALYTICS.
• Code review — hər #if və ya buildConfigField əlavəsi ayrıca icmal keçməlidir.
• Test — CI gündə ən azı bir dəfə bütün mümkün bayraq kombinasiyalarını qurmalıdır.