簡介面向 iOS 平臺音視頻開發(fā)者的自動編譯腳本資源解決手動下載 ffmpeg、x264、fdk-aac、lame 源碼并逐一配置交叉編譯環(huán)境所帶來的流程繁瑣、版本匹配易錯等問題。尤其適合需要為 iOS 應(yīng)用集成自定義音視頻編解碼能力、希望快速生成靜態(tài)庫的開發(fā)者使用。壓縮包共 4 個文件全部為 shell 腳本整體大小僅 8KB輕量且便于查看和改動各腳本分工明確分別處理對應(yīng)開源庫的下載、參數(shù)配置與編譯在主腳本統(tǒng)一調(diào)度下可一鍵執(zhí)行完整流程最終產(chǎn)出 fdk-aac-ios、lame-ios、x264-ios、FFmpeg-iOS 等可直接鏈接進(jìn)工程的靜態(tài)庫目錄。目前已有 344 人學(xué)習(xí)下載。該腳本不僅給出了可直接運行的編譯方案還展示了 iOS 平臺交叉編譯中常見的架構(gòu)選擇、參數(shù)傳遞、模塊裁剪等關(guān)鍵細(xì)節(jié)復(fù)用價值較高后續(xù)需要擴(kuò)展其他音視頻組件時也可參考其中的組織與排錯思路。1. 先說清楚這個標(biāo)題在解決什么問題開 iOS 音視頻方向的開發(fā)者十有八九會卡在同一個地方工程里缺一個能用的 FFmpeg。源碼下載容易但在 iOS 平臺把它編成 .a 靜態(tài)庫還得帶上 x264、fdk-aac、lame 三個外圍庫手動敲 configure 和 make快則半天慢則兩三天。標(biāo)題里這個「一鍵自動下載并編譯腳本.sh」干的就是把下載源碼、配置交叉編譯環(huán)境、按依賴順序編四個庫、最后合并多架構(gòu)靜態(tài)庫這幾步串成一個腳本省掉人肉敲命令的重復(fù)勞動。這類腳本真正解決的不是「能不能編譯成功」而是「換臺機(jī)器、換個 Xcode 版本之后還能不能穩(wěn)定復(fù)現(xiàn)」。我見過太多人第一次手動編譯僥幸成功第二次在新環(huán)境里直接翻車。適用人群很明確做播放器、做音視頻剪輯、做直播前處理的 iOS 開發(fā)。如果你只想要編譯好的庫第 3、4 章的腳本結(jié)構(gòu)能直接抄如果你正被各種編譯報錯折磨第 5 章每一條都是真實的踩坑記錄。2. iOS 交叉編譯的原理先弄清楚腳本每一步在干什么2.1 iOS 交叉編譯和 Linux 本地編譯差在哪FFmpeg 在 macOS 或 Linux 上很好編一個./configure make就完事。但在 iOS 上事情變復(fù)雜的原因有三個iOS SDK 里只有 clang 工具鏈沒有 GNU gcc系統(tǒng)庫被封裝成 framework第三方庫只能編靜態(tài)庫由 Xcode 鏈接arm64 架構(gòu)的匯編代碼需要 gas-preprocessor 做預(yù)處理。這三個差異決定了一鍵腳本里必須顯式指定CC、SDK_PATH、ARCH全套環(huán)境變量。腳本開頭的環(huán)境變量導(dǎo)出是所有后續(xù)編譯命令的地基。我這邊常用的寫法是export MIN_IOS_VERSION10.0 export SDK_NAMEiphoneos # 真機(jī)模擬器請換成 iphonesimulator export SDK_PATH$(xcrun --sdk $SDK_NAME --show-sdk-path) export CC$(xcode-select -p)/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang export CFLAGS-arch $ARCH -isysroot $SDK_PATH -mios-version-min$MIN_IOS_VERSION export LDFLAGS-arch $ARCH -isysroot $SDK_PATH -mios-version-min$MIN_IOS_VERSION export HOST_TRIPLE$ARCH-apple-darwinSDK_PATH指向當(dāng)前 Xcode 對應(yīng)的 SDK 根目錄clang 靠-isysroot才能找到 UIKit、CoreMedia 這些 iOS 系統(tǒng)頭文件和 framework。-mios-version-min決定這個庫最低能跑在哪個系統(tǒng)版本上低于這個版本的手機(jī)會在啟動時直接 dyld 報錯。CFLAGS里必須帶-arch否則 clang 默認(rèn)編出的是 macOS 的 x86_64 產(chǎn)物。這個環(huán)境塊在腳本里通常會包成一個函數(shù)每切換一個架構(gòu)就重新導(dǎo)出一次。2.2 依賴順序為什么 FFmpeg 必須最后一個編四個庫之間的依賴關(guān)系是單向的x264、fdk-aac、lame 各自只依賴系統(tǒng)庫互不依賴而 FFmpeg 需要通過 pkg-config 探測前三個庫的頭文件和pc文件把它們編譯進(jìn) avcodec。所以順序上只需要保證一點FFmpeg 一定是最后一個。實際操作里大家習(xí)慣把 lame 放在第一個。原因不是它最基礎(chǔ)而是它的 configure 腳本在 iOS 交叉編譯場景下最容易出幺蛾子先編它能盡早暴露環(huán)境問題。x264 和 fdk-aac 的 configure 相對老實放中間編比較省心。三個前置庫都要裝到同一個PREFIX目錄里這樣 FFmpeg configure 只需要把PKG_CONFIG_PATH指向那一個目錄就能同時找到三個庫。這個統(tǒng)一前綴的做法省掉了很多路徑拼接的麻煩。2.3 靜態(tài)庫與架構(gòu)arm64、armv7、x86_64 具體怎么選iOS 從 11 開始就只支持 64 位設(shè)備了armv7 已經(jīng)是歷史包袱。當(dāng)前最穩(wěn)妥的組合是真機(jī)架構(gòu)只編 arm64模擬器架構(gòu)編 x86_64如果團(tuán)隊里有 Apple Silicon 芯片的 Mac模擬器還要額外編一份 arm64 的模擬器切片。三份切片生成后用 lipo 合并成一個 fat 靜態(tài)庫。腳本里對應(yīng)的循環(huán)結(jié)構(gòu)一般長這樣ARCHS(arm64) # 真機(jī) if [ $BUILD_FOR_SIMULATOR 1 ]; then ARCHS(x86_64 arm64) # 模擬器x86_64 兜底舊 Mac fi for ARCH in ${ARCHS[]}; do export CFLAGS-arch $ARCH -isysroot $SDK_PATH -mios-version-min$MIN_IOS_VERSION export LDFLAGS-arch $ARCH -isysroot $SDK_PATH -mios-version-min$MIN_IOS_VERSION export PREFIX_DIR$BASE_DIR/build/$ARCH mkdir -p $PREFIX_DIR build_lame build_x264 build_fdk_aac build_ffmpeg done注意這里每個架構(gòu)有獨立的PREFIX_DIR這是有意為之。不同架構(gòu)的產(chǎn)物混在同一個目錄里FFmpeg configure 會挑到第一個匹配的.a文件編出來的庫架構(gòu)是錯的而且極難排查。每架構(gòu)獨立目錄最后再合并是這類腳本必須遵守的紀(jì)律。3. 腳本開頭必做的三件事環(huán)境檢查、下載源碼、固定版本3.1 gas-preprocessor 與 pkg-config兩個最容易缺的東西FFmpeg 和 x264 源碼里有大量為 arm64 優(yōu)化的匯編iOS 交叉編譯時這些.S文件需要先經(jīng)過 gas-preprocessor 做宏處理再交給 clang 內(nèi)置的匯編器。沒裝它的話編譯到匯編環(huán)節(jié)必報Unable to find gas-preprocessor.pl。最穩(wěn)的安裝方式是從 FFmpeg 源碼樹里直接拷貝版本永遠(yuǎn)和源碼匹配# 先把 ffmpeg 源碼下載到 SRC_DIR再執(zhí)行這步 cp $SRC_DIR/ffmpeg-$FFMPEG_VERSION/tools/gas-preprocessor.pl /usr/local/bin/ chmod x /usr/local/bin/gas-preprocessor.plpkg-config 則是給 FFmpeg configure 用的。它負(fù)責(zé)回答「libx264 裝在哪個目錄、編譯需要什么 flag」這類問題。macOS 上自帶的 pkg-config 版本很舊容易漏掉.pc文件我一般會裝一個新版if ! command -v pkg-config /dev/null 21; then echo 缺少 pkg-config先執(zhí)行: brew install pkg-config exit 1 fi pkg-config --version腳本執(zhí)行到這里應(yīng)該停下來檢查一次而不是等到 FFmpeg configure 階段才報ERROR: libx264 not found。提前暴露環(huán)境問題能省下后面排查的半小時。3.2 源碼下載與版本固定不要每天拉最新 master一鍵腳本里最容易埋雷的是「下載最新代碼」。FFmpeg 官方倉庫每天都有新 commitx264 的 master 也在持續(xù)變動今天能編過的組合下周可能因為一個匯編改動直接編譯失敗。所以腳本里一定要固定版本號并且把版本號集中寫在最頂部方便以后統(tǒng)一升級FFMPEG_VERSION4.4 # 以 4.4 分支為例按需固定 X264_VERSIONstable # x264 官方分支名 FDK_AAC_VERSION2.0.2 LAME_VERSION3.100 SOURCE_DIR$BASE_DIR/src PREFIX_BASE$BASE_DIR/build下載函數(shù)我一般這樣寫先檢查本地是否已經(jīng)解壓過沒有才去拉包避免重復(fù)下載。fetch_tarball() { local NAME$1 local URL$2 if [ ! -d $SOURCE_DIR/$NAME ]; then cd $SOURCE_DIR || exit 1 curl -L $URL -o $NAME.tar.gz tar -zxf $NAME.tar.gz fi } fetch_tarball x264-$X264_VERSION $X264_MIRROR_URL fetch_tarball lame-$LAME_VERSION $LAME_MIRROR_URL下載地址建議用你所在網(wǎng)絡(luò)環(huán)境訪問最快的鏡像國內(nèi)團(tuán)隊一般會在內(nèi)網(wǎng)架一個源碼鏡像。腳本里留出變量而不是寫死 URL一方面是方便換源另一方面也是避免把第三方倉庫地址寫進(jìn)團(tuán)隊公共腳本里造成安全隱患。curl下載后建議順手用sha256sum校驗一下包完整性這一步能過濾掉大多數(shù)網(wǎng)絡(luò)傳輸損壞的問題。3.3 統(tǒng)一架構(gòu)循環(huán)與輸出目錄規(guī)劃下載完源碼后腳本會按 2.3 節(jié)的架構(gòu)列表做循環(huán)編譯。這里有一個很容易被忽略的細(xì)節(jié)四個庫在兩個架構(gòu)之間切換時必須使用完全獨立的編譯目錄。x264 和 lame 在重新 configure 之后如果不清除舊的.o文件鏈接階段就會混入上一架構(gòu)的產(chǎn)物報出Undefined symbols for architecture x86_64這種讓人摸不著頭腦的錯誤。我建議源碼目錄共用一份但編譯安裝目錄按架構(gòu)隔離每次進(jìn)入某個庫的源碼目錄前先執(zhí)行一次make distclean。腳本里的目錄規(guī)劃通常是BASE_DIR$(cd $(dirname $0) pwd) SOURCE_DIR$BASE_DIR/src PREFIX_BASE$BASE_DIR/build # build/arm64、build/x86_64、build/universal 三層結(jié)構(gòu)最終build/universal/lib放 lipo 合并后的結(jié)果build/universal/include放頭文件。Xcode 集成時只需要引用這一個目錄不需要關(guān)心內(nèi)部有多少個架構(gòu)切片。4. 核心編譯流程四個庫逐個 configure 的完整參數(shù)4.1 編譯 x264靜態(tài)庫 禁用 CLI性能與穩(wěn)定性之間留個開關(guān)x264 的 configure 參數(shù)相對簡單重點是把--prefix指向當(dāng)前架構(gòu)的安裝目錄并關(guān)閉命令行工具。命令行工具會依賴pthread等一堆東西在 iOS 上不需要build_x264() { cd $SOURCE_DIR/x264-$X264_VERSION || exit 1 make distclean /dev/null 21 # 上次編譯的殘留產(chǎn)物必須清掉 ./configure \ --prefix$PREFIX_DIR \ --host$HOST_TRIPLE \ --cross-prefix$CC $CFLAGS \ --extra-cflags$CFLAGS \ --extra-ldflags$LDFLAGS \ --enable-static \ --disable-shared \ --disable-cli \ --disable-opencl \ --disable-asm make -j${JOB_COUNT} make install }--cross-prefix這里直接復(fù)用了CC和CFLAGS這是 x264 configure 比較特殊的地方它不像 FFmpeg 那樣單獨讀--cc參數(shù)。--disable-asm值得單獨說arm64 的匯編優(yōu)化能帶來明顯編碼性能提升但需要 gas-preprocessor 正確工作。如果你的編譯機(jī)是某公司配發(fā)的安全加固系統(tǒng)perl環(huán)境被限制過gas-preprocessor 可能跑不起來這時候別死磕--disable-asm是保底方案。腳本里我一般把這個參數(shù)做成變量X264_ASSEMBLY默認(rèn)開啟失敗時手動改為--disable-asm。4.2 編譯 fdk-aacmacOS 的 libtool 坑和 autogen 前置fdk-aac 是純 C 代碼configure 本身不復(fù)雜但它有兩個前置問題。第一如果拉的是 git 源碼而不是 release 包目錄里沒有 configure必須先執(zhí)行./autogen.sh這要求機(jī)器裝了 automake 和 autoconf。第二macOS 的/usr/bin/libtool是 Apple 自己的實現(xiàn)不是 GNU libtoolfdk-aac 的構(gòu)建系統(tǒng)會用到 GNU libtool 的參數(shù)直接用 Apple 版 libtool 會在鏈接時出現(xiàn)詭異行為。build_fdk_aac() { cd $SOURCE_DIR/fdk-aac-$FDK_AAC_VERSION || exit 1 # git clone 的源碼要先跑 autogen.shrelease 包不用 [ ! -f configure ] ./autogen.sh # macOS 安裝 GNU libtool 后二進(jìn)制名被重命名為 glibtool LIBTOOL$(command -v glibtool) if [ -z $LIBTOOL ]; then echo 缺少 glibtool執(zhí)行: brew install libtool exit 1 fi export CC$CC $CFLAGS ./configure \ --prefix$PREFIX_DIR \ --host$HOST_TRIPLE \ --with-pic \ --disable-shared \ --enable-static \ LIBTOOL$LIBTOOL make -j${JOB_COUNT} make install }注意這里export CC$CC $CFLAGS是個土辦法。fdk-aac 的 configure 會把 CC 當(dāng)作一條完整的編譯命令執(zhí)行如果我們只給 clang 路徑它不會自己去讀CFLAGS。把架構(gòu)參數(shù)拼進(jìn) CC 是社區(qū)里最常見的繞行方案丑但有效。--with-pic是給靜態(tài)庫加位置無關(guān)代碼后續(xù)鏈接進(jìn) App 時需要這個屬性。4.3 編譯 lameconfigure 最脆弱需要 --build 參數(shù)兜底lame 是這幾個庫里 configure 寫得最老的它默認(rèn)會嘗試運行剛編譯出來的測試程序來判斷編譯環(huán)境是否可用。交叉編譯時編譯出來的程序是 iOS 的跑在 macOS 上必然失敗configure 就直接判定「編譯器不可用」。解決辦法是顯式告訴 configure 兩個參數(shù)--build表示當(dāng)前這臺機(jī)器的環(huán)境--host表示目標(biāo)環(huán)境build_lame() { cd $SOURCE_DIR/lame-$LAME_VERSION || exit 1 make distclean /dev/null 21 ./configure \ --prefix$PREFIX_DIR \ --buildx86_64-apple-darwin \ --host$HOST_TRIPLE \ --disable-shared \ --enable-static \ --disable-frontend \ --disable-decoder \ --enable-nasm$([ $ARCH arm64 ] echo no || echo yes) make -j${JOB_COUNT} make install }--buildx86_64-apple-darwin是關(guān)鍵它告訴 configure「測試程序會在 x86_64 的 macOS 上被運行」configure 就不會報cannot run C compiled programs。--disable-frontend去掉lame命令行工具--disable-decoder只保留編碼器。lame 的 MP3 解碼器代碼里用了不少 x86 內(nèi)聯(lián)匯編arm64 下編解碼器是最大踩坑點直接禁用是最省心的處理方式。4.4 編譯 FFmpeg把前三個庫通過 pkg-config 串起來前置庫都裝進(jìn)$PREFIX_DIR之后FFmpeg 的 configure 就順暢多了。關(guān)鍵是把PKG_CONFIG_PATH指過去讓探測邏輯能找到三個庫的.pc文件build_ffmpeg() { cd $SOURCE_DIR/ffmpeg-$FFMPEG_VERSION || exit 1 make distclean /dev/null 21 export PKG_CONFIG_PATH$PREFIX_DIR/lib/pkgconfig ./configure \ --prefix$PREFIX_DIR \ --cc$CC \ --arch$ARCH \ --target-osdarwin \ --sysroot$SDK_PATH \ --enable-cross-compile \ --extra-cflags$CFLAGS \ --extra-ldflags$LDFLAGS \ --enable-static \ --disable-shared \ --disable-doc \ --disable-programs \ --disable-debug \ --enable-gpl \ --enable-nonfree \ --enable-libx264 \ --enable-libfdk-aac \ --enable-libmp3lame make -j${JOB_COUNT} make install }--enable-gpl和--enable-nonfree必須同時開因為 fdk-aac 的許可證和 GPL 不兼容FFmpeg 的 configure 遇到這個組合會強(qiáng)制要求--enable-nonfree否則直接報許可證沖突。--disable-programs很重要iOS 上我們只需要靜態(tài)庫不需要 ffmpeg 命令行可執(zhí)行文件編了反而會在鏈接階段帶上 main 符號和 App 沖突。--disable-debug能明顯縮小 .a 文件體積但要注意上線后想定位 FFmpeg 內(nèi)部的崩潰棧時沒有調(diào)試符號會非常痛苦。我一般會保留 debug等優(yōu)化體積時再關(guān)。4.5 lipo 合并產(chǎn)物生成最終的 universal 靜態(tài)庫所有架構(gòu)編譯完成后最后一個動作是合并。我習(xí)慣把 avcodec、avformat、avutil、swscale、swresample以及 x264、fdk-aac、lame 這八個庫各自做一次 lipoUNIVERSAL_DIR$BASE_DIR/build/universal mkdir -p $UNIVERSAL_DIR/lib for LIB in libavcodec.a libavformat.a libavutil.a libswscale.a libswresample.a libx264.a libfdk-aac.a libmp3lame.a; do FILES for ARCH in ${ARCHS[]}; do FILES$FILES $BASE_DIR/build/$ARCH/lib/$LIB done xcrun lipo -create $FILES -output $UNIVERSAL_DIR/lib/$LIB done cp -R $BASE_DIR/build/arm64/include $UNIVERSAL_DIR/提示頭文件隨便從哪個架構(gòu)目錄拷貝都可以頭文件不區(qū)分架構(gòu)但一定要保證版本和 .a 文件的源碼版本一致最忌諱的是頭文件用 FFmpeg 4.4庫卻編的是 4.2。很多一鍵腳本會再執(zhí)行一步「把八個庫用 libtool 合并成單個 libffmpeg.a」我不建議這么干。合并之后任何一個小庫的更新都要全量重打包而且 Xcode 的鏈接器在處理超大靜態(tài)庫時偶爾會有符號沖突問題。分開引用八個 .a維護(hù)成本低排查問題也更直接。5. 常見問題排查一鍵腳本最容易翻車的 5 個地方5.1 報錯 ERROR: libfdk_aac not found / libx264 not found現(xiàn)象FFmpeg configure 階段直接拒絕執(zhí)行明確說找不到某個前置庫。這個錯大概率不是「沒編譯成功」而是「編譯好了但探測不到」。原因基本只有兩個PKG_CONFIG_PATH沒設(shè)置或者設(shè)置指向了別的架構(gòu)的build目錄。很多腳本在循環(huán)里會重新設(shè)置PREFIX_DIR但忘了同步更新PKG_CONFIG_PATH結(jié)果 x86_64 循環(huán)里讀到了 arm64 的.pc文件。解決在build_ffmpeg函數(shù)內(nèi)部重新 exportPKG_CONFIG_PATH$PREFIX_DIR/lib/pkgconfig并在 configure 前用pkg-config --exists fdk-aac echo ok自檢一遍。5.2 arm64 匯編編譯失敗gas-preprocessor.pl 找不到或權(quán)限問題現(xiàn)象編譯 x264 或 FFmpeg 時報Unable to find gas-preprocessor.pl或者perl: command not found。原因gas-preprocessor 沒裝或者它的依賴 perl 不可用。某公司加固過的開發(fā)機(jī)上/usr/local/bin的寫入權(quán)限被鎖定腳本里cp命令靜默失敗后續(xù)編譯到匯編時直接崩。解決不要把它當(dāng)作「裝完就不管」的依賴每次腳本運行前檢查文件是否存在且可執(zhí)行如果perl被限制考慮用--disable-asm繞開匯編路徑x264 和 FFmpeg 都有這個開關(guān)性能略降但能保證編譯鏈路走通。5.3 模擬器鏈接報錯building for iOS-Simulator, but linking in object file built for iOS現(xiàn)象Xcode 工程里鏈接靜態(tài)庫時報building for iOS-Simulator, but linking in object file built for iOS或者could not be built for architecture arm64。原因真機(jī) SDK 編出來的 arm64 切片和模擬器 SDK 的 arm64 切片不是同一種 Mach-O 平臺標(biāo)識。Apple Silicon Mac 上跑模擬器也需要 arm64但這個 arm64 必須用iphonesimulatorSDK 來編。解決腳本里要支持兩套 SDK_NAME真機(jī)用iphoneos模擬器用iphonesimulator分別輸出到build/device-arm64和build/sim-arm64、build/sim-x86_64最后三合一。只做雙架構(gòu)arm64x86_64在 Intel Mac 上沒問題但在 Apple Silicon 上模擬器會優(yōu)先找 arm64 切片找不到才走 Rosetta這時候 x86_64 切片也能用但性能有損耗。5.4 bitcode 相關(guān)錯誤bitcode bundle could not be generated現(xiàn)象Xcode 鏈接時提示某個庫缺少 bitcode或者反過來提示輸入的-fembed-bitcode與目標(biāo)設(shè)置不一致。原因老的編譯教程普遍讓腳本加-fembed-bitcode但 Xcode 14 之后 bitcode 已經(jīng)被官方廢棄新工程默認(rèn)不開。四個庫里有一個開了 bitcode、三個沒開鏈接器就罷工。解決最省事的是腳本里完全不傳-fembed-bitcode同時把 Xcode 工程的ENABLE_BITCODE設(shè)為 NO。如果你的團(tuán)隊還有老設(shè)備上架需求就保持一致要么四個庫都開要么都關(guān)不要混。5.5 Undefined symbols for architecture x86_64但明明編過這個架構(gòu)現(xiàn)象鏈接階段報找不到某個符號比如dequant_lut這類 lame 內(nèi)部函數(shù)而 lipo 查看 .a 確實包含 x86_64 切片。原因這個坑多半是復(fù)用源碼目錄導(dǎo)致的。lame 的 configure 在換架構(gòu)后沒有清理干凈舊架構(gòu)的.o還留在目錄里make 時跳過了部分文件的重編。解決在build_lame、build_x264的 configure 前無條件執(zhí)行make distclean /dev/null 21并把PREFIX_DIR按架構(gòu)徹底分離開。執(zhí)行完這步問題一般就消失了。如果還報錯手動刪掉源碼目錄重新解壓避免依賴增量編譯的緩存。6. 驗證產(chǎn)物從 .a 文件到 Xcode 里真正跑起來靜態(tài)庫編完不能直接信第一步用 lipo 確認(rèn)每個庫的架構(gòu)列表xcrun lipo -info $BASE_DIR/build/universal/lib/libavcodec.a # 輸出應(yīng)包含 arm64 和模擬器需要的架構(gòu) xcrun lipo -info $BASE_DIR/build/universal/lib/libmp3lame.a第二步強(qiáng)烈建議寫一個最小測試程序驗證頭文件和庫真的配套。先在 Xcode 工程里跑通播放本地文件是最貼近真實場景的驗證。更輕量的做法是用模擬器編一個 20 行的 C 程序xcrun -sdk iphonesimulator clang -arch x86_64 \ test.c \ -I$BASE_DIR/build/universal/include \ -L$BASE_DIR/build/universal/lib \ -lavformat -lavcodec -lavutil -lswresample -lswscale \ -lx264 -lfdk-aac -lmp3lame \ -framework AudioToolbox -framework CoreMedia \ -framework VideoToolbox -framework Foundation \ -mios-simulator-version-min10.0 \ -o test_sim如果這個程序能編譯鏈接通過說明四個庫的符號表完整、頭文件版本匹配集成進(jìn) Xcode 只是時間問題。我在實際項目里習(xí)慣把這三個驗證步驟放進(jìn)腳本的verify子命令每次重編后自動執(zhí)行從源頭杜絕「編譯成功但鏈接翻車」的玄學(xué)問題。最后提醒一句能被忽略但早晚會來的一課x264 是 GPL 許可fdk-aac 是不允許商用分發(fā)的一類許可兩個庫同時編譯進(jìn)去的二進(jìn)制如果走公開渠道分發(fā)會有許可證風(fēng)險。我現(xiàn)在的習(xí)慣是工程里拿這套腳本做技術(shù)驗證和內(nèi)部預(yù)研正式產(chǎn)品若需要上架會把 x264 換掉或者對相關(guān)功能做動態(tài)裁剪。這個決策越早定越好不要等庫已經(jīng)深度集成再后悔。希望這篇筆記能讓你少走幾趟編譯的彎路。本文還有配套的精品資源點擊獲取