先把结论放前面ijkplayer 在 Win10 下编译不是能不能成功的问题而是你能不能闯过前十分钟的问题。几乎所有卡住的人都死在同一个点上——官方构建脚本默认你用的是 macOS 或 Linux偏偏你手里是 Windows。这篇东西写给两类人一类是刚接触播放器开发、想在自己机器上把源码拉通跑起来的另一类是看了一堆编译帖子结果换了好几个 NDK 版本仍然在报错里打转的。我会把环境配置、版本匹配、命令行流程以及我在 Windows 上实际撞过的坑从头到尾讲清楚尽量做到你跟着走一遍就能出包。我这边反复编译过很多次实际使用场景包括拿它做本地视频播放、接入直播流、以及帮别人排查编译环境问题。所以说到底这不是一个玄学问题而是环境不对、版本不齐、路径不规范三个老问题叠加的结果。下面不废话直接进正题。1. 为什么Windows用户总在ijkplayer编译这一步翻车1.1 官方构建脚本的“Unix视角”ijkplayer 这个开源播放器项目核心代码分成几块Java 层负责播放器接口JNI 层衔接 Java 和原生代码再往下是 FFmpeg、openssl 这些 C 库。构建整套东西的入口是一堆.sh脚本比如init-android.sh、compile-ffmpeg.sh、compile-ijkplayer.sh。脚本本身不复杂复杂的是它背后依赖的一整套 Unix 式工具链。官方 README 和 Wiki 里给出的构建步骤基本都是这样克隆源码切分支运行init-android.sh下载依赖接着编译。这套流程在 macOS 和 Linux 上是顺畅的因为系统自带 bash、make、yasm 以及标准工具链。但 Windows 不一样自带的 cmd 和 PowerShell 不会直接执行.sh文件系统里没有 Unix 那种符号链接权限模型默认又缺一堆编译依赖。所以很多人第一次在 Windows 上尝试还没走到编译那一步就卡在这个.sh文件到底怎么打开上。1.2 Windows下的三条路线WSL、Git Bash、Docker怎么选我实际试过的方案有三个各自优缺点很明显。路线上手难度踩坑概率适合场景WSLUbuntu环境低低本地开发主力最推荐Git Bash 手动装依赖中中高不想装 WSL机器配置一般Docker 容器编译中高中团队统一环境、CI 构建先说 WSL。装好 Ubuntu 子系统后apt直接安装 yasm、make、vim 等工具下载 NDK、SDK 后设置环境变量剩下的步骤和 Linux 上一模一样。我有段时间还在 Windows 上做日常开发编译这类带 C 库的项目就切到 WSL 终端执行成功率最高。它的一个额外好处是绕开了 Windows 上最头疼的符号链接权限问题因为脚本在 WSL 内运行时文件系统操作更接近原生 Linux。再说 Git Bash。Git for Windows 自带 bash 环境也能执行.sh脚本但缺 make 和 yasm还得自己补。我的经验是用这个方案也能编出 aar但你会额外处理两类问题——一类是脚本中创建符号链接时报权限错误另一类是路径中有中文、空格时各种诡异报错。如果你机器上同时装了多个 NDK 版本Git Bash 下的 PATH 也很容易写乱。最后是 Docker。它的好处是一次配好到处编译。我把编译工具链、NDK 版本都固定在一个镜像里之后不管换机器还是帮同事排查拉下来就直接编译不用再折腾环境。缺点是初次构建镜像、进入容器挂载目录这些操作对新手不友好。如果只是自己玩我不建议一上来就用 Docker。1.3 环境变量和路径编译前必须做的一次“体检”不管走哪条路线有三件事我会在编译前先检查能省掉后面一大半报错。第一项目路径不要有中文和空格。Windows 上最常见的坑是用户名是中文默认目录在C:\Users\张三下面放进这个目录的源码在编译时经常出现奇怪的文件找不到、路径解析失败。我的做法是单独建一个纯英文目录比如C:\dev专门放 Android 相关的源码和工具。第二Git 要开启 longpaths。ijkplayer 仓库里嵌套目录比较深Windows 默认路径长度上限是 260 个字符克隆时容易报Filename too long。提前执行git config --global core.longpaths true后续再克隆就不会被路径长度卡住。第三确认 ANDROID_SDK 和 ANDROID_NDK 两个环境变量指向正确的目录。脚本靠这两个变量找 SDK、NDK 和编译工具。最常见的报错是export ANDROID_NDK/path/to/ndk但实际目录层级写错了比如源码里要求 NDK 根目录你写成了ndk-bundle下的某个子目录后面ndk-build会直接提示找不到。2. 环境选型NDK版本、SDK版本和工具链的匹配关系2.1 NDK r10e不是老古董它是ijkplayer的“舒适区”如果你去翻各种编译教程会发现几乎所有人都指定了 NDK 版本有的说 r10e有的说 r14b。我刚接触时也疑惑为什么不能直接下载最新稳定版原因在于ijkplayer 0.8.x 的编译脚本和 FFmpeg 配置在编写时针对的是旧版 NDK 的 GCC 工具链。NDK 在 r17 之后逐步用 Clang 替换 GCC并且移除了不少旧的系统头文件和链接库。你用新 NDK 去编译老项目经常遇到clang: error: unknown argument: -mfpuneon或者sys/sysctl.h找不到这类错误。这不是你写错了代码而是工具链和项目年龄不匹配。我个人用下来r10e 和 r14b 是稳定度最高的两个版本。r10e 稍老但它与 ijkplayer 的脚本配合得很成熟网上绝大多数成功案例也基于它。r14b 则在部分 Android 新机型上生成的 so 兼容性更好一点。如果你不想折腾首选 r10e配好之后基本一镜到底。提示NDK 版本不是一个越新越好的东西。在编译老开源项目时固定版本往往比追新更重要。2.2 Gradle与Android SDK能用脚本编译就尽量别用ASijkplayer 的 android 目录下面是一个完整的 Gradle 工程理论上你可以用 Android Studio 直接打开编译。但问题在于这个工程的 Gradle 版本和 Android Gradle Plugin 版本都比较老新版 Android Studio 打开后会提示升级升级之后又可能和其他模块冲突。我踩过的坑是直接用 AS 构建报了一堆Failed to resolve依赖错误。所以我的建议是日常编译不要用 AS而是直接跑脚本出 aar 包编完之后再集成到自己的新工程里。脚本编译只依赖命令行工具链绕开了 AS 对 Gradle 版本的兼容性检查效率也高。SDK 方面脚本对 compileSdk 的要求不算高。我用的是 API 23 左右的 build-tools 就能过编译。如果你本机已经安装了新版 SDK也不用卸载旧版只要环境变量里指定的 SDK 包含对应 build-tools 即可。2.3 yasm、make、git三个最容易漏掉的小工具三个工具里git 大家基本都装问题不大。但 yasm 和 make 经常被忽略。yasm 是汇编器FFmpeg 里大量使用的汇编优化代码要靠它编译。缺了 yasm编译到 FFmpeg 时会卡在类似Cant locate YASM的报错上。在 WSL 里直接安装apt install yasm在 Git Bash 环境下需要额外下载 yasm.exe 放到 PATH 覆盖的目录里。make 就更基础了。FFmpeg 的编译本身靠 Makefile 驱动Windows 的 Git Bash 并不会自带 make。我见过不少人在这个位置反复失败其实不是项目问题是根本没装 make。WSL 下同样用 apt 装apt install make装了这两个之后编译链路才算完整。你可能会想NDK 不是自带 make 吗NDK 里确实有独立工具链但脚本调用的 make 是环境里的通用 make两者的角色不能混用。3. 编译实操从拉取源码到产出aar的完整链路3.1 拉取源码并固定分支我用的是 0.8.8 分支这是目前使用最广、资料最多的一个版本。操作如下git clone https://github.com/Bilibili/ijkplayer.git cd ijkplayer git checkout -B latest k0.8.8有人会问为什么不直接编 mastermaster 分支更新较频繁某些提交可能和 Windows 编译环境的兼容性未验证。固定分支的好处是你搜到的问题记录、补丁、配置方法都和这个分支对应排查起来容易。3.2 用init-android.sh拉取FFmpeg等依赖源码进入android目录执行./init-android.sh这个脚本会做两件事下载 FFmpeg 和 openssl 的源码包到extra目录并做初步初始化。openssl 分支是可选的用来支持 HTTPS 协议。如果你只做 http 点播、直播或者暂时不需要加密流可以直接跳过./init-android.sh --disable-openssl这一步的坑点在于依赖包体量不小脚本下载过程不会处理特别智能的断点续传。如果你在下载中途关掉终端再跑init-android.sh它通常会重新尝试下载并且可能因为已经存在的半截文件而报错。我的做法是执行前先保证网络稳定中途不要打断万一真的中断先删掉extra目录下面不完整的文件夹再重来。3.3 配置环境并执行ABI编译先设置环境变量export ANDROID_SDK/your/sdk/path export ANDROID_NDK/your/ndk/path然后进入android/contrib目录编译 FFmpegcd android/contrib ./compile-ffmpeg.sh clean ./compile-ffmpeg.sh allclean是为了清掉上次残留的构建产物如果不清理可能会出现一些莫名其妙的链接错误。all表示给所有支持的 ABI 编译。如果只是先验证环境能不能通可以只编译一种架构./compile-ffmpeg.sh armv7aFFmpeg 编译完成后回到android目录编译 ijkplayer 本身cd .. ./compile-ijkplayer.sh all同样可以不带参数或指定单一 ABI./compile-ijkplayer.sh armv7aall会依次编译 armv7a、arm64、x86、x86_64 等架构耗时长我的机器上全量编译要一小时以上。单 ABI 大概二十来分钟。第一次跑建议先单 ABI跑通之后再决定要不要全量。3.4 编译产物有哪些怎么确认成功编译完成后产物在android/ijkplayer下各个模块的build/outputs/aar目录里。你会看到类似这样的文件ijkplayer-java-release.aarJava 层封装库ijkplayer-armv7a-release.aararmv7a 架构的原生库和资源ijkplayer-arm64-release.aararm64 架构的对应产物ijkplayer-exo-release.aarExoPlayer 扩展模块可选怎么确认编译成功最简单的方法看对应目录下是否生成了release.aar文件。另外armv7a模块的build/intermediates下会有对应的.so文件说明 FFmpeg 和封装层都编进去了。到这里你已经拿到了可以直接集成的安装包。多数人第一次编译卡在上面某一步下面我专门开一章把高频报错和处理方法列出来。4. 这份“问题对照表”是我一遍遍踩坑换来的4.1 高频错误对照表下面这张表基本涵盖了我遇到过的 95% 的报错。如果你恰好命中其中一条按对应方法处理即可。报错或现象根因处理Cant locate YASM缺 yasm 汇编器安装 yasm 并确保在 PATH 中ffmpeg download failed/ curl 超时init 脚本拉取依赖失败重新执行脚本或手动补包见 4.2clang: error: unknown argument: -mfpuneonNDK 版本太新换成 r10e 或 r14bsys/sysctl.h: No such file or directoryNDK 新版本移除了旧头文件固定使用旧版 NDKcannot create symlink: Permission deniedWindows符号链接权限不足以管理员身份运行 bash或开启开发者模式ndk-build: command not foundNDK 路径未正确写入 PATH检查环境变量确认路径指向 NDK 根目录Exception in thread main java.lang.UnsupportedClassVersionErrorJDK 版本与 Gradle 版本不匹配安装 JDK 8 并确保命令行使用的是该版本编译到一半内存溢出或进程被杀多 ABI 同时编译资源占用高改成单 ABI 编译或适当增大系统虚拟内存这张表不能替代实操但能帮你快速定位问题。下面挑三个讲细一点。4.2 卡在FFmpeg源码下载环节的手动兜底方案init-android.sh的下载环节是最容易出问题的。虽然脚本本身会检测extra/ffmpeg目录是否存在但网络不稳时半截文件会直接导致后续编译失败。手动兜底的思路很简单自己去下载对应版本的 FFmpeg 源码包然后放到脚本指定的位置。以 0.8.8 分支为例它依赖的 FFmpeg 版本是 3.4.x。你到 FFmpeg 官网找到对应的源码压缩包解压后把目录重命名为ffmpeg放到extra目录下。放置完之后编译脚本会检查这个目录。需要注意目录内必须包含configure脚本并且该脚本要有可执行权限。Windows 下解压的文件没有 Unix 权限位所以在 Git Bash 环境里执行一下chmod x configure这一步很容易漏。权限不对时脚本执行 configure 会提示Permission denied很多人又绕回到是不是依赖没装好的误区里。openssl 同理。如果不编译 openssl直接执行带--disable-openssl参数的初始化脚本即可没必要下载源码包。4.3 NDK版本引发的一类编译报错新版 NDK 导致的报错通常不受具体文件影响而是系统性的。最常见的特征是编译 FFmpeg 或 ijkmedia 模块时突然冒出和架构相关的参数错误例如-mfpuneon不被识别。因为新版 NDK 默认 Clang 对老式 ARM 编译参数不支持而旧版脚本里保留了大量这类参数。这种问题的处理逻辑和代码调试完全无关。不要试图去改 Makefile 或 configure 参数直接换 NDK 版本更高效。如果你下了十几个不同版本的 NDK建议做一个统一目录比如C:\dev\android-ndk下按r10e、r14b子目录存放切换环境变量即可。我自己的习惯是给 ijkplayer 单独准备一个环境变量脚本编译前 source 一下避免把系统和项目的 NDK 配置搞混。4.4 Windows下的符号链接、权限与路径坑最后聊聊 Windows 特有的问题。ijkplayer 的源码仓库里某些文件以符号链接形式存在。Windows 默认情况下创建符号链接需要管理员权限所以普通用户运行 Git Bash 执行初始化时会出现cannot create symlink: Permission denied。解决方式有三种任选其一右键点击 Git Bash 图标选择“以管理员身份运行”。在 Windows 设置里打开“开发者模式”让当前用户获得创建符号链接的权限。改用 WSL 环境编译这一步在 WSL 内不会出现。路径问题我在前面提过这里再说细一点。Windows 的C:\Users\中文用户名这类路径在 NDK 和 FFmpeg 联合编译时容易触发file not found因为工具链对非 ASCII 路径的支持时好时坏。遇到这种情况不要和编译器较劲把整个工程挪到如C:\dev\ijkplayer这种纯英文路径下重新编译通常立竿见影。5. 编译产物接入项目的三个细节点5.1 用module依赖还是aar文件依赖编译得到 aar 之后有两种接入方式一种是把整个android/ijkplayer工程作为模块引入你的 Android 项目另一种是直接拷贝 aar 文件到自己的工程里依赖。我更推荐后者也就是 aar 文件依赖。原因很简单你自己项目的 Gradle 配置是新的而 ijkplayer 工程里的 Gradle 配置是老的强行以 module 依赖时会连带升级或降级插件版本容易出现不可控的连锁报错。aar 相当于解耦的黑盒。用法是在你的app/libs目录下放入 aar 文件然后在build.gradle里声明implementation files(libs/ijkplayer-armv7a-release.aar) implementation files(libs/ijkplayer-java-release.aar)如果你同时需要 Java 层的播放器接口和某个架构的原生库那么至少依赖这两个 aar。是否需要ijkplayer-exo-release.aar取决于你的场景官方 Demo 里带了一个基于 ExoPlayer 的扩展用于兼容更多格式如果只播普通的 http/flv/hls可以不加。5.2 abiFilters与多ABI共存你现在手上有 armv7a、arm64、x86 等多个 aar并不是都要塞进 APK。全塞进去会显著增大安装包而且 x86 架构的 so 在现代真机上根本用不上。我会在defaultConfig里明确限制defaultConfig { ndk { abiFilters armeabi-v7a, arm64-v8a } }这两个架构基本覆盖了当前主流 Android 设备。如果你的播放器还会跑在电视盒子或老旧平板这种 x86 设备上再加一个x86。这里有一个常见的匹配错误你打了 armv7a 的 aar但工程的 abiFilters 只留了 arm64安装后启动播放直接UnsatisfiedLinkError。所以 abiFilters 要和 aar 保持一致。5.3 初始化播放器与常见运行期表现接入工作完成后播放器初始化可以用官方默认方式IjkMediaPlayer player new IjkMediaPlayer();如果想要更好的兼容性我会设置几个关键 option。比如允许播放不规范的封装格式并开启硬解player.setOption(IjkMediaPlayer.OPT_CATEGORY_FORMAT, safe, 0); player.setOption(IjkMediaPlayer.OPT_CATEGORY_PLAYER, mediacodec, 1);硬解跑的其实是 MediaCodec对大多数视频都能流畅播放但部分机型在特定编码下会出现花屏或音画不同步。碰到这种情况可以把mediacodec关掉切回软解。软解对 CPU 占用更高可兼容性最好。第一次跑起来时如果 Surface 黑屏先检查是不是 surface 初始化时序的问题如果声音正常画面不动多半是硬解和封装格式不匹配关掉 mediacodec 就好。这些现象和编译环境无关但新手往往会把它们也算到编译失败头上所以列出来省得你误判。最后分享一个自己常用的排查习惯编译前先检查extra目录里的依赖是否完整再决定要不要重新跑 init 脚本。因为 init 下载这一环确实比较脆弱依赖不完整时直接进编译报错信息五花八门排查起来特别费时间。另外如果你只是为了做一个简单的 http 播放器完全可以跳过 openssl 编译能省下不少编译时间。先把最基本的链路跑通再按需加功能这条路在 Windows 上是最省心的。