Active Compilation Conditions ve vývoji aplikací: klíčové pojmy a použití

Co jsou Active Compilation Conditions

Active Compilation Conditions jsou příznaky překladu, které určují sadu aktivních direktiv preprocesoru ve fázi sestavení. Na rozdíl od runtime příznaků (kontrola if (isDebug)) podmínky překladu fyzicky vylučují neaktivní kód z binárního souboru, což zlepšuje výkon a zmenšuje velikost aplikace.

Mechanismus pracuje na úrovni preprocesoru nebo raných fází překladu: překladač obdrží seznam aktivních jmen a když narazí na direktivu #if NAME, zkontroluje, zda je NAME v tomto seznamu. Pokud jméno neexistuje — kód uvnitř bloku je ignorován a není přeložen.

Podle Swift.org Blog (2025) použití Active Compilation Conditions místo runtime příznaků snižuje velikost release binárního souboru v průměru o 12-18% u projektů s rozvinutým systémem logování a nástroji pro ladění. To je obzvláště důležité pro mobilní aplikace s omezením velikosti instalačního souboru.

Hlavní rozdíl oproti podmíněnému překladu na úrovni preprocesoru C/C++ — Active Compilation Conditions ve Swift a Kotlin pracují na úrovni AST (Abstract Syntax Tree) překladače, nikoli na úrovni textového nahrazování. To je činí bezpečnějšími a předvídatelnějšími: jakákoli syntaktická chyba v neaktivní větvi #if bude odhalena ve fázi parsování, neobjeví se za běhu.

Další důležitý rozdíl — ve Swift je podmínka #if os(iOS) || os(macOS) kontrolována ve fázi překladu a pracuje s názvy platforem, nikoli s makry preprocesoru. To eliminuje celou třídu chyb souvisejících s nesprávným vkládáním textu přes #define, které jsou možné v preprocesoru C/C++. Překladač Swift vidí AST, nikoli nahrazený text, což výrazně usnadňuje ladění podmíněného překladu.

Active Compilation Conditions ve Swift

Swift podporuje Active Compilation Conditions prostřednictvím direktivy #if, která přijímá seznam názvů příznaků spojených logickými operátory &&, || a !. Překladač zahrne kód uvnitř #if ... #endif pouze pokud je podmínka pravdivá.

Vestavěné podmínky Swift

Swift poskytuje několik vestavěných podmínek: DEBUG (automaticky aktivní v debug sestavení), swift(>=5.0) (kontrola verze překladače), canImport(UIKit) (kontrola dostupnosti modulu) a targetEnvironment(simulator) (kontrola prostředí). Tyto podmínky nevyžadují další konfiguraci.

// Vestavěné podmínky Swift
#if DEBUG
    print("Debug sestavení — logování aktivní")
#endif

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

Vlastní příznaky v Xcode

Vývojář může přidávat vlastní příznaky prostřednictvím Build Setting OTHER_SWIFT_FLAGS v Xcode. Příznak se uvádí s předponou -D, například -DBETA nebo -DANALYTICS_ENABLED. Pro různé konfigurace (Debug, Release, Staging) lze nastavit různé sady příznaků.

// Zpracování vlastního příznaku BETA
#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
}

Platformní podmínky #if os()

Swift podporuje platformní podmínky: os(iOS), os(macOS), os(tvOS), os(watchOS), os(Linux), os(Windows). Tyto podmínky kontrolují cílovou platformu sestavení a umožňují psát společný kód pro více platforem Apple s bloky specifickými pro platformu.

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
}

Analogie v Android a Kotlin

V ekosystému Android jsou Active Compilation Conditions implementovány prostřednictvím systému BuildConfig, productFlavors a příznaků v build.gradle.kts. Kotlin nemá přímou analogii direktivy #if na úrovni jazyka, ale poskytuje alternativní mechanismy.

Pole BuildConfig jako příznaky

Nejčastější způsob — přidat buildConfigField pro každý příznak: buildConfigField("boolean", "BETA", "true"). Tato pole jsou generována ve třídě BuildConfig pro každý Build Variant zvlášť. Pole DEBUG je již vestavěno a automaticky true pro debug sestavení.

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

// Použití v kódu Kotlin
if (BuildConfig.BETA) {
    enableBetaFeatures()
}

Source Sets a productFlavors

Gradle umožňuje vytvářet samostatné adresáře sourceSets pro každý flavor. Například src/demo/ a src/full/. Třídy se stejným názvem v různých sourceSets se navzájem nahrazují při sestavení příslušného flavoru. Jedná se o silnější mechanismus než příznaky, protože lze přepsat celé třídy.

// 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
}

Pro Kotlin Multiplatform (KMP) je k dispozici direktiva expect/actual, která umožňuje deklarovat očekávané deklarace ve společném kódu a poskytovat platformní implementace. Jedná se o mechanismus na úrovni překladu, svým účinkem podobný Active Compilation Conditions — neaktivní kód není překládán pro nevhodné platformy.

Scénáře použití a nejlepší postupy

Active Compilation Conditions se používají ve čtyřech hlavních scénářích: ladění (logy, inspektory), A/B testování (příznaky funkcí), platformní adaptace (společný kód iOS/macOS) a licencování (bezplatné/placené verze).

Ladicí logování

Nejčastější scénář — podmíněné logování. V debug sestavení jsou všechny logy zapisovány do konzole, v release — žádné. Použití #if DEBUG nebo BuildConfig.DEBUG zaručuje, že release binární soubor neobsahuje žádné volání loggeru, ani inline.

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

Feature Flags ve fázi sestavení

Pokud nová funkcionalita ještě není připravena pro produkci, ale již existuje v kódu, lze ji skrýt za příznak překladu. Na rozdíl od runtime feature flags příznaky překladu nezatěžují aplikaci kontrolami a nemohou být uživatelem zapnuty.

• Nové funkce — skryjte nedokončenou funkcionalitu do dalšího vydání bez mazání kódu
• Analytika — zapněte dodatečný sběr metrik pouze pro beta testery
• SDK třetích stran — vylučte těžké knihovny z bezplatné verze aplikace
• UI komponenty — zobrazujte experimentální obrazovky pouze v staging sestavení

Nejlepší postupy

Active Compilation Conditions by měly být používány s mírou. Nadměrný počet příznaků činí kód obtížně srozumitelným: vývojář si nemůže být jistý, které větve se v daném okamžiku překládají. Doporučuje se dokumentovat každý příznak v README nebo speciálním souboru CONFIG.md.

Ve velkých projektech s distribuovaným týmem je užitečné implementovat automatickou validaci příznaků v CI. Každý pull request by měl projít sestavením se všemi možnými kombinacemi Active Compilation Conditions. To zaručuje, že se kód pod neaktivním příznakem nerozbil kvůli refaktorování a žádná větev podmíněného překladu nezůstala nezkontrolována až do vydání. Nástroje jako xcresulttool (pro iOS) a Gradle Build Scan (pro Android) pomáhají tento proces automatizovat.

• Minimum příznaků — ne více než 5-7 aktivních podmínek na projekt. Každý příznak je bodem složitosti.
• Konvence pojmenování — všechny příznaky v UPPER_CASE, s předponou projektu: MYAPP_BETA, MYAPP_ANALYTICS.
• Code review — každé přidání #if nebo buildConfigField by mělo projít samostatnou kontrolou.
• Testování — CI by mělo sestavovat všechny možné kombinace příznaků alespoň jednou denně.