Kondisyonal na Kompilasyon sa mga Mobile App — esensya, direktiba, at prinsipyo ng paggana

Ano ang Kondisyonal na Kompilasyon

Kondisyonal na kompilasyon ay isang mekanismo kung saan sinusuri ng compiler ang mga direktiba ng kondisyonal na kompilasyon at isinasama sa output binary file ang mga bloke ng code lamang na natutugunan ang mga kondisyon. Ito ay nagpapahintulot na magkaroon ng isang pinag-isang codebase na umaangkop sa iba't ibang target na platform at configuration.

Ang konsepto ay nagmula sa C/C++ na may mga preprocessor directive na #ifdef, #ifndef, #endif. Sa mga modernong wika (Swift, Rust, Go) ang mekanismo ay gumagana sa antas ng compiler nang walang hiwalay na preprocessor, na nagpapataas ng seguridad: ang mga kondisyonal na bloke ay dapat na syntactically tama, kahit na hindi sila nai-compile.

Ayon sa datos mula sa Apple WWDC session na “Embrace Swift” (2025), humigit-kumulang 40% ng mga Swift project ang gumagamit ng kondisyonal na kompilasyon para suportahan ang iOS at macOS sa isang target. Para sa mga proyektong may UIKit at SwiftUI, ang UI code ay kadalasang pinaghihiwalay ng mga direktiba na #if os(iOS) at #if os(macOS), na nagpapahintulot sa muling paggamit ng business logic.

Ang pangunahing bentahe — kaligtasan sa oras ng kompilasyon. Ang code para sa hindi angkop na platform ay hindi lamang hindi naisasagawa, kundi hindi rin nai-compile. Nangangahulugan ito na ang mga error sa iOS-specific code ay hindi lilitaw sa pagbuo para sa macOS at vice versa. Ang mga runtime check ay hindi nagbibigay ng ganoong garantiya.

Kondisyonal na Kompilasyon sa Swift

Ang Swift ay nagbibigay ng apat na pangunahing direktiba: #if, #elseif, #else, #endif. Hindi tulad ng C preprocessor, ang Swift ay nangangailangan ng syntactical correctness ng code sa lahat ng branch — pinaparse ng compiler ang lahat ng code, ngunit gumagawa ng machine code para lamang sa mga aktibong branch.

Mga Pagsusuri ng Platform os()

Sinusuportahan ng Swift ang mga built-in na function ng pagsusuri: os(iOS), os(macOS), os(tvOS), os(watchOS), os(Linux), os(Windows). Ang mga function na ito ay sumusuri sa target na platform kung saan itinatayo ang application. Ang kombinasyon sa && at || ay nagpapahintulot sa paglikha ng mga komplikadong kondisyon.

// Pinag-isang code para sa iOS, macOS at tvOS
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
    }
}

Mga Pagsusuri ng Bersyon ng Compiler

Sinusuportahan ng Swift ang pagsusuri ng bersyon ng compiler: #if swift(>=5.9). Ito ay kapaki-pakinabang para sa mga library at framework na sumusuporta sa maraming bersyon ng Swift. Ang mga bagong kakayahan ng wika (halimbawa, macro sa Swift 5.9) ay maaaring protektahan ng naturang pagsusuri.

// Backward compatibility
#if swift(>=5.9)
    @MainActor
    struct ModernView: View {
        var body: some View {
            Text("Modernong SwiftUI")
        }
    }
#else
    struct ModernView: View {
        var body: some View {
            Text("Lumang SwiftUI")
        }
    }
#endif

Pagsusuri ng Availability ng Module canImport()

Ang function na canImport(ModuleName) ay sumusuri kung ang tinukoy na module ay available sa kasalukuyang build environment. Ito ang pinaka-flexible na mekanismo: hindi ito nakatali sa isang partikular na platform. Halimbawa, ang code na gumagamit ng CoreHaptics ay mai-compile lamang sa mga device kung saan available ang framework na ito.

#if canImport(CoreHaptics)
    import CoreHaptics

    class HapticManager {
        private var engine: CHHapticEngine?

        func playTapFeedback() {
            guard let engine else { return }
            // Implementasyon ng tactile feedback
        }
    }
#endif

Mga Alternatibo sa Kotlin at Android

Ang Kotlin bilang isang wika ay walang mga preprocessor directive. Sa halip, ang Android ecosystem ay nag-aalok ng tatlong alternatibo: mga field ng BuildConfig (runtime checks), sourceSets (pagpapalit ng buong file), at expect/actual (sa Kotlin Multiplatform).

Source Sets sa Gradle

Ang Gradle sourceSets ay nagpapahintulot na magkaroon ng iba't ibang implementasyon ng mga klase para sa iba't ibang flavor o uri ng build. Sa direktoryo na src/debug/ ay matatagpuan ang implementasyon para sa debug, sa src/release/ — para sa release. Sa pagbuo, pinipili ng Gradle ang naaangkop na sourceSet at ini-compile lamang ang mga file nito.

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

Expect/Actual sa Kotlin Multiplatform

Ang KMP ay nagbibigay ng mekanismo na expect (deklarasyon sa shared code) at actual (implementasyon para sa partikular na platform). Ito ay isang compile-time mechanism: para sa iOS, ang actual implementasyon mula sa iOS sourceSet ay nai-compile, para sa Android — mula sa Android sourceSet. Ang mga hindi target na implementasyon ay hindi nai-compile.

// commonMain — expect declaration
expect fun getPlatformName(): String

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

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

Preprocessor ng C/C++ at NDK

Sa pag-develop ng native libraries sa pamamagitan ng Android NDK, ginagamit ang classic na C/C++ preprocessor na may mga direktiba na #ifdef, #ifndef, #define. Hindi tulad ng Swift, ang C preprocessor ay gumagana sa tekstwal na antas — ang code sa mga hindi aktibong branch ay maaaring syntactically hindi tama.

Mga Flag ng Platform ng NDK

Ang NDK ay tumutukoy ng macro para sa bawat platform: __ANDROID__ (Android), __APPLE__ (iOS/macOS), __linux__ (Linux). Para sa mga arkitektura: __arm__, __aarch64__, __x86_64__. Ang mga macro na ito ay awtomatikong itinatakda ng compiler kapag nagbu-build para sa target na platform.

// Native code para sa Android at iOS
#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

Kapag nagtatrabaho sa NDK, mahalagang tandaan na ang C/C++ preprocessor ay isang tekstwal na pagpapalit. Kung may syntax error sa hindi aktibong branch, hindi ito makikita ng compiler, ngunit kung dahil sa maling #define ang aktibong branch ay masira — lilitaw ang error. Inirerekomenda na bawasan ang mga chain ng #define at gumamit ng constexpr constants.

Para sa Rust, na ginagamit din sa mobile development sa pamamagitan ng UniFFI at Mozilla Application Services, may sariling mekanismo — feature flags sa Cargo.toml. Ang mga flag tulad ng #[cfg(target_os = "android")] sa Rust ay gumagana katulad ng Swift directives: ang pagsusuri ay ginagawa sa antas ng compiler, hindi preprocessor. Ito ay ginagawang kaakit-akit na pagpipilian ang Rust para sa native libraries na kailangang i-compile para sa Android at iOS mula sa isang codebase.

Mga Praktikal na Senaryo at Anti-pattern

Ang kondisyonal na kompilasyon ay epektibo sa mahigpit na tinukoy na mga senaryo. Kapag ginamit nang hindi tama, lumilikha ito ng mabahong code na mahirap subukan at panatilihin. Tingnan natin ang mga tamang senaryo at karaniwang pagkakamali.

Mga Tamang Senaryo

Unang senaryo — abstraksyon ng platform: pinag-isang facade, sa loob kung saan pinipili ng kondisyonal na kompilasyon ang implementasyon ng platform. Pangalawa — debugging at profiling: mga tool ng developer na hindi dapat mapunta sa release. Pangatlo — backward compatibility: suporta para sa mga lumang bersyon ng operating system hanggang sa ma-update ang minimum na bersyon.

Mga Anti-pattern

Ang pinaka-mapanganib na anti-pattern — pagkalat ng mga direktiba sa buong code. Kung bawat ikalawang file ay naglalaman ng #if, ito ay isang senyales na ang arkitektura ay nangangailangan ng refactoring. Ang tamang solusyon — ilagay ang platform code sa likod ng mga protocol/interfaces at gumamit ng Dependency Injection.

• #if sa bawat file — arkitektural na anti-pattern. Ang platform code ay dapat ihiwalay sa likod ng mga protocol.
• Nested #if — mabilis na nagiging hindi nababasa. Ang lalim ng nesting ay hindi dapat lumagpas sa 2 antas.
• Pagdoble ng buong function — kung ang isang function ay ganap na kinopya sa #if at #else, dapat itong ilipat sa isang shared na bahagi.
• Pagsubok — ang code sa loob ng hindi aktibong branch ay hindi sinubukan. Kinakailangan ang CI builds ng lahat ng posibleng kombinasyon.
• Mga magic flag — hindi dokumentadong flag na hindi alam ng bagong team ng developer.