2、开发环境搭建：交叉编译工具链安装、FFmpeg与OpenGL ES依赖库编译、WebRTC Native源码编译
说实话，ARM平台上的WebRTC开发，最让人头疼的往往不是业务逻辑本身，而是环境搭建。我见过太多新手卡在这一步，工具链版本不对、依赖库编译不过、WebRTC源码下载到一半断掉……嗯，今天我们就一步步把这些坑填平。
2.1 交叉编译工具链：选对版本，事半功倍
交叉编译，说白了就是在你的x86电脑上编译出能在ARM板子上跑的程序。工具链的选择直接决定了后续所有工作的成败。
核心原则：工具链的GCC版本必须与你的ARM板子内核匹配。版本差太多，编译出来的二进制可能直接Segmentation Fault。
我个人习惯使用Linaro提供的工具链，稳定且社区活跃。以ARMv8（64位）平台为例，我常用的版本是gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu。为什么选这个？因为我在项目中踩过gcc 9.x编译WebRTC时某些内联汇编不兼容的坑，退回到8.3就一切正常。
# 下载并解压
wget https://releases.linaro.org/components/toolchain/binaries/latest-8/aarch64-linux-gnu/gcc-linaro-8.3.0-2019.03-x86_64_aarch64-linux-gnu.tar.xz
tar -xf gcc-linaro-8.3.0-2019.03-x86_64_aarch64-linux-gnu.tar.xz -C /opt/
# 设置环境变量（建议写入 ~/.bashrc）
export PATH=/opt/gcc-linaro-8.3.0-2019.03-x86_64_aarch64-linux-gnu/bin:$PATH
export CC=aarch64-linux-gnu-gcc
export CXX=aarch64-linux-gnu-g++
export AR=aarch64-linux-gnu-ar
export RANLIB=aarch64-linux-gnu-ranlib小技巧：验证工具链是否正常工作，直接编译一个hello.c，然后用file命令查看生成的二进制。输出应该是ELF 64-bit LSB executable, ARM aarch64。
2.2 FFmpeg依赖库编译：硬解码的基石
WebRTC在ARM平台上做屏幕共享，FFmpeg几乎是绕不开的。它负责视频的编解码、缩放、颜色空间转换。但FFmpeg的编译选项极其复杂，稍有不慎就会编译出一个“残废”版本。
我曾经在RK3399板子上编译FFmpeg，忘了开启--enable-neon，结果H.264软解码只能跑720p@15fps，开启NEON优化后直接飙到1080p@30fps。差距就是这么大。
# 下载FFmpeg 4.4（推荐，与WebRTC M94兼容性最好）
wget https://ffmpeg.org/releases/ffmpeg-4.4.tar.bz2
tar -xf ffmpeg-4.4.tar.bz2
cd ffmpeg-4.4
# 配置交叉编译
./configure \
--prefix=/opt/ffmpeg_arm \
--enable-cross-compile \
--cross-prefix=aarch64-linux-gnu- \
--arch=aarch64 \
--target-os=linux \
--enable-gpl \
--enable-nonfree \
--enable-neon \
--enable-hwaccels \
--enable-ffmpeg \
--disable-ffplay \
--disable-ffprobe \
--disable-doc \
--enable-libx264 \
--enable-libx265 \
--extra-cflags="-I/opt/x264_arm/include" \
--extra-ldflags="-L/opt/x264_arm/lib"
make -j$(nproc)
make install注意：如果你需要H.264硬件编码（如RK平台的MPP），必须额外配置--enable-mpp和--enable-rkmpp。否则FFmpeg会回退到软编码，CPU直接拉满。
2.3 OpenGL ES依赖库：屏幕共享的渲染引擎
WebRTC的屏幕共享功能，底层依赖OpenGL ES来做帧缓冲区的读取和渲染。ARM平台通常使用Mali或Adreno GPU，对应的OpenGL ES库需要提前编译好。
这里有个坑：很多ARM开发板的BSP自带的OpenGL ES库是闭源的二进制，只提供了libGLESv2.so和libEGL.so。你不需要重新编译，但必须确保头文件路径正确。
| GPU类型 | 常见平台 | 库文件位置 | 头文件来源 |
|---|---|---|---|
| Mali G52 | RK3566/RK3568 | /usr/lib/aarch64-linux-gnu/ | BSP中的mali-headers |
| Mali G610 | RK3588 | /usr/lib/aarch64-linux-gnu/ | BSP中的mali-headers |
| Adreno 610 | QCS610/QRB5165 | /usr/lib/ | Qualcomm LE SDK |
# 假设你的BSP已经安装了OpenGL ES库
# 只需要设置PKG_CONFIG_PATH让编译系统找到它们
export PKG_CONFIG_PATH=/usr/lib/aarch64-linux-gnu/pkgconfig:$PKG_CONFIG_PATH
# 验证是否可用
pkg-config --cflags --libs glesv2
# 输出应该类似：-I/usr/include -lGLESv2避坑指南：我曾经在RK3588上编译WebRTC，发现屏幕共享时帧率只有个位数。排查了半天，发现是OpenGL ES的EGL扩展EGL_EXT_platform_base没有正确链接。解决方案是在编译WebRTC时显式加上-lEGL -lGLESv2。
2.4 WebRTC Native源码编译：核心环节
终于到了最关键的步骤。WebRTC的编译系统基于Google的depot_tools，第一次编译需要下载大量源码（约15GB），请确保你的网络稳定。
我个人建议使用M94版本，原因有二：一是这个版本对ARM64的支持已经非常成熟；二是API相对稳定，后续章节的代码示例都基于这个版本。
# 1. 安装depot_tools
git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
export PATH=$PWD/depot_tools:$PATH
# 2. 获取WebRTC源码
mkdir webrtc_arm && cd webrtc_arm
fetch --nohooks webrtc
gclient sync
# 3. 切换到M94版本
cd src
git checkout branch-heads/4606
gclient sync
# 4. 配置ARM64交叉编译
mkdir -p out/arm64_release
cat > out/arm64_release/args.gn <关键参数说明：
rtc_use_h264 = true：开启H.264支持，屏幕共享必备rtc_use_openh264 = true：使用OpenH264软件编码器，兼容性好use_custom_libcxx = false：使用板子自带的libc++，避免ABI冲突treat_warnings_as_errors = false：ARM平台有些警告不影响运行，直接忽略
2.5 整体架构与依赖关系
下面这张图展示了整个开发环境的依赖关系。你可以看到，WebRTC Native库位于最上层，下面依次是FFmpeg、OpenGL ES和系统内核驱动。每一层都依赖下一层提供的接口。
2.6 验证编译结果
编译完成后，你会得到几个关键产物。我建议你重点检查以下文件是否存在：
# 检查编译产物
ls -lh out/arm64_release/obj/libwebrtc.a
ls -lh out/arm64_release/obj/rtc_base/librtc_base.a
ls -lh out/arm64_release/obj/api/libmedia_engine.a
# 检查是否包含H.264支持
aarch64-linux-gnu-objdump -t out/arm64_release/obj/libwebrtc.a | grep H264快速验证：写一个简单的测试程序，调用webrtc::CreatePeerConnectionFactory()，交叉编译后放到板子上运行。如果程序不报错且能正常初始化，说明环境搭建成功。