第28章跨平台开发

课程目录第28章跨平台开发

28、跨平台开发：Windows/Linux/macOS平台差异处理、CMake构建系统、条件编译

说实话，跨平台开发这事儿，我入行头三年都没太当回事。那时候一直在Windows上做项目，觉得换个平台编译一下不就行了？直到有一次，客户要求在Linux服务器上部署我们的音视频处理服务……好家伙，一编译全是错，链接器报了几百个警告。从那以后，我彻底老实了。

今天咱们就聊聊跨平台开发的那些坑，以及怎么用CMake和条件编译优雅地解决它们。

28.1 三大平台的“脾气”不一样

Windows、Linux、macOS，说白了都是操作系统，但底层差异比你想象的大得多。我整理了一张表，把最常见的差异列出来：

差异项	Windows	Linux	macOS
动态库后缀	.dll	.so	.dylib
静态库后缀	.lib	.a	.a
可执行文件后缀	.exe	无（或空）	无（或空）
路径分隔符	\	/	/
默认编码	UTF-16LE	UTF-8	UTF-8
线程API	CreateThread	pthread	pthread
套接字API	Winsock2	POSIX socket	POSIX socket
编译器	MSVC / MinGW	GCC / Clang	Clang / GCC

你看，光一个动态库后缀就够你喝一壶的。我在项目中遇到过最离谱的事——同事在Windows上写死了加载libavcodec.so，结果在macOS上死活跑不起来。嗯，这种低级错误其实很容易避免，只要用CMake抽象一下就好。

28.2 CMake：跨平台构建的“瑞士军刀”

我个人习惯用CMake管理所有C++项目，不管目标平台是哪个。为什么？因为CMake能帮你自动检测平台、编译器、库路径，省去大量手写Makefile的麻烦。

先看一个最基础的CMakeLists.txt：

cmake_minimum_required(VERSION 3.16)
project(AVProcessor VERSION 1.0.0 LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

# 添加可执行文件
add_executable(av_processor main.cpp audio.cpp video.cpp)

# 链接第三方库
target_link_libraries(av_processor PRIVATE
    ${CMAKE_DL_LIBS}
    Threads::Threads
)

这段代码在Windows、Linux、macOS上都能跑。你想想看，Threads::Threads这个目标，CMake会自动帮你找到pthread（Linux/macOS）或Windows线程库，完全不用你操心。

小技巧：我建议你在项目根目录放一个CMakePresets.json，这样团队成员可以直接用cmake --preset=release一键配置，避免每个人手动传参数。

28.3 条件编译：让代码“见风使舵”

条件编译说白了就是让同一份代码在不同平台上走不同分支。C++里最常用的就是预处理宏：

#include <iostream>

void print_platform_info() {
#ifdef _WIN32
    std::cout << "当前平台: Windows" << std::endl;
    std::cout << "编译器: MSVC" << std::endl;
#elif __APPLE__
    std::cout << "当前平台: macOS" << std::endl;
    #include <TargetConditionals.h>
    #if TARGET_OS_IPHONE
        std::cout << "设备: iOS" << std::endl;
    #else
        std::cout << "设备: Mac" << std::endl;
    #endif
#elif __linux__
    std::cout << "当前平台: Linux" << std::endl;
#else
    std::cout << "未知平台" << std::endl;
#endif
}

为什么会这样？因为每个平台预定义了不同的宏。Windows有_WIN32，macOS有__APPLE__，Linux有__linux__。这些宏是编译器自动定义的，你直接拿来用就行。

注意：我曾经在macOS上吃过亏——__APPLE__这个宏在iOS和macOS上都会被定义。如果你想区分iOS和macOS，必须额外包含TargetConditionals.h并检查TARGET_OS_IPHONE。别问我怎么知道的，问就是踩过坑。

28.4 音视频开发中的平台差异实战

音视频处理里，平台差异最集中的地方就是硬件加速和编解码器。我拿FFmpeg举个例子：

// 硬件加速设备选择
AVHWDeviceType get_best_hw_device() {
#ifdef _WIN32
    // Windows上优先用DXVA2或D3D11VA
    return av_hwdevice_find_type_by_name("d3d11va");
#elif __APPLE__
    // macOS上只能用VideoToolbox
    return av_hwdevice_find_type_by_name("videotoolbox");
#elif __linux__
    // Linux上优先用VAAPI，其次VDPAU
    AVHWDeviceType type = av_hwdevice_find_type_by_name("vaapi");
    if (type == AV_HWDEVICE_TYPE_NONE) {
        type = av_hwdevice_find_type_by_name("vdpau");
    }
    return type;
#else
    return AV_HWDEVICE_TYPE_NONE;
#endif
}

这段代码的逻辑很清晰：每个平台有自己专属的硬件加速方案。Windows用DirectX那一套，macOS用VideoToolbox，Linux用VAAPI。你硬要在Linux上调用D3D11，那肯定不行。

28.5 文件路径与编码的“隐形炸弹”

文件路径处理是跨平台开发里最容易出bug的地方。Windows用反斜杠，Linux和macOS用正斜杠。更坑的是，Windows的路径可能包含空格和中文，而Linux上文件名大小写敏感。

我的建议是：永远用正斜杠。CMake和C++标准库都支持正斜杠，Windows也能识别。至于编码问题，我习惯在Windows上用UTF-8，然后调用MultiByteToWideChar转成UTF-16再传给Windows API。

#include <filesystem>
namespace fs = std::filesystem;

// 统一用正斜杠
fs::path data_path = "data/videos/sample.mp4";

// 检查文件是否存在
if (!fs::exists(data_path)) {
    std::cerr << "文件不存在: " << data_path << std::endl;
    return -1;
}

你看，C++17的std::filesystem已经帮我们处理了大部分平台差异。路径分隔符、编码转换，它内部都搞定了。我个人强烈建议新项目直接用C++17及以上标准。

28.6 CMake中的平台检测与条件编译

除了在C++代码里用预处理宏，CMake本身也提供了强大的平台检测能力。我一般这样用：

# 检测操作系统
if(WIN32)
    message(STATUS "目标平台: Windows")
    add_definitions(-DPLATFORM_WINDOWS)
elseif(APPLE)
    message(STATUS "目标平台: macOS/iOS")
    add_definitions(-DPLATFORM_APPLE)
elseif(UNIX)
    message(STATUS "目标平台: Linux/Unix")
    add_definitions(-DPLATFORM_LINUX)
endif()

# 检测编译器
if(MSVC)
    message(STATUS "编译器: MSVC")
    add_compile_options(/W4 /utf-8)
elseif(CMAKE_CXX_COMPILER_ID MATCHES "Clang")
    message(STATUS "编译器: Clang")
    add_compile_options(-Wall -Wextra -Wpedantic)
elseif(CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
    message(STATUS "编译器: GCC")
    add_compile_options(-Wall -Wextra -Wpedantic)
endif()

这样，你在C++代码里就可以直接用#ifdef PLATFORM_WINDOWS了，不用记那些晦涩的编译器宏。

  核心思路：CMake负责“检测”和“传递”，C++代码负责“使用”。CMake检测到平台后，通过add_definitions或target_compile_definitions把宏传给编译器，C++代码里直接用这些宏做条件编译。职责清晰，维护方便。

28.7 跨平台音视频项目的目录结构

我习惯把平台相关的代码单独放文件夹，避免混在一起：

av_processor/
├── CMakeLists.txt
├── src/
│   ├── core/          # 平台无关的核心逻辑
│   ├── platform/      # 平台相关代码
│   │   ├── win/       # Windows专用
│   │   ├── linux/     # Linux专用
│   │   └── mac/       # macOS专用
│   └── utils/         # 工具函数
├── include/
│   └── av_processor/
├── third_party/       # 第三方库
└── tests/

然后在CMake里根据平台选择不同的源文件：

if(WIN32)
    list(APPEND PLATFORM_SOURCES
        src/platform/win/audio_capture_win.cpp
        src/platform/win/display_win.cpp
    )
elseif(APPLE)
    list(APPEND PLATFORM_SOURCES
        src/platform/mac/audio_capture_mac.mm
        src/platform/mac/display_mac.mm
    )
elseif(UNIX)
    list(APPEND PLATFORM_SOURCES
        src/platform/linux/audio_capture_linux.cpp
        src/platform/linux/display_linux.cpp
    )
endif()

add_executable(av_processor
    src/core/main.cpp
    src/core/decoder.cpp
    ${PLATFORM_SOURCES}
)

这样结构清晰，每个平台的代码互不干扰。你想想看，如果所有平台代码都写在同一个文件里，用#ifdef包来包去，那维护起来得多痛苦。

28.8 跨平台开发的“避坑指南”

最后分享几个我踩过的坑，希望能帮你少走弯路：

不要用#pragma once以外的非标准扩展——虽然主流编译器都支持，但万一遇到嵌入式或小众平台，你就哭了。
小心字节序（Endianness）——x86/x64都是小端，但ARM设备可能是大端。音视频数据里很多多字节数值，记得用htons/ntohl转换。
线程栈大小——Windows默认1MB，Linux默认8MB。如果你在Windows上创建大量线程，很容易栈溢出。我建议显式设置栈大小。
动态库加载路径——Windows搜当前目录和PATH，Linux搜LD_LIBRARY_PATH，macOS搜DYLD_LIBRARY_PATH。部署时一定要确认库能找得到。

嗯，跨平台开发就是这样——细节决定成败。但只要用好CMake和条件编译，把平台差异抽象好，其实也没那么可怕。

这张图把整个跨平台开发的流程串起来了。从CMake构建系统出发，检测目标平台，然后通过条件编译生成平台相关的代码，最终产出可执行文件。每一步都环环相扣，缺一不可。

我的建议：刚开始做跨平台项目时，别想着一步到位。先在Windows上把功能跑通，然后移植到Linux，最后再适配macOS。每移植一个平台，就把平台差异抽象出来，慢慢积累自己的跨平台工具库。这样既稳当，又能学到东西。

📚 课程目录

28、跨平台开发：Windows/Linux/macOS平台差异处理、CMake构建系统、条件编译

28.1 三大平台的“脾气”不一样

28.2 CMake：跨平台构建的“瑞士军刀”

28.3 条件编译：让代码“见风使舵”

28.4 音视频开发中的平台差异实战

28.5 文件路径与编码的“隐形炸弹”

28.6 CMake中的平台检测与条件编译

28.7 跨平台音视频项目的目录结构

28.8 跨平台开发的“避坑指南”