1. 从一个播放器说起ijkplayer到底解决了什么问题做移动端开发这些年只要碰过视频播放需求几乎绕不开一个名字ijkplayer。它是由哔哩哔哩开源的一套基于 FFmpeg 的跨平台播放器框架支持 Android 和 iOS核心代码挂在 GitHub 上社区活跃度一直很高。今天想聊的不是官方 README 里那几行介绍而是把 ijkplayer 相关的实用链接、全量编译思路、集成方式和踩坑记录整理成一篇能直接照着做的文章让刚入手的新朋友少走弯路也让已经在用的人能解决一些长期困扰的细节问题。ijkplayer 解决的痛点说白了就是移动端做视频播放远比想象中复杂。Android 自带的 MediaPlayer 和 iOS 的 AVPlayer 虽然能播一些格式但遇到 RTSP、RTMP、HLS、FLV 这类流媒体协议或者 MKV、TS、MOV 这些封装格式原生播放器常常束手无策。FFmpeg 功能确实全面但它是纯 C 项目编译配置复杂API 设计面向桌面和服务器场景直接拿到手机上用非常痛苦。ijkplayer 相当于在 FFmpeg 外边包了一层漂亮的移动端壳把硬件解码、音画同步、网络协议等底层细节全部封装好对外提供 Java/Kotlin 和 Objective-C 接口开发者调用起来就像用系统播放器一样简单。我最初接触 ijkplayer 是在做一款直播类 App 的推流直播模块当时需要播放 RTMP 和 HTTP-FLV 流同时对延迟要求很高。系统播放器根本不支持这些协议自己拿 FFmpeg 命令行工具做试验可行但要想稳定集成进 App 并处理好生命周期、硬解切换、缓冲策略工作量巨大。最终选择了 ijkplayer这算是当时最合理的路径也是绝大多数团队的实际选择。今天这篇就以它为例把“实用链接”背后真正该掌握的知识讲透。2. 实用链接整理哪些资源值得真正收藏标题既然叫“ijkplayer相关实用链接”那咱们就先亮家底。我按信息获取、编译产物、社区参考三个维度把资源分类列一下每个链接我都会说明它的作用和适用场景避免收藏了一堆却不知道怎么用。资源地址/位置用途说明官方 GitHub 仓库github.com/bilibili/ijkplayer源码、编译脚本、README、issue 区一切内容的主入口官方 Wikigithub.com/bilibili/ijkplayer/wikiAndroid/iOS 编译流程、模块定制说明、官方 FAQ官方示例工程仓库内 android/ 和 ios/ 目录包含完整 Demo适合对照集成FFmpeg 官方文档ffmpeg.org/documentation.html了解协议、滤镜、编解码器参数帮助判断裁剪范围和参数调优B 站开源团队主页相关组织页面了解项目背景、团队维护的其他音视频组件码云/CSDN 镜像搜索 ijkplayer 镜像仓库国内访问时加速 git clone注意核对 commit 一致性预编译 AAR 分发站搜索 ijkplayer aar 全量包直接用于集成但要确认 arm64-v8a 支持和 FFmpeg 版本把这些链接收藏只是第一步更重要的是理解仓库的目录结构。ijkplayer 主目录下有几个关键部分ijkplayer-java 是 Android 的 Java 封装层提供 IjkMediaPlayer 类ijkplayer-arm64、ijkplayer-armv7a 等目录放对应架构的 so 库和构建配置media 目录是核心中的核心里面包含 FFmpeg 编译脚本、openssl 编译脚本以及各种 patch 文件。iOS 端则在 ios 目录下通过 IJKMediaFramework 集成。官方 Wiki 里的“编译”相关页面一定要读尤其是 Android 编译环境要求那一节。官方对 NDK 版本有严格要求这一点我后边会专门说。很多人收藏了无数链接最终编译一遍全量包还是报错基本都是环境问题和脚本执行顺序问题而不是链接不对。还有一个很多人不知道的点ijkplayer 建议配合“预编译 so 自定义 FFmpeg 模块”这套思路来用。也就是说不要每次集成都从零编译一份全量库那样太耗时太痛苦。官方仓库的 Releases 页面虽然不直接提供所有 AAR但通过 gradle 依赖方式可以引用官方发布的版本比如“tv.danmaku.ijk.media:ijkplayer-java”系列。我自己在多个项目里都是先拿官方预编译包跑通功能等业务稳定后再单独编译定制库这个顺序最省时间。3. 链接背后的关键动作全量编译与模块裁剪3.1 什么是“全量”构建什么情况下你需要它关于 ijkplayer 的热搜词里经常出现“全量”二字圈内习惯说“全量包”。它指的是在编译 FFmpeg 时使用默认的 module.sh 配置不裁剪任何地方将所有支持的编解码器、协议、封装格式、音频重采样等功能全部编译进 so 库。与之相对的是“lite”版通过 module-lite.sh 裁剪掉大量不常用的功能只保留最基础的播放能力。全量包体积确实大每个架构的 so 可能达到几十 MB三个架构加起来会显著拉高 APK 体积。但在某些场景下全量是最省心的选择。比如播放源格式不可控可能是 MP4、FLV、MKV、TS也可能是 RTSP、RTMP、HLS 流客户随时可能会换封装格式需要处理特殊音频编码如 AC3、DTS 音轨lite 版通常不支持但全量版可直接解析需要做本地视频文件播放器覆盖用户从各种渠道获取的文件格式五花八门做直播场景RTMP、HTTP-FLV、HLS 协议并存且要兼顾回看、录播等形态。当然如果业务场景极其固定比如只播自家服务的 MP4 文件那完全没必要背全量包的体积负担裁剪一份精简的 so 库能轻松把播放器内核压到 10MB 以内。3.2 Android 全量编译实操流程先说说环境。我建议使用 Ubuntu 18.04 或 20.04 作为编译系统Android SDK 和 NDK 版本要配合官方要求。ijkplayer 官方默认使用的 NDK 是 r10e这个比较老但很多人在新 NDK 上编译会报 “unable to locatex86_64/libgcc.a” 或者各种链接失败的问题。如果你的项目本身对 NDK 版本没有硬性要求直接装一个独立的 NDK r10e 是最省事的。如果必须用新版 NDK需要修改 ijkplayer 的编译脚本调整 API level 和工具链路径操作起来比较烦琐。完整全量编译流程如下# 1. 克隆官方仓库 git clone https://github.com/bilibili/ijkplayer.git cd ijkplayer # 2. 拉取 FFmpeg、openssl 等依赖源码 ./init-android.sh # 3. 进入 Android 目录设置架构和 SDK 路径 cd android export ANDROID_SDK_ROOT/path/to/your/sdk export ANDROID_NDK_ROOT/path/to/your/ndk/r10e # 4. 确认使用全量配置默认为 module.sh无需修改 # 如果想用精简配置执行 # cp module-lite.sh module.sh # 5. 编译 FFmpeg cd ../media ./compile-ffmpeg.sh all # 如果要指定架构可用 arm64-v8a 等参数具体看脚本提示 ./compile-openssl.sh all # 如果不需要 https 或某些加密协议可跳过 # 6. 编译各架构 so 库 cd ../android ./compile-ijk.sh all这里有个细节容易误导新手./compile-ffmpeg.sh all中的参数 all 不是“全量模块”的意思而是编译所有 CPU 架构armv7a、arm64、x86 等。模块全量裁剪与否由 module.sh 文件控制。所以网上有人问“为什么我执行了 all 还是不包含某个解码器”答案很简单你没看 module.sh 里是否加上了对应的 enable-demuxer 或 enable-decoderall 只是架构维度的全量不是功能维度的全量。编译完成后产物集中在android/ijkplayer/ijkplayer-arm64/src/main/libs/目录下核心是三个 so 文件libijkffmpeg.soFFmpeg 核心、libijkplayer.so播放器引擎、libijksdl.soSDL 抽象层。Java 层代码通过 JNI 调用这些动态库。你可以直接用 gradle 将好几个 ijkplayer-xxx 模块打包成 AAR 放进你自己的工程也可以只把 so 文件和 Java 源码拷贝过去用后者更自由但需要自己维护资源。这里也说说我在实际项目中发现的关于“全量”的一些偏颇认知。全量包并不是只能靠官方默认 module.sh 一条路走。你可以在 module.sh 里尽情追加需要的组件也可以故意 disable 某些你完全不用的组件来达到自定义全量的效果。比如我们项目要支持 WebM 播放就需要在 module.sh 里增加enable-demuxer matroska、enable-decoder vp8、enable-decoder vp9但可以保留官方全量配置里其他用不到的组件不动。这样既保证功能覆盖又不需要花时间做减法。3.3 iOS 端编译要点与差异iOS 端编译的整体思路和 Android 一致核心脚本同样是 init-ios.sh、compile-ffmpeg.sh、compile-ijk.sh。但有几个平台特有的坑需要单独说。首先是依赖工具。编译 iOS 版 FFmpeg 需要 yasm低版本 FFmpeg 对 nasm 的兼容性比较差建议按官方 wiki 的说明安装 yasm。其次是架构官方脚本默认支持 armv7、arm64 和 x86_64 模拟器架构但在新版本 Xcode 上x86_64 模拟器产物可能无法被真机工程引用。如果你只打包 arm64 真机版本可以直接在执行 compile-ffmpeg.sh 只传入 arm64。我自己常用的构建组合是 arm64这样既能减小编译时间又能满足当前绝大多数真机设备需求。iOS 全量编译完成后产出的是 IJKMediaFramework 这个 framework 包。集成方式有两种直接拖进 Xcode 工程或者用 CocoaPods 引用源码配置。用后者的话管理依赖方便一些但需要注意把脚本编译出来的 framework 路径配置正确不然编译链接阶段会报找不到模块。还要特别提醒的是iOS 端全量包在部分场景下启动速度会比较吃力因为动态库加载和初始化 FFmpeg 组件的耗时比 Android 端更明显。如果 App 冷启动就要播放视频建议做成异步初始化播放器避免主线程卡顿导致用户看到白屏或者掉帧。4. 集成使用从编译产物到可播放的 Demo拿到编译好的 so 库或 framework 之后下一步就是和业务代码打通。这部分我把 Android 和 iOS 分开讲同时说清楚播放器核心 API 和几个参数的作用。4.1 Android 端最小集成步骤Android 端先用 Android Studio 新建一个空白工程把编译好的模块拷贝到工程里。最优雅的方式是直接新建一个 library module将 ijkplayer-java 源码和 so 文件导入再让 app 依赖这个 module。接下来就是调用代码层面的工作// 初始化播放器 val player IjkMediaPlayer() // 设置播放源 player.setDataSource(rtmp://your.stream.url/live/stream) // 如果需要硬解码提前设置 Option player.setOption(IjkMediaPlayer.OPT_CATEGORY_PLAYER, mediacodec, 1) player.setOption(IjkMediaPlayer.OPT_CATEGORY_PLAYER, mediacodec-auto-rotate, 1) player.setOption(IjkMediaPlayer.OPT_CATEGORY_PLAYER, opensles, 0) // 绑定显示层 val textureView TextureView(this) player.setDisplay(textureView.holder) // 准备并播放 player.prepareAsync() player.setOnPreparedListener { it.start() }代码本身没什么难度但有几个细节会明显影响体验。第一显示层优先用 TextureView 而不是 SurfaceView因为 SurfaceView 在大屏弹窗、动画切换时容易出现黑屏闪烁问题TextureView 虽然性能理论上略低但对大部分播放场景完全够用而且兼容性更好。第二网络流播放务必用 prepareAsync 异步准备不能用 prepare 同步方法否则网络慢时主线程直接卡死。第三释放资源时要在 onPause 和 onDestroy 中分别处理尤其是直播流不释放的话底层网络连接不会立刻断掉。4.2 iOS 端集成要点iOS 端的核心类是 IJKFFMoviePlayerController。初始化流程大概是IJKFFOptions *options [IJKFFOptions optionsByDefault]; [options setPlayerOptionValue:1 forKey:mediacodec]; // 对硬解无效iOS 侧用 videotoolbox [options setPlayerOptionIntValue:1 forKey:videotoolbox]; IJKFFMoviePlayerController *player [[IJKFFMoviePlayerController alloc] initWithContentURL:url withOptions:options]; player.view.frame self.view.bounds; player.view.autoresizingMask UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight; [self.view addSubview:player.view]; [player prepareToPlay]; [player play];这里可以提一个 iOS 特有的点视频渲染视图底层是基于 OpenGL ES 或 Metal 的。如果 App 同时使用了其他 OpenGL 渲染组件有可能出现图层冲突。官方 Wiki 里有相关说明。实际项目中如果遇到画面出不来的情况可以尝试调整 player.view 的 frame 重新布局或者在多线程场景里加锁控制。4.3 硬解码与软解码的取舍逻辑ijkplayer 在 Android 端通过 MediaCodec 支持硬解码在 iOS 端通过 VideoToolbox 支持硬解。硬解能显著降低 CPU 占用对发热和耗电友好但兼容性上偶尔会有问题。比如部分机型在播放某些 H.265 视频时会出现绿屏、花屏或者画面旋转方向错误这就是硬解码器和编码参数不完全兼容的表现。我的经验是不能单纯地“全硬解”或“全软解”而要做降级策略。iJKplayer 本身支持在初始化时指定硬解开关但业务层最好监控解码异常事件。具体做法是通过 setOnNativeInvokeListener 或者监听错误回调一旦发现硬解视频出现渲染异常自动清除当前 Option 并重启一个软解播放器实例。这种“硬解优先失败重试退软解”的模式我在几款电商和视频类 App 里都验证过能覆盖绝大多数兼容性问题。顺带说一个容易被忽略的参数opensles。Android 端使用 OpenSL ES 时音频延迟更低但部分设备会出现声音断续、爆音现象。如果你发现播放流畅但声音有问题可以尝试把opensles设为 0系统会自动走普通 AudioTrack 路径音质和稳定性反而更好。5. 全量编译时的体积与裁剪实战5.1 控制 so 体积的一般手段全量包体积极为感人这是很多团队犹豫是否使用 ijkplayer 的核心原因。实际上体积问题可以通过裁剪模块和合理配置架构解决到可接受范围。官方 module.sh 默认开启了大量编码器和协议但很多你根本用不到比如你只做播放不做录制那所有 encoder 都可以关掉比如你只播放 MP4 和 HLS那大部分 demuxer 也都可以关掉。裁剪的入口就是 module.sh 和 module-lite.sh。具体操作为# 编辑 module.sh cd ijkplayer/media vim module.sh # 针对不需要的编解码器进行 disable比如 # --disable-encoderh264 # --disable-decoderhevc # 或者完全使用从精简模板修改的方式 # cp module-lite.sh module.sh模块裁剪最麻烦的在于FFmpeg 组件之间存在依赖关系比如你保留了某个 demuxer它内部又依赖某个 parser如果裁剪不当会直接编译失败。建议每做一次裁剪就编译一次不要一次性删太多然后通过 FFmpeg 的 configure 日志去排查依赖缺失。编译失败时日志里会明确提示没有找到某个 component按提示逐步调整即可。5.2 架构选择与 ABI 过滤Android 端的 ABI 策略也很关键。当前主流应用基本只需要 arm64-v8a 一种架构多年前的 armeabi-v7a 设备已经越来越少。如果你还在为兼容老旧设备而保留 armeabi-v7a建议看一下自己 App 的崩溃后台很可能这类设备占比已经低于 1% 了。直接只编 arm64 架构的 so能让体积减少将近 40%同时还规避了一部分老旧设备上兼容性差的问题。至于 x86 和 x86_64官方为了让模拟器能运行播放器而保留了相关编译选项但是极少有线上应用需要它。如果只是做功能验证用 arm64 架构的模拟器镜像就好不需要把 x86 打进去。iOS 端同理目前只需要 arm64如果要做模拟器调试单独编译一份 x86_64 调试用即可Release 包不用包含。我做过的某个直播 SDK 项目最初默认全量全架构打包最终 APK 体积增量超过了 70MB客户直接拒绝集成。后来把架构收敛到 arm64再根据协议需求把编码器全部禁用、解码器只保留 H.264、H.265、AAC最终 APK 体积增量不到 25MB。这个优化过程没有魔法就是裁剪 架构收敛按部就班而已。5.3 module.sh 的经典配置模板我拿一套比较通用的 module.sh 配置作为示例覆盖常见点播和直播场景同时能在体积和功能之间取得平衡。需要说明的是FFmpeg 的版本对应配置项可能略有差异你以实际分支源码中的 valid 列表为准但思路是相通的。# 协议方面保留常用网络协议 --enable-protocolrtmp --enable-protocolhttp --enable-protocolhttps --enable-protocolhls --enable-protocolcrypto # 封装格式保留点播和直播常见容器 --enable-demuxermov --enable-demuxerflv --enable-demuxerhls --enable-demuxermpegts --enable-demuxermatroska # 解码器保留主流视频和音频 --enable-decoderh264 --enable-decoderhevc --enable-decoderaac --enable-decodermp3 --enable-decoderac3 # 编码器全部关闭播放器场景基本不需要 --disable-encoder* # 滤镜按需开启一般保留缩放和旋转即可 --enable-filterscale --enable-filterrotate这份配置不是官方固化的模板是我根据多年项目中总结的常用组合。你可以在此基础上按需追加。唯一要反复验证的是每一个 enable/disable 是否会破坏 FFmpeg 内部的依赖链务必在改完配置后完整编译跑一遍。6. 常见问题与排查技巧实录6.1 编译阶段的经典报错很多人全量编译的第一道坎就是 NDK 相关报错我见过最多的几条记录一下。错误一找不到libgcc.a。原因是新版 NDK 将 libgcc.a 替换为 libunwind.aijkplayer 官方脚本里写死了旧路径。解决办法要么用 NDK r10e要么修改 build scripts 里查找 libgcc.a 的逻辑改成新 NDK 对应的工具链路径。错误二openssl 编译失败。执行 init-android.sh 后会拉取 openssl 源码但不同网络环境下载可能不完整导致后续 configure 时提示版本不匹配。这个问题我建议直接检查 openssl 目录里是否有完整的openssl/ssl文件缺少的话重新执行 init 脚本或者手动删除目录重新下载。错误三执行 compile-ffmpeg.sh 时提示无权限或脚本格式错误。这在 Windows 上通过 WSL 操作时偶尔出现一般用dos2unix转换脚本格式即可。编译时间也是个硬伤。全量 FFmpeg 编译三个架构在高性能机器上也要二十分钟以上性能差的机器轻松超过一个小时。我有一次出差笔记本编译 arm64 单架构都花了近四十分钟。建议编译时关闭 Android Studio减少系统负载。如果只是调试侧链逻辑可以只编 arm64不编全架构。6.2 播放阶段的常见问题播放 RTSP 流时有音无画或有画无音这类问题多半是 FFmpeg 缺了对应解码器注意看播放器的日志会明确打印“could not find codec parameters”或类似提示。以 RTSP 的 H.265 流为例很多视频源站会调用 RTP over TCP 或 UDP 的方式传输默认协议是 UDP但某些网络环境会丢包严重导致花屏。解决方式是通过 Option 设置rtsp_transporttcp强制走 TCP 传输。另外IjkMediaPlayer 的日志等级默认是比较低的很多细节不会直接输出。调试时建议调用IjkMediaPlayer.native_setLogLevel(IjkMediaPlayer.IJK_LOG_DEBUG)或设置IJKFFOptions的 log level这样 FFmpeg 层的警告才会打到 logcat 或 Xcode 的控制台。排查播放问题时写清楚播放地址、播放器版本、是否硬解、完整日志这四项基本能定位 90% 的问题。播放直播流的延迟问题也很常见。ijkplayer 默认配置偏向稳定缓冲较大延迟可能到三五秒。如果要做低延迟直播需要主动调小缓存值。Android 端设置缓冲参数的核心代码大概是player.setOption(IjkMediaPlayer.OPT_CATEGORY_PLAYER, max-buffer-size, 1024) player.setOption(IjkMediaPlayer.OPT_CATEGORY_PLAYER, min-frames, 2) player.setOption(IjkMediaPlayer.OPT_CATEGORY_PLAYER, infbuf, 0)iOS 端在 IJKFFOptions 里也有对应的setPlayerOptionIntValue。但低延迟和播放稳定性是一对天然矛盾调小了容易卡顿调大了延迟升高。建议直播场景先把延迟调到 1 到 2 秒然后实测用户网络环境再微调 buffer 参数。6.3 全量包集成后的合规与稳定性问题集成全量包之后还需要考虑合规有关的事。ijkplayer 底层是 LGPL 协议的 FFmpeg如果你的 App 只是动态调用系统层面的 API没有静态链接并且你把播放器框架作为独立动态库使用通常不会触发开源协议连带义务。但如果你的项目依赖了 GPL 协议相关的 FFmpeg 组件比如某些滤镜库并且修改了 FFmpeg 源码却没有按要求开源就会带来较大的合规风险。具体到你自己的发布场景建议和法务或开源合规团队确认正规公司一般都会要求 lint 一下许可证信息。稳定性方面ijkplayer 的历史版本里也有多个已知 bug比如某些 Android 版本上 prepareAsync 偶发不回调、硬解切换时出现 ANR、频繁快速销毁重建播放器导致 native 层崩溃等。这些都是真实现象。遇到这类问题首先检查你用的 ijkplayer 版本是否过于陈旧然后看官方 issue 区是否有人提交相同的崩溃栈。很多时候崩溃根本原因在原生系统或视频源本身不一定在播放器内核对播放器的 API 兼容性。7. 内容之外关于 ijkplayer 的长期维护思路一个现实问题是ijkplayer 的官方维护节奏并不快新版本 FFmpeg 支持经常滞后于社区预期。做长期项目的团队如果对播放内核有很高要求会让 ijkplayer 停留在某个自认为稳定的版本然后在此基础上自行维护补丁。这不代表它不值得用了而是说你要以对待基础设施的心态来对待播放器组件不要期待隔三差五更新带来惊喜。用 ijkplayer 这些年我最深的体会是它的“实用链接”再多也不如自己把编译流程和模块配置吃透。每当你觉得某个问题在官方文档里找不到答案时多翻一下 FFmpeg 的 configure 输出、阅读一下 module.sh 里每一项的含义你会对自己播放器的掌控力提升一个台阶。真正的护城河不是收藏了多全的链接而是遇到怪问题时能快速定位到是 FFmpeg 的哪个组件、哪个参数、哪一行脚本在搞事情。只要你绕过了全量编译心魔学会了模块裁剪理解了硬解软解降级那 ijkplayer 就只是你的起点而非终点后续无论换成自研播放器还是引入其他内核你都会从容得多。