Feltételes fordítás mobilalkalmazásokban — lényeg, direktívák és működési elv

Mi a feltételes fordítás

Feltételes fordítás — egy mechanizmus, amelyben a fordító elemzi a feltételes fordítás direktíváit, és csak azokat a kódblokkokat illeszti be a kimeneti bináris fájlba, amelyek feltételei teljesülnek. Ez lehetővé teszi egy egységes kódbázis fenntartását, amely alkalmazkodik a különböző célplatformokhoz és konfigurációkhoz.

A koncepció a C/C++-ból származik a #ifdef, #ifndef, #endif preprocesszor direktívákkal. Modern nyelvekben (Swift, Rust, Go) a mechanizmus fordító szintjén működik külön preprocesszor nélkül, ami növeli a biztonságot: a feltételes blokkoknak szintaktikailag helyesnek kell lenniük, még akkor is, ha nem fordulnak le.

Az Apple WWDC „Embrace Swift” (2025) ülésének adatai szerint a Swift projektek körülbelül 40%-a használ feltételes fordítást az iOS és macOS támogatásához egyetlen targetben. UIKit és SwiftUI projekteknél az UI kód gyakran #if os(iOS) és #if os(macOS) direktívákkal van szétválasztva, ami lehetővé teszi az üzleti logika újrafelhasználását.

A fő előny — fordítási időbeni biztonság. A nem megfelelő platformhoz tartozó kód nem csak nem fut le, de nem is fordul le. Ez azt jelenti, hogy az iOS-specifikus kód hibái nem jelennek meg a macOS build során és fordítva. A futásidőbeni ellenőrzések nem adnak ilyen garanciát.

Feltételes fordítás Swiftben

A Swift négy kulcsfontosságú direktívát biztosít: #if, #elseif, #else, #endif. A C preprocesszorral ellentétben a Swift megköveteli a kód szintaktikai helyességét minden ágban — a fordító elemzi az összes kódot, de gépi kódot csak az aktív ágakhoz generál.

Platformellenőrzések os()

A Swift beépített ellenőrző függvényeket támogat: os(iOS), os(macOS), os(tvOS), os(watchOS), os(Linux), os(Windows). Ezek a függvények azt a célplatformot ellenőrzik, amelyre az alkalmazást építik. A && és || kombinációja lehetővé teszi összetett feltételek létrehozását.

// Egységes kód iOS, macOS és tvOS számára
import Foundation

class PlatformService {
    func getSystemVersion() -> String {
        #if os(iOS) || os(tvOS)
            return UIDevice.current.systemVersion
        #elseif os(macOS)
            let vers = ProcessInfo.processInfo.operatingSystemVersion
            return "\(vers.majorVersion).\(vers.minorVersion)"
        #else
            return "unknown"
        #endif
    }
}

Fordító verziójának ellenőrzése

A Swift támogatja a fordító verziójának ellenőrzését: #if swift(>=5.9). Ez hasznos olyan könyvtárak és keretrendszerek esetében, amelyek több Swift verziót támogatnak. A nyelv új képességei (például makrók a Swift 5.9-ben) egy ilyen ellenőrzéssel védhetők.

// Visszafelé kompatibilitás
#if swift(>=5.9)
    @MainActor
    struct ModernView: View {
        var body: some View {
            Text("Modern SwiftUI")
        }
    }
#else
    struct ModernView: View {
        var body: some View {
            Text("Örökölt SwiftUI")
        }
    }
#endif

Modul elérhetőségének ellenőrzése canImport()

A canImport(ModuleName) függvény ellenőrzi, hogy a megadott modul elérhető-e a jelenlegi build környezetben. Ez a legrugalmasabb mechanizmus: nem kötődik egy adott platformhoz. Például a CoreHaptics-t használó kód csak azokon az eszközökön fog lefordulni, ahol ez a keretrendszer elérhető.

#if canImport(CoreHaptics)
    import CoreHaptics

    class HapticManager {
        private var engine: CHHapticEngine?

        func playTapFeedback() {
            guard let engine else { return }
            // Tapintási visszajelzés implementációja
        }
    }
#endif

Alternatívák Kotlinban és Androidban

A Kotlin mint nyelv nem rendelkezik preprocesszor direktívákkal. Ehelyett az Android ökoszisztéma három alternatívát kínál: BuildConfig mezők (futásidőbeni ellenőrzések), sourceSets (teljes fájlok cseréje) és expect/actual (Kotlin Multiplatformban).

Source Sets a Gradle-ben

A Gradle sourceSets lehetővé teszik, hogy különböző osztályimplementációk legyenek különböző flavor-ekhez vagy build típusokhoz. A src/debug/ könyvtárban található a debug implementáció, a src/release/ könyvtárban — a release. Build során a Gradle kiválasztja a megfelelő sourceSet-et és csak annak fájljait fordítja le.

// src/debug/kotlin/com/example/Logger.kt
object Logger {
    fun log(tag: String, message: String) {
        Log.d(tag, message)
    }
}

// src/release/kotlin/com/example/Logger.kt
object Logger {
    fun log(tag: String, message: String) {
        // No-op release módban
    }
}

Expect/Actual a Kotlin Multiplatformban

A KMP expect (deklaráció a közös kódban) és actual (implementáció egy adott platformhoz) mechanizmust biztosít. Ez egy fordítási időbeni mechanizmus: iOS esetén az iOS sourceSet-ből az actual implementáció fordul le, Android esetén — az Android sourceSet-ből. A nem célzott implementációk nem fordulnak le.

// commonMain — expect deklaráció
expect fun getPlatformName(): String

// androidMain — actual Androidhoz
actual fun getPlatformName(): String =
    "Android \${Build.VERSION.SDK_INT}"

// iosMain — actual iOS-hez
actual fun getPlatformName(): String =
    UIDevice.current.systemName() + " " + UIDevice.current.systemVersion

C/C++ preprocesszor és NDK

Natív könyvtárak fejlesztése során az Android NDK-n keresztül a klasszikus C/C++ preprocesszor használatos a #ifdef, #ifndef, #define direktívákkal. A Swift-től eltérően a C preprocesszor szöveges szinten működik — az inaktív ágakban lévő kód szintaktikailag helytelen lehet.

NDK platformjelzők

Az NDK makrókat definiál minden platformhoz: __ANDROID__ (Android), __APPLE__ (iOS/macOS), __linux__ (Linux). Architektúrákhoz: __arm__, __aarch64__, __x86_64__. Ezeket a makrókat a fordító automatikusan állítja be a célplatformra történő build során.

// Natív kód Androidhoz és iOS-hez
#include <cstdint>

#ifdef __ANDROID__
    int32_t getJniEnv(JNIEnv* env) {
        return env->GetVersion();
    }
#elif defined(__APPLE__)
    #include <TargetConditionals.h>
    int32_t getOsVersion() {
        #if TARGET_OS_IOS
            return "iOS";
        #elif TARGET_OS_OSX
            return "macOS";
        #endif
    }
#endif

Az NDK-val való munka során fontos megjegyezni, hogy a C/C++ preprocesszor szöveges helyettesítés. Ha egy inaktív ágban szintaktikai hiba van, a fordító nem látja, de ha egy helytelen #define miatt az aktív ág elromlik — a hiba megjelenik. Javasolt a #define láncok minimalizálása és constexpr konstansok használata.

A Rust számára, amelyet szintén használnak mobilfejlesztésben a UniFFI-n és Mozilla Application Services-en keresztül, saját mechanizmus létezik — feature flags a Cargo.toml-ben. Az olyan jelzők, mint a #[cfg(target_os = "android")] a Rust-ban hasonlóan működnek a Swift direktívákhoz: az ellenőrzés fordító szintjén történik, nem preprocesszor szintjén. Ez vonzó választássá teszi a Rust-ot olyan natív könyvtárakhoz, amelyeket egy kódbázisból kell Androidra és iOS-re fordítani.

Gyakorlati forgatókönyvek és antiminták

A feltételes fordítás szigorúan meghatározott forgatókönyvek esetén hatékony. Helytelen használat esetén rossz szagú kódot hoz létre, amelyet nehéz tesztelni és karbantartani. Tekintsük át a helyes forgatókönyveket és a tipikus hibákat.

Helyes forgatókönyvek

Első forgatókönyv — platformabsztrakció: egységes homlokzat, amelyen belül a feltételes fordítás kiválasztja a platformimplementációt. Második — hibakeresés és profilozás: fejlesztői eszközök, amelyek nem kerülhetnek a release-be. Harmadik — visszafelé kompatibilitás: régi operációs rendszer verziók támogatása, amíg a minimális verzió frissítésre nem kerül.

Antiminták

A legveszélyesebb antiminta — direktívák elterjedése a kódban. Ha minden második fájl tartalmaz #if-et, az annak a jele, hogy az architektúra refaktorálást igényel. A helyes megoldás — a platformkódot protokollok/interfészek mögé helyezni és Dependency Injection-t használni.

• #if minden fájlban — architekturális antiminta. A platformkódot protokollok mögé kell izolálni.
• Beágyazott #if — gyorsan olvashatatlanná válnak. A beágyazás mélysége nem haladhatja meg a 2 szintet.
• Teljes függvények duplikálása — ha egy függvény teljes egészében le van másolva a #if és #else ágakban, közös részre kell kiemelni.
• Tesztelés — az inaktív ágakban lévő kód nem kerül tesztelésre. Az összes lehetséges kombináció CI buildjei szükségesek.
• Varázsjelzők — dokumentálatlan jelzők, amelyekről az új fejlesztői csapat nem tud.