简介：这份资源提供面向iOS平台的FFmpeg交叉编译方案及完整编译产物，适合需要将FFmpeg集成到iPhone、iPad应用的移动开发者，解决armv7、armv7s、arm64与i386四种架构下的适配难题。资源包含FFmpeg源码、配置脚本、编译配置与大量音视频测试样本，总计2000个文件，以C源码、头文件、汇编文件、makefile及静态库等类型为主，压缩包约50.66MB。内容涵盖64位编译环境配置、交叉编译工具链设置、lipo合并fat binary等关键知识点，并附有test02ffmpeg等验证文件，便于在真机与模拟器上确认编译结果。已有376人学习，适合有一定iOS开发基础、希望自行裁剪与编译FFmpeg的中高级开发者作为参考资料。
1. 一套脚本解决 ffmpeg 64 位编译的四个架构问题：armv7/armv7s/arm64/i386 全打通
接手过一个老项目，底层音视频模块要支持 iOS 真机和模拟器，要求必须覆盖 armv7、armv7s、arm64、i386 四个架构。最头疼的不是 ffmpeg 本身的编译，而是四份架构产物如何一次生成、如何合并成通用静态库、如何在 Xcode 里顺利链接。这套 ffmpeg 64 位编译资源的核心价值，在于把完整的交叉编译流程固化成了可直接改参执行的脚本，适合还在维护 iOS 老工程、或者想在模拟器与真机之间无缝切换音视频能力的开发者。不用反复看网上碎片化的 configure 教程，顺着脚本走一遍就能拿到四架构 .a 文件。
2. 选型与原理：为什么是这四个架构，以及 Xcode 工具链的边界
2.1 架构与平台对应关系：armv7s 不是给新设备用的，但老工程离不开它
iOS 的架构演进决定了 ffmpeg 编译脚本里必须保留这一组架构组合：arm64 对应 iPhone 5s 之后的 64 位设备，所有提交 App Store 的新包都以它为绝对主力；armv7 覆盖的是 iPhone 4 到 iPhone 5C 时代的 32 位设备，目前仍有一些行业定制机在用；armv7s 只在 iPhone 5 和 iPad 4 上出现，属于过渡性质的架构，但老项目如果依旧保留最低 iOS 版本，并且不想单独维护两套产物，仍然需要把它编进去；i386 则是 32 位模拟器的架构，针对较老的 Mac 环境或特定 CI 机器。
实际编译时，这些架构不能混为一谈。真机和模拟器虽然都是 ARM 指令集，但模拟器产物运行在一个受系统管理的进程环境里，链接方式、系统调用接口都不同，不能把 arm64 真机产物直接改名丢进模拟器。脚本里为每个架构单独走一遍 configure、make、合并，就是为了让四份产物各归其位。armv7s 在这套资源里保留，主要是为了兼容老设备型号，如果你的部署目标只有 arm64，完全可以在脚本里删掉这一项，节省一半编译时间。
2.2 编译环境的三个前提：版本匹配、gas-preprocessor、SDK 路径
这套脚本对环境的要求没那么玄学，但有三个硬前提不满足，跑起来一定报错。第一是 Xcode 版本与 iOS SDK 的匹配。脚本里通过 xcrun 动态查找 SDK 路径，而不是写死一个 /Applications/Xcode 下的绝对路径，这样换机器、换 Xcode 版本时不用改脚本。我一般建议用 Xcode 13 或更老一点的版本编译这套全架构方案，因为新版 Xcode 对 armv7、armv7s、i386 的支持在逐步弱化，某些新版本里 i386 模拟器头文件都找不全。
第二是 gas-preprocessor。这个工具处理 ffmpeg 里汇编文件在 iOS 交叉编译环境下的预处理，没有它，编译会遇到 “unknown directive” 一类错误。网上的编译教程很少把这一步放前面，但实际踩坑概率极高，我通常在跑 ffmpeg configure 之前先把它放到 /usr/local/bin 下并确认可执行。
第三是 SDK 路径。用 xcrun --sdk iphoneos --show-sdk-path 查到的路径会被传入 configure 的 --sysroot，只有保证这个路径真实存在，编译器才能找到 UIKit、CoreMedia 等系统头文件。脚本里我习惯把这段动态查找逻辑写在架构循环外面，避免每次循环都重新查一遍。
2.3 64 位是硬要求：arm64 与 i386 在 iOS 生态里的角色
这套资源被搜索最多的场景就是“ffmpeg 64位编译”。arm64 不用多说，它是当前 iOS 生态的唯一主架构。i386 架构的 64 位意义体现在模拟器侧：在 Apple Silicon 出现之前，Mac 的 Intel 模拟器跑 32 位和 64 位进程都顺畅，但模拟器上的内存地址空间是 32 位限制的，处理大分辨率视频解码时容易碰上限。老工程想完整调试 64 位代码行为，必须在模拟器里跑 x86_64 而不是 i386，但那是另一套组合了。这套脚本里保留 i386，价值在于覆盖老设备模拟器以及一些第三方库仍然只产出 i386 静态库的旧工程。
需要留意的边界是，arm64e 不在脚本范围内。很多新工程会看到 arm64e 这个架构标签，但它是系统内部使用的优化架构，第三方库和应用层代码不需要编译它，苹果也不会接受提交 arm64e 版本的二进制。所以脚本聚焦 armv7、armv7s、arm64、i386 这四件套，是贴合老到新过渡期的实际方案。
3. 编译脚本实战：把 configure 参数、架构循环、第三方库打包成一条命令
3.1 架构循环与输出目录设计
这套脚本最核心的结构是一个 for 循环遍历四个架构，每个架构独立编译、独立产出 .a 文件，最后用 lipo 合并。以 bash 脚本为例，核心骨架如下：
#!/bin/bash # 基础变量：源码目录、输出目录、SDK 版本 FF_SRC=./ffmpeg-4.1 SCRATCH=./scratch OUT=./ffmpeg-ios # 架构列表：真机 armv7/armv7s/arm64，模拟器 i386 ARCHS=(armv7 armv7s arm64 i386) # 对外部库（模拟项目 X）的路径声明 X264_SRC=./x264 X264_LIB=./x264-ios # 先为每个架构准备 scratch 子目录 for ARCH in ${ARCHS[@]}; do mkdir -p "$SCRATCH/$ARCH" done这个循环结构是整个编译流程的骨架。ARCHS 数组的顺序有讲究：先把真机架构放前面编译，最后编模拟器，这样如果某个架构失败，你可以从日志里快速定位是哪个平台的问题。SCRATCH 目录用来存放每个架构的临时编译产物，不同架构的 object 文件混在一起会引发链接错乱，所以每个架构必须独立目录。我一般还会在脚本开头加一句 set -e，让某个架构编译失败时整个脚本立刻退出，避免带着错误继续往下跑，最后产出一个残缺的合并库。
3.2 configure 开关与裁剪选项
ffmpeg 的 configure 参数决定这个库有多大、支持哪些功能。老工程用 ffmpeg 最怕的就是静态库塞进 App 之后体积暴增，所以这套资源里体现出来的裁剪思路值得细看：
CONFIGURE_FLAGS="--enable-cross-compile \ --target-os=darwin \ --arch=$ARCH \ --sysroot=$SDK \ --cc=$CC \ --disable-programs \ --disable-doc \ --disable-encoders \ --disable-decoders \ --disable-hwaccels \ --disable-postproc \ --disable-avdevice \ --disable-devices \ --disable-network \ --disable-debug \ --disable-shared \ --enable-static \ --enable-pic \ --enable-encoder=aac \ --enable-decoder=h264,aac,pcm_s16le \ --enable-protocol=file \ --enable-muxer=mp4,flv \ --enable-demuxer=mov,flv \ --enable-parser=h264,aac"这段参数里，--disable-encoders 和 --disable-decoders 先整体关掉，再单独打开需要的编码器和解码器，是控制静态库体积最有效的手段。--disable-network 对本地文件播放场景几乎没影响，但能裁掉大量协议相关代码。--enable-pic 在 iOS 平台上必须保留，这是位置无关代码选项，否则链接到动态壳工程时可能报警告。target-os=darwin 告诉编译系统当前目标是苹果生态，arch 变量在循环里会被替换成 armv7、armv7s 这些具体值。
3.3 把脚本跑通：从下载源码到生成 .a 全家桶
实际跑这套脚本时，环境变量得先备好。下面是 x264 外部库和 ffmpeg 本体的编译流程，我按真实项目中可运行的顺序拆开写：
# 第一步：编译 x264 静态库（模拟项目 X 依赖它做编码） function build_x264() { for ARCH in ${ARCHS[@]}; do case $ARCH in armv7|armv7s|arm64) SDK_PATH=$(xcrun --sdk iphoneos --show-sdk-path) HOST="arm-apple-darwin" ;; i386) SDK_PATH=$(xcrun --sdk iphonesimulator --show-sdk-path) HOST="i386-apple-darwin" ;; esac cd $X264_SRC ./configure --host=$HOST --sysroot=$SDK_PATH \ --prefix=$X264_LIB/$ARCH --disable-asm \ --enable-static --disable-shared make clean make -j4 make install cd .. done } # 第二步：为每个架构编译 ffmpeg 本体 function build_ffmpeg() { for ARCH in ${ARCHS[@]}; do cd $FF_SRC ./configure $CONFIGURE_FLAGS \ --extra-cflags="-I$X264_LIB/$ARCH/include" \ --extra-ldflags="-L$X264_LIB/$ARCH/lib -lx264" \ --prefix=$OUT/$ARCH make clean make -j4 make install cd .. done } # 第三步：合并四个架构的静态库 function lipo_merge() { for LIB in libavcodec.a libavformat.a libavutil.a libswscale.a libswresample.a; do lipo -create \ $OUT/armv7/lib/$LIB \ $OUT/armv7s/lib/$LIB \ $OUT/arm64/lib/$LIB \ $OUT/i386/lib/$LIB \ -output $OUT/universal/$LIB done } build_x264 build_ffmpeg lipo_merge这段脚本里值得拆解的不是命令本身的难度，而是三个容易搞错的点。x264 的 --disable-asm 在 armv7s 和 i386 上尤其重要，老版本 x264 的内联汇编和 iOS 新工具链的兼容性很差，不开这个选项很可能死在汇编阶段。ffmpeg 的 --extra-ldflags 里 -lx264 必须排在库搜索路径之后，如果手抖把顺序写反，链接器找不到 x264 的符号。lipo_merge 里五个 .a 文件是 ffmpeg 的核心库集合，如果你裁剪时保留了其他 component，需要在这里手动加进去。
编译速度方面，在常规配置的 Mac mini 上，四架构全量编译大约需要 15 到 25 分钟，其中 arm64 单架构耗时最长。如果只是调试模拟器功能，临时把 ARCHS 改成 i386 arm64 两个架构，整个流程能压到 8 分钟以内。这也算是这套脚本的隐藏用法：架构列表是数组，想编几个就编几个，不用专门维护另一套脚本。
4. 避坑：编译期最容易翻车的 5 个位置
4.1 x264 静态库版本不一致导致的 Undefined symbols
现象：ffmpeg 的 configure 和 make 都成功，但最后链接到 Xcode 工程时报一堆 Undefined symbols，指向 x264_encoder_open 等符号。
原因：ffmpeg 编译时找到的 x264 头文件和最终链接进工程的 x264 静态库版本不一致。常见于系统里存在多个 x264 副本，configure 时搜到了新版本头文件，链接时却拿旧版本 .a 去用。
解决：脚本里强制为每个架构单独指定 --extra-cflags 和 --extra-ldflags，并且在 configure 输出信息里确认 “external libraries: x264” 这一行确实存在。实际操作中我会在编译前把 /usr/local/lib 下的 x264 相关文件暂时移走，确保不干扰工程内的版本。
4.2 gas-preprocessor 缺失引发的汇编报错
现象：编译到 libavcodec 的 arm 汇编文件时，报错信息类似 “unknown directive .arch armv7-a”，或者直接提示 gas-preprocessor.pl 找不到。
原因：ffmpeg 的 iOS 交叉编译依赖 gas-preprocessor 处理 ARM 汇编里的伪指令，这个工具不在 ffmpeg 源码树里，也不会被 configure 自动安装。新版 macOS 上 /usr/local/bin 的写权限问题也可能导致安装不成功。
解决：把 gas-preprocessor.pl 下载后放到 /usr/local/bin，并执行 chmod +x。更稳妥的方法是直接把脚本文件路径注入 PATH 环境变量，不必放进系统目录。从那以后我每换一台机器编译这套资源，第一件事就是执行 xcrun gas-preprocessor.pl 验证工具链可用，而不是直接跑 configure。
4.3 新版 Xcode 把警告当错误，编译中断
现象：make 过程中出现 “error: invalid output section name” 或者一堆 clang 警告后面跟着 exit code 1。
原因：新版 clang 对四架构的某些汇编语法比老版本更严格，一些历史悠久的 ffmpeg 版本在编译 armv7s 时会出现新工具链无法接受的语法。这不是 ffmpeg 的错，也不是脚本的错，纯粹是版本代差。
解决：把这套资源里的 ffmpeg 版本换成 4.x 系列，对旧 clang 的兼容性较好。另外一个通用技巧是给编译命令加上 --extra-cflags="-Wno-error=deprecated-declarations"，让警报告警但不中断编译进程。
4.4 生成的 .a 架构不全，lipo -info 查到只有两种架构
现象：lipo_merge 后，用 lipo -info libavcodec.a 查看，发现只有 arm64 和 i386，armv7 和 armv7s 不翼而飞。
原因：编译顺序里，armv7s 和 armv7 的 make 失败了，但脚本没有启用 set -e，后续架构继续编译并最终执行 lipo，lipo -create 不会报错，只会默默吞掉缺失的架构，产出一个看起来没问题的“半桶水”库。
解决：脚本顶部加 set -e，让任意架构失败时立即终止。同时在 lipo_merge 前增加校验逻辑，调用 lipo -info $ARCH/lib/libavcodec.a 逐个确认文件存在且架构正确，我一般在 merge 函数里用 if [ -f ] 做四个文件的存在性检查，少一个就直接退出。
4.5 反复切换 Debug/Release 后架构串台
现象：模拟器跑得好好的，切到真机 Debug 编译，报错说 x86_64 架构重复，或者说某个 .a 文件不是当前架构的二进制。
原因：Xcode 的 DerivedData 缓存了旧架构的静态库。脚本输出的 universal 目录里，四个架构合并后的 .a 是真机和模拟器杂合的，如果 Xcode 配置的是 “Build Active Architecture Only”，它可能不挑架构直接拿缓存文件去链接。
解决：Xcode 工程里把 Architectures 设置为 Standard，并把 “Build Active Architecture Only” 在 Release 配置下关闭。更血泪的经验是，每次切换运行设备前，先删掉工程目录下 build 和 DerivedData 里的旧产物，再重新编译链接。宁可多等一次全量编译，也不要被串台架构折磨一上午。
5. 集成与验证：把 ffmpeg 静态库接进 Xcode，并顺手解决一个遗留问题
5.1 头文件与 .a 文件的工程组织方式
脚本生成的每个架构目录下都有 include 和 lib 两套内容，Xcode 工程里不推荐把四个架构分别拖进去，而是只引用 universal 目录下的合并 .a 和一份公共头文件集。我的组织方式是把 include 整个拖进工程目录，与 ffmpeg-ios/universal 并列，编译时在 Build Settings 里给 Header Search Paths 和 Library Search Paths 分别指向这两个目录。静态库在 Link Binary With Libraries 里只添加一个 libavcodec.a 时，记得把其他几个 .a 也一并添加，否则链接器会报 avformat 等符号缺失，这是新手最常忽略的细节。
5.2 lipo -info 验证、运行期架构检查
合并完成后，验证是必不可少的一步。在终端里执行：
lipo -info ffmpeg-ios/universal/libavcodec.a输出应该是 “Architectures in the fat file: … are: armv7 armv7s arm64 i386”。如果缺架构，回到第四章排查。运行期验证更直接：在模拟器里执行一段解码代码，打印 avcodec_configuration 或调用 av_version_info，如果崩溃在 vfp 指令附近，基本可以判断 static library 的编译参数出了问题。对于老工程的音视频模块，我最常跑的验证是解码一段 1080p H.264 文件并输出视频帧率统计，确认没有崩溃且帧率符合预期。
5.3 进阶：按需裁剪出 arm64 + x86_64 精简变体
Apple Silicon 普及后，这份脚本的模拟器架构需求从 i386 变成了 x86_64。保留老架构的兼容没问题，但新工程可以省掉 armv7 和 armv7s，只编 arm64 与 x86_64 两个架构。同时还可以配合一些暗坑经验进行处理，比如老 ffmpeg 版本在 Apple Silicon Mac 上编译时，可能需要禁用某些汇编优化，或者手动指定 --cpu=arm64，否则 x86_64 模拟器产物容易产生 SIGILL。这个精简变体适合新起步的项目，而完整四架构版本适合既要跑老设备、又要兼容老 Mac 模拟器的维护型工程。
最后说一个我自己的习惯：每次拿到这种编译脚本资源，我不会直接跑一遍就扔，而是先看它的 ARCHS 循环和 configure 参数，把版本号、库路径这些环境相关项提取成脚本开头的变量区，确认在干净机器上能复现后，才把生成的 .a 放进工程。同时我会把用完的脚本和修复记录拼成一个补丁文件，放在工程目录的 build_tools 下，方便团队其他人重建环境时对照。照着这样一套流程走下来，从那以后我每次做 iOS 上的 ffmpeg 集成，都强制先跑一遍 lipo -info 确认架构，再进链接阶段，这个习惯帮我少加了很多冤枉班。把这套资源按上述步骤拆一遍，相信你也能一次拿到四架构全量的静态库，希望帮到你。
本文还有配套的精品资源，点击获取
