第二章：主流操作系统平台对比——Windows、macOS、Linux、Android、iOS
做跨平台SDK，第一关就是摸清这几个系统的脾气。我见过不少团队，代码写得挺漂亮，一上其他系统就崩得稀里哗啦。说白了，就是没把底层差异当回事。这一章咱们就把五个主流平台的核心差异掰开揉碎讲清楚。
核心认知：没有完美的操作系统，只有做对了兼容性适配的SDK。明白差异在哪，你才知道坑在哪。
2.1 系统内核：一切差异的起点
不同的内核，决定了进程怎么调度、内存怎么分配、文件怎么读写。我在项目中遇到过同一个多线程算法在Windows上跑得飞起，到Linux上就频繁死锁。原因？一个用的是Windows的IOCP，另一个压根没适配epoll。
| 系统 | 内核类型 | 调度模型 | 用户态/内核态边界 |
|---|---|---|---|
| Windows | 混合内核 (NT) | 优先级抢占式，多级反馈队列 | 边界清晰，通过系统调用切换 |
| macOS | 混合内核 (XNU) | 基于Mach的抢占式调度 | 边界清晰，采用微内核+BSD混合 |
| Linux | 宏内核 | 完全公平调度 (CFS) | 边界严格，系统调用开销相对低 |
| Android | 宏内核 (Linux定制) | CFS + cgroup约束 | 同Linux，但增加了Binder IPC |
| iOS | 混合内核 (XNU变体) | 基于Mach，受电源管理影响大 | 边界严格，沙盒化更强 |
你想想看，Linux的宏内核把所有驱动都塞进内核空间，性能高但出个Bug就容易整个系统崩掉。macOS和iOS的XNU内核则用Mach微内核管理最基本的任务，其他服务放在用户态。我刚开始做SDK时，就是因为没搞清楚这个区别，在macOS上直接用Linux的ioctl调用，结果接口全对不上。
2.2 文件系统与路径处理：一字之差，满盘皆输
这个坑我踩了不止一次。路径分隔符、大小写敏感性、特殊目录……每一项都能让SDK在测试阶段就暴露出兼容性问题。
注意：Windows文件系统默认不区分大小写，但Linux和macOS默认区分。这意味着你的SDK如果在Linux上创建了“Config.xml”，另一台机器上通过“config.xml”可能根本找不到它。我曾经因为这个问题，在CI/CD流水线上排查了整整一个下午。
| 维度 | Windows | macOS | Linux |
|---|---|---|---|
| 路径分隔符 | 反斜杠 (\)，但也支持正斜杠 (/) | 正斜杠 (/) | 正斜杠 (/) |
| 大小写敏感 | 不敏感 (NTFS默认) | 不敏感 (HFS+/APFS默认，但可配置) | 敏感 (ext4默认) |
| 根目录 | 盘符 (C:\) | / | / |
| 隐藏文件标记 | 文件属性 (FILE_ATTRIBUTE_HIDDEN) | 文件名以 . 开头 | 文件名以 . 开头 |
做SDK的时候，我建议你统一用处理路径的库，比如std::filesystem或者自己封一层。千万不要在代码里硬编码反斜杠或盘符。嗯，这里还要提一句：Android虽然也用Linux内核，但它的文件系统权限管理完全不同。普通App根本访问不了/data目录之外的系统分区。
2.3 图形子系统与UI差异
SDK如果不是纯后台服务，往往需要跟图形打交道。哪怕只是弹个通知，背后的机制都不一样。
- Windows: 传统用GDI/GDI+，现代用DirectX。窗口管理器是桌面窗口管理器 (DWM)。
- macOS: 采用Metal (替代了OpenGL) 和Core Graphics。窗口系统是Quartz Compositor。
- Linux: 分X11和Wayland两大阵营。图形库用OpenGL/Vulkan，窗口管理器各个桌面环境自己实现。
- Android: 用SurfaceFlinger合成，渲染走OpenGL ES或Vulkan。UI框架是View/Compose。
- iOS: 用Core Animation + Metal，UI框架是UIKit/SwiftUI。
核心问题来了：如果你的SDK需要在非UI线程操作UI控件，Android会直接抛异常，iOS则有可能无声无息地崩溃。我调试过的一个SDK，在Windows上没问题，到了macOS上通知弹窗总延迟。后来发现是macOS的主事件循环（RunLoop）跟Windows的消息泵（Message Pump）处理方式完全不一样。
2.4 进程与内存管理：沙盒的牢笼
这一点尤其影响移动端SDK的测试。Android和iOS的进程管理、内存限制，跟桌面系统完全是两个世界。
避坑指南：我曾经给一个图像处理SDK做移植，在Windows上跑了3GB内存都没事，一上iOS就闪退。为什么？iOS对单个App的内存有硬限制，老旧设备可能只有1GB左右。SDK一定要做内存水位检测，超标时主动降级。
| 特性 | 桌面 (Win/macOS/Linux) | 移动 (Android/iOS) |
|---|---|---|
| 进程创建 | fork/exec或CreateProcess，开销大 | Zygote预孵化 (Android)，launchd触发 (iOS) |
| 后台运行 | 可任意长驻后台 | 受限，有后台任务时间上限 |
| 沙盒机制 | 用户权限控制 (UAC/SELinux) | 强制沙盒，App间文件隔离 |
| 内存限制 | 由物理内存和交换空间决定，宽松 | 有硬上限，超限立即被Kill |
| 虚拟内存 | 支持交换分区/文件 | 无交换 (iOS)，有ZRAM (Android) |
你想想看，iOS的“墓碑机制”这个称呼不是白来的。App切到后台，系统随时可能把你的进程杀掉回收资源。SDK如果在后台做长连接或耗时计算，必须考虑状态保存和恢复逻辑。Android好一点，可以用Service，但Android 8.0以后后台Service也被严格限制了。
2.5 核心冲突领域一览
说了这么多，其实都可以总结到一张图里。下面这张SVG图展示了我在兼容性测试中常遇到的核心冲突领域，以及它们分别落在哪个平台组合上。
2.6 如何制定测试策略
了解了这些差异之后，你的测试策略就有了方向。我个人的习惯是按这个优先级来安排测试资源：
- 文件系统兼容性 —— 路径、大小写、权限，这是最容易出问题的地方。
- 进程生命周期 —— 特别是后台运行和内存回收，影响用户体验。
- 系统调用封装 —— SDK里用的每一种系统调用，都必须在目标平台上验证过。
- 线程模型与同步 —— 不同系统的锁实现、线程优先级映射机制都不同。
- 图形/UI组件 —— 如果是带界面的SDK，这个优先级调到最前面。
别想着一次性覆盖所有平台。你想想看，同时适配五个平台的SDK，发布初期能稳定跑通Windows和Android就已经很不错了。先把核心功能在这两个用户量最大的平台上打磨好，再扩展到macOS和iOS，最后考虑Linux。嗯，我就是这么做的。
小技巧：在SDK的构建系统里，用预定义宏 (比如 _WIN32, __APPLE__, __linux__, __ANDROID__, __arm__ 等) 来做条件编译。但记住，宏只能帮你选择代码路径，真正的系统行为测试必须跑在真机或原生虚拟机里。模拟器不能代替真机，我在iOS模拟器上测试过多线程代码一切正常，一到真机就崩，因为模拟器用的是Mac的XNU内核，跟iOS设备上受限的调度环境完全不同。
记住这些差异，你写SDK的时候就会多问自己一句：“这个函数在Linux上返回什么？在Android上会不会被系统杀掉？”带着这种敏感度，兼容性问题自然会少很多。