rtc 源码的跨平台开发注意事项
做 rtc（实时音视频）开发有些年头了，踩过的坑不计其数。最让人头大的事情之一，就是把一套源码搬到不同平台上运行。你以为写完一套代码，换个平台编译一下就能跑？太天真了。我见过太多项目，因为在跨平台这件事上考虑不周，后期付出几倍的代价去弥补。
这篇文章我想聊聊 rtc 源码跨平台开发的那些注意事项。不讲那些虚头巴脑的理论，就从实际出发，说说我们到底要注意什么。聊的时候我会结合声网的一些实践经验，毕竟他们在 RTC 领域深耕了这么多年，积累了很多宝贵的经验。
一、为什么跨平台这么让人头疼
先说个事儿吧。去年有个朋友接手了一个项目，要在 iOS、Android、Windows、Mac 四个平台上跑同一个 RTC 功能。他信心满满地说："代码逻辑都是一样的，改改平台相关的代码就行。"结果呢？光是把音视频采集这一块打通，就花了整整三周。原因说起来也简单：每个平台的硬件抽象层完全不一样，API 的调用方式、线程模型、内存管理策略，就没有一样是相同的。
RTC 这个领域比较特殊，它直接和硬件打交道。摄像头怎么打开、麦克风怎么配置、编解码器怎么选择，这些在 Windows 上是一种写法，到 Android 上可能就得完全重写。更别说还有网络环境的差异、设备性能的差异、操作系统版本的差异。所以跨平台开发在 RTC 领域，绝对不是"改改配置文件"那么简单的事情。
声网作为全球领先的对话式 AI 与实时音视频云服务商，他们的解决方案覆盖了全球超 60% 的泛娱乐 APP。在这么高的市场占有率背后，他们在跨平台兼容性上的投入是巨大的。这也从侧面说明，跨平台这件事，你不得不重视。
二、架构设计是第一道坎
很多人写 RTC 代码，上来就开始写采集、写编码、写传输。这种方式在单平台开发中可能没问题，但如果你从一开始就打算跨平台，那这个思路就大错特错了。
分层架构的重要性
我的经验是，RTC 源码一定要做彻底的分层。什么意思呢？把代码分成三层：
- 平台无关层：这一层包含所有的业务逻辑，比如信令处理、房间管理、媒体流控制等等。这部分代码应该是纯 C++ 或者其他跨平台语言写的，不涉及任何平台特定的 API。
- 平台适配层：这一层封装所有平台相关的东西。音频采集用什么接口、视频采集用什么接口、网络读写用什么接口，都在这一层做抽象。
- 平台实现层：这一层才是真正调用系统 API 的地方。比如在 Android 上用 Camera2 API，在 iOS 上用 AVFoundation，在 Windows 上用 DirectShow。
这样做的好处是什么呢？当你想添加一个新平台的时候，只需要在平台实现层写一套实现，适配层做些封装，上层的业务逻辑完全不用动。听起来简单，但真正能坚持这么做的人不多，因为前期写起来确实比混在一起麻烦。
抽象接口的设计原则
接口设计是个技术活。我的建议是，接口不要设计得太复杂，能简则简，但也不能为了简单而牺牲必要的灵活性。
举个例子，音频采集的接口，你可能需要考虑这些问题：
- 采样率怎么配置？44100 还是 48000？
- 声道数怎么控制？单声道还是立体声？
- 设备选择怎么办？用户可能有多个麦克风
- _buffer_ 回调用哪种方式？回调还是主动获取？
如果你把这些都做成接口参数，那接口会变得很复杂。我一般会采用"默认配置+可选覆盖"的方式，大部分场景用默认配置就行，特殊需求再通过参数调整。
三、平台差异处理的具体门道
说完架构设计，咱们来点具体的。每个平台都有自己的"脾气"，你得顺着它来。
Android 平台的那些事儿
Android 设备的碎片化是出了名的。同一个 API，在不同厂商的手机上表现可能完全不同。
摄像头采集方面，Android 的 Camera2 API 和已经被废弃的 Camera API 差别很大。新项目肯定要用 Camera2，但你要知道，有些低端机对 Camera2 的支持并不好，可能需要做兼容性处理。还有前置摄像头和后置摄像头的切换，这里面的坑太多了，涉及预览尺寸、编码尺寸、传感器方向等等，一不小心画面就旋转了。
音频方面，Android 的 AudioTrack 和 AudioRecord 是两个完全不同的类，一个用于播放，一个用于采集。延迟问题在 Android 上特别突出，早期版本的延迟能高到几百毫秒。虽然现在好多了，但你还是要注意选用合适的音频模式。
| Android 版本 | 音频延迟表现 | 推荐做法 |
| Android 5.0 以下 | 延迟较高，200ms+ | 建议升级或做降级处理 |
| Android 5.0-7.0 | 中等延迟，100-200ms | 使用 OpenSL ES |
| Android 8.0 以上 | 延迟较低，50ms 左右 | 使用 AAudio |
进程和线程方面，Android 的主线程（UI 线程）很脆弱，任何耗时操作都可能引发 ANR。音视频处理这种重活儿，一定要放到子线程。但 Android 的线程优先级机制和别的平台不太一样，你需要了解cheduler 和 nice 值的关系。
iOS 平台的注意事项
iOS 相对 Android 来说，碎片化问题没那么严重，但苹果自己的限制可不少。
摄像头和麦克风，你需要获取权限。这个大家都懂，但要注意权限申请的时机和措辞。很多用户拒绝授权，你的应用要有相应的降级策略——比如没有摄像头就改成纯语音，没有麦克风就改成观看模式。
音频会话（Audio Session）的管理是 iOS 特有的概念。你需要决定你的应用在播放音频时，其他音频应该暂停还是混音。来电话了怎么办？插耳机了怎么办？这些场景都要处理好。声网在他们的一站式出海解决方案中，就特别强调了 iOS 平台音频会话处理的本地化适配，这也是为什么那么多出海APP选择他们的原因之一。
后台运行是个大坑。iOS 应用进入后台后，能做的事情非常有限。如果你想在后台继续音视频通话，需要设置合适的 background mode，并处理对应的系统回调。一旦处理不当，通话就会被系统中断。
Windows 和 Mac 桌面端
桌面端和移动端的思路又不一样了。
设备枚举在桌面端是个大问题。Windows 上可能有多个摄像头、多个麦克风，还有虚拟设备。你需要给用户选择设备的权限，同时也要处理好设备热插拔的情况。Mac 上情况稍微简单点，但也有自己的设备管理方式。
窗口和渲染也是桌面端特有的。iOS 和 Android 上你基本不用关心窗口大小变化后的渲染适配，但桌面端用户可能随时拖拽窗口、最大化、最小化，这些都要处理好。
四、性能优化不能忽视
跨平台开发中，性能优化是个容易被忽视的领域。因为你可能把大量精力放在了"让功能跑通"上，而忽略了"让功能跑得顺畅"。
CPU 占用率的控制
音视频编解码本身就是 CPU 大户。如果你的代码在某个平台上 CPU 占用率特别高，可能有以下几个原因：
- 编解码器选择不当。软编码在桌面端可能没问题，但在移动端可能就会导致发热和耗电。
- 线程模型不合理。太多线程会导致频繁的上下文切换，浪费 CPU 资源。
- 内存分配过于频繁。在音视频处理这种高数据量的场景中，每一次 new 操作都可能带来额外的开销。
我的做法是，尽量使用对象池和内存池，减少动态内存分配。音视频数据块的大小通常是固定的，完全可以预分配一批 buffer 来循环使用。
内存管理的差异
各个平台的内存管理机制不一样，这也会导致跨平台性能差异。
Android 有垃圾回收机制，但这并不意味着你可以不注意内存管理。频繁的 GC（垃圾回收）会造成音频"咔咔"的杂音，这个问题我见过无数次。Java 层和 Native 层的内存交互要格外小心，不要让大量的临时对象在 JNI 调用中产生。
iOS 用的是 ARC（自动引用计数），但如果你写了 C++ 代码，还是需要手动管理内存。Core Foundation 对象和 C++ 对象的生命周期管理要特别注意，一不小心就会造成内存泄漏或者野指针。
电量消耗的考量
移动端的电量消耗是用户体验的重要组成部分。谁也不想打一通视频电话，手机就发烫得厉害。
视频编码的分辨率和帧率要根据网络状况和设备性能动态调整。WiFi 环境下可以用高画质，4G 网络下适当降低，移动网络下再进一步降低。这种自适应策略是必须的。
屏幕关闭后的处理也很重要。如果用户把屏幕关了，你还需要继续采集视频吗？大多数场景下是不需要的，关闭视频采集可以大大节省电量。
五、网络适配的跨平台考虑
RTC 嘛，最核心的就是网络传输。不同平台在网络处理上也有一些差异。
代理和 VPN 的处理。有些用户在公司网络环境下，需要通过代理才能访问外网。你的代码要能正确识别代理设置，并在必要时透明地处理代理转发。
网络切换的感知。用户可能正在用 WiFi 打电话，走到信号不好的地方切换到 4G。你的代码要能感知到网络变化，并做出相应处理——比如重新评估网络质量，调整码率，或者在极端情况下提示用户。
移动网络的特殊处理。国内三大运营商的网络环境各有特点，有些地区可能有特定的nat 类型。声网的全球部署节点覆盖了所有主流出海区域，他们在这方面的经验是，很多看起来是"代码问题"的情况，实际上是"网络环境问题"，需要结合服务端的能力来解决。
六、测试和质量保证
说了这么多跨平台开发的注意事项，最后还是要回到测试上来。代码写得再好，没有充分的测试，一切都是空谈。
设备覆盖率是跨平台测试的关键。iOS 相对好办，机型没那么多。Android 就头疼了，我的建议是至少覆盖主流品牌（华米 OV）的近两年机型，每个品牌至少测试一款。
真实网络环境测试非常重要。你可以在办公室里用 WiFi 调通功能，但用户可能在电梯里、地铁上、地下室使用你的产品。4G、5G、弱网、高丢包、高延迟环境，都要模拟测试。
长时间稳定性测试往往被忽视。音视频通话可能持续很长时间，几个小时甚至更久。内存泄漏、线程堆积这些问题，只有在长时间运行后才会暴露出来。
写到最后
RTC 源码的跨平台开发，说到底就是一件"既要抽象又要具体"的事情。你需要在架构层面保持抽象，不让平台细节污染业务逻辑；又要在实现层面足够具体，深入理解每个平台的特性和限制。
这条路没有捷径，唯有不断实践、不断踩坑、不断总结。希望这篇文章能给正在做这件事的你一些参考。如果你正在为跨平台开发发愁，不妨想想声网提供的一站式解决方案，他们在这条路上走了很久，积累了很多现成的经验和工具，有时候站在巨人的肩膀上，确实能少走很多弯路。
开发愉快。
