移动应用中的条件编译 — 本质、指令及工作原理

什么是条件编译

条件编译是一种机制，编译器通过它分析条件编译指令，并仅将满足条件的代码块包含到输出的二进制文件中。这使得可以拥有适应不同目标平台和配置的统一代码库。

该概念源于C/C++的预处理器指令#ifdef、#ifndef、#endif。在现代语言（Swift、Rust、Go）中，该机制在编译器级别工作，无需单独的预处理器，从而提高了安全性：条件块即使在未被编译的情况下也必须是语法正确的。

根据Apple WWDC “Embrace Swift”（2025）会议的数据，大约40%的Swift项目使用条件编译来在单个目标中支持iOS和macOS。对于使用UIKit和SwiftUI的项目，UI代码通常通过#if os(iOS)和#if os(macOS)指令分离，从而允许重用业务逻辑。

主要优势——编译时安全性。不适合平台的代码不仅不会执行，而且不会被编译。这意味着iOS特定代码中的错误不会在构建macOS时出现，反之亦然。运行时检查无法提供这样的保证。

Swift中的条件编译

Swift提供四个关键指令：#if、#elseif、#else、#endif。与C预处理器不同，Swift要求所有分支中的代码在语法上都是正确的——编译器解析所有代码，但仅为活动分支生成机器代码。

平台检查 os()

Swift支持内置的检查函数：os(iOS)、os(macOS)、os(tvOS)、os(watchOS)、os(Linux)、os(Windows)。这些函数检查应用程序构建的目标平台。与&&和||的组合允许创建复杂条件。

// 适用于iOS、macOS和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
    }
}

编译器版本检查

Swift支持检查编译器版本：#if swift(>=5.9)。这对于支持多个Swift版本的库和框架非常有用。语言的新功能（例如Swift 5.9中的宏）可以通过这样的检查来保护。

// 向后兼容
#if swift(>=5.9)
    @MainActor
    struct ModernView: View {
        var body: some View {
            Text("现代SwiftUI")
        }
    }
#else
    struct ModernView: View {
        var body: some View {
            Text("旧版SwiftUI")
        }
    }
#endif

模块可用性检查 canImport()

canImport(ModuleName)函数检查指定模块在当前构建环境中是否可用。这是最灵活的机制：它不绑定到特定的平台。例如，使用CoreHaptics的代码将仅在该框架可用的设备上编译。

#if canImport(CoreHaptics)
    import CoreHaptics

    class HapticManager {
        private var engine: CHHapticEngine?

        func playTapFeedback() {
            guard let engine else { return }
            // 触觉反馈的实现
        }
    }
#endif

Kotlin和Android中的替代方案

Kotlin语言没有预处理器指令。取而代之的是，Android生态系统提供了三种替代方案：BuildConfig字段（运行时检查）、sourceSets（替换整个文件）和expect/actual（在Kotlin Multiplatform中）。

Gradle中的Source Sets

Gradle sourceSets允许为不同的构建变体或类型拥有不同的类实现。在src/debug/目录中是debug的实现，在src/release/中是release的实现。构建时，Gradle选择相应的sourceSet并仅编译其文件。

// 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) {
        // release中的无操作
    }
}

Kotlin Multiplatform中的Expect/Actual

KMP提供expect（在共享代码中声明）和actual（针对特定平台的实现）机制。这是一种编译时机制：对于iOS，从iOS sourceSet编译actual实现；对于Android，从Android sourceSet编译。非目标实现不会被编译。

// commonMain — expect声明
expect fun getPlatformName(): String

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

// iosMain — 适用于iOS的actual
actual fun getPlatformName(): String =
    UIDevice.current.systemName() + " " + UIDevice.current.systemVersion

C/C++预处理器与NDK

通过Android NDK开发原生库时，使用带有#ifdef、#ifndef、#define指令的经典C/C++预处理器。与Swift不同，C预处理器在文本级别工作——非活动分支中的代码可能在语法上不正确。

NDK平台标志

NDK为每个平台定义宏：__ANDROID__（Android）、__APPLE__（iOS/macOS）、__linux__（Linux）。对于架构：__arm__、__aarch64__、__x86_64__。这些宏由编译器在为目标平台构建时自动设置。

// 适用于Android和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

在使用NDK时，重要的是要记住C/C++预处理器是文本替换。如果非活动分支中存在语法错误，编译器不会看到它，但如果由于错误的#define导致活动分支损坏——错误就会出现。建议最小化#define链并使用constexpr常量。

对于也通过UniFFI和Mozilla Application Services用于移动开发的Rust，有自己独特的机制——Cargo.toml中的feature flags。Rust中像#[cfg(target_os = "android")]这样的标志与Swift指令类似地工作：检查在编译器级别进行，而非预处理器级别。这使得Rust成为需要从统一代码库为Android和iOS编译的原生库的有吸引力的选择。

实际场景与反模式

条件编译在严格定义的场景中有效。当使用不当时，会产生难以测试和维护的坏味道代码。让我们看看正确的场景和典型错误。

正确场景

第一个场景——平台抽象：统一外观，内部条件编译选择平台实现。第二个——调试和分析：不应进入发布版本的开发者工具。第三个——向后兼容：在最低版本更新之前支持旧版本操作系统。

反模式

最危险的反模式——指令遍布整个代码。如果每两个文件中就有一个包含#if，这是架构需要重构的信号。正确的解决方案——将平台代码分离到协议/接口之后并使用依赖注入。

• 每个文件中都有#if — 架构反模式。平台代码应通过协议隔离。
• 嵌套#if — 很快变得不可读。嵌套深度不应超过2层。
• 重复整个函数 — 如果函数完全复制到了#if和#else中，应将其提取到公共部分。
• 测试 — 非活动分支中的代码未经测试。需要在CI中构建所有可能的组合。
• 魔法标志 — 新开发者团队不知道的未记录的标志。