网上关于 Android 集成 FFmpeg 的文章很多，但大多数都只介绍了步骤，没有说明背后的原理，若之前没有集成底层库的经验，那就会“神知无知”的走一步看一步，出错几率很大，出错了也不知道原因，然后会乱猜“这篇教程有问题“，“换个版本估计可以”，甚至“电脑有问题，重装下系统试试”。

为什么会出现这种情况，答案很简单：欲速则不达，要实现 Android 端集成 FFmpeg 功能，那就要掌握必需的基础知识，如果连 JNI、NDK都不了解，一上来就参考几秒钟搜出来的集成步骤开始集成，那只会被各种莫名其妙的异常完虐，如果运气好很快就实现了功能呢？ 在我看来这是更大的损失，这些你没有掌握的知识如此接近却又悄悄溜走。

那么在 Android 端集成 FFmpeg 需要掌握哪些基础知识呢？个人认为以下内容是需要了解的：

1. JNI
2. CPU架构
3. 交叉编译
4. NDK
5. FFmpeg 简介

以下知识点阐述是经过反复推敲的，不是随意复制而来，其中融入自己的理解，以个人易于理解的方式记录下来，希望能给你带来帮助。

JNI，即 Java Native Interface ，是 Java 提供用来与其他语言通信的 api ，“其他语言”意味不止局限于 C 或 C++ ,也可以调用除 C 和 C++ 之外的语言，只是大多数情况下调用 C 或 C++ ; “通信”意味着 Java 和 其他语言之间可以相互调用，不止局限于 Java 调用其他语言，其他语言也可以主动调用 Java .

Java 虚拟机实现了跨平台特性， 无法很好的实现与操作系统相关的本地操作，而 C 或 C++ 可以，同时代表着 C 或 C++ 不具备 Java 的跨平台能力，那么当我们在程序中使用 JNI 功能时，就必须关注程序的平台可移植性， JNI 标准要求本地代码至少能工作在任何Java 虚拟机环境。

简而言之，跨平台的 Java 调用了不跨平台的 C/C++，使程序丧失了跨平台性，这就是 JNI 的副作用，所以可以不使用 JNI 时就尽量避免。而大多数不可避免的情况是：已存在用 C/C++ 写的程序/库或者 Java 语言不支持程序所要实现的特性，比如 ffmpeg 是由 C 编写的，则必须要通过 JNI 实现调用。

JNI 的实现步骤很简单，如下：

1. 编写带有 native 方法的 Java 类
2. 生成该类扩展名为 .h 的头文件
3. 创建该头文件的 C/C++ 文件，实现 native 方法
4. 将该 C/C++ 文件编译成动态链接库
5. 在Java 程序中加载该动态链接库

动态链接库是一组源代码的模块，其中包含可供应用程序调用的函数。比如 Windows 下的 .dll 文件就是一种动态链接库，也就是说 Java 程序在 Windows 中运行，所需的动态链接库就是 .dll 文件; 如果 Java 程序在 Linux 中运行，所需的动态链接库就是 .so 文件 ，这里 JNI 的副作用已初见端倪，本来无视操作系统的 Java ，因为 JNI ，就要考虑运行环境是 Windows 还是 Linux 。除此之外，还要考虑 CPU 架构，这也是 Android 中使用 JNI 主要需考虑的 so 库兼容型问题。

对于 Java 程序来说，需要的仅仅是编译后的动态链接库，不需要 C/C++ 文件和 .h 头文件。Android 亦如此，网上很多 Android NDK 教程会把需要编译的 C/C++ 源码放入 Android 工程中，形成类似这样的工程结构：

这对新手来说可能会产生误导，误以为 Android 工程需要 C/C++ 文件或 .h 头文件或者其他的文件，要清楚的是， Android 工程需要的仅仅是编译后的 .so 库，所以我们可以在工程之外编译完后，只将 .so 库移植到工程中。那为什么大多数教程会把源码先移植到 Android 工程中再去编译呢？目的只有一个：节省目录的切换以及 .so 库的复制时间，实际上这些时间微乎其微，我推荐新手将编译操作于工程外进行，更易理解。

我们都知道 CPU 是什么，那 CPU 架构到底是什么呢？回归到“架构”这个词本身含义，CPU 架构就是 CPU 的框架结构、设计方案，处理器厂商以某种架构为基础，生产自己的 CPU，就好比“总-分-总”是文章的一种架构，多篇文章可以都基于“总-分-总”架构。

常见的 CPU 架构有 x86、x86-64 以及 arm 等， x86-64 其实也是基于 x86 架构，只是在 x86 的基础上做了一些扩展，以支持 64 位程序的应用，常见的 Intel 、AMD 处理器都是基于 x86 架构的。

而 x86 架构主打的是 pc 端，对于移动端，arm 架构处于霸主地位 ，由于其体积小、低功耗、低成本、高性能的优点，被广泛应用在嵌入式系统中，目前大多数安卓、苹果手机的 CPU 都基于 arm 架构，此处所说的 arm 架构指 arm 系列架构，其中包括 ARMv5 、ARMv7 等等。

最后再看 Android 端 ， Android 系统目前支持 ARMv5、ARMv7、ARMv8、 x86 、x86_64、MIPS 以及 MIPS64 共七种 CPU 架构，也就是说除此之外其他 CPU 架构的硬件并不能运行 Android 系统。

在某个平台上，编译该平台的可执行程序，叫做本地编译，比如在 Windows 平台上编译 Windows 自身的可执行程序；在 x86 平台上，编译 x86 平台自身的可执行程序。

在某个平台上，编译另一种平台的可执行程序，就是交叉编译，比如在 x86 平台上，编译 arm 平台的可执行程序，这也是 Android 端使用最多的交叉编译类型。

在交叉编译时，由于主机与目标的体系架构、环境不同，所以交叉编译比本地编译复杂很多，需要一些工具来解决主机与目标不同特性的问题，这些工具构成的工具集就叫做交叉编译链。

既然交叉编译比本地复杂很多，那为什么不使用本地编译，比如在 arm 平台编译 arm 平台的可执行程序呢？这是因为目标平台存储空间和计算能力通常是有限的，而编译过程需要较大的存储空间和较快的计算能力，但目标平台无法提供。

我们需要的是 arm 平台的动态库，而这一编译过程往往是在 x86 平台上进行，所以属于交叉编译，需要交叉编译链来实现，所以 NDK（Native Development Kit ）中提供了交叉编译链，方便开发。

Android 中包括七种 CPU 架构，NDK 中自然就有与之对应的交叉编译链，以下是 Android 官网对此的表格描述：

| 架构 | 工具链名称 |
|: ------