简介：面向Android直播推流开发者的完整工程资料包，围绕直播推流全链路展开，覆盖服务器搭建、图像采集、H.264视频编码、AAC音频编码及RTMP封装推流等核心环节。压缩包约112.53MB，内含Android应用源码、Nginx服务器源码、RTMPDump源码、x264与FAAC源码及其编译好的Android函数库，并附带远程Linux控制工具、二进制查看工具和FLV视频文件分析工具，方便对照验证。已有1295人学习下载，适合正在攻克Android推流链路、需要参考完整实现方案的初中级开发者。把繁琐的源码编译和工具链整理到一处，可配合对应博文快速搭建直播服务器与客户端实验环境，结合NV21图像采集、PCM音频采集和RTMP封装的代码逐段理解，借助FLV分析工具检查封装结果，能有效缩短排错时间。

1. 项目缘起：为什么是 Android + RTMP

做音视频开发这几年，我陆续接触过 WebRTC、HLS、SRT 这些协议，但最后在移动端选型时，RTMP 仍然是我绕不开的选择。原因很简单：RTMP 的生态太成熟了。服务端有 nginx-rtmp 这类开箱即用的方案，播放端几乎所有播放器都支持 RTMP 输入源，推流端在 Android 上也有成熟的开源工程可以借鉴。这个项目的核心目标，就是基于 Android 原生平台实现一套 RTMP 直播推流方案，配合自建服务端完成从采集、编码、推到播放的完整闭环，同时沉淀一份可复用的技术资料。

先交代一下我实际做的事情：用 Camera2 API 做摄像头采集，AudioRecord 做麦克风采集，然后交给 MediaCodec 做硬编码，最后通过 RTMP 协议把编码后的数据推送到 nginx-rtmp 服务器，拉流端用 VLC 或者 IJKPlayer 验证效果。整个过程全部在 Android Studio 中完成，从新建工程到跑通推流，实测下来没有太离谱的坑，但细节问题相当多，这篇文章就是把这些踩过的坑和验证过的方案梳理成体系。

适合看这篇文章的读者，我默认你有两类情况：一是刚接触 Android 音视频开发，想找一条能快速跑通 RTMP 推流的路子；二是已经做过一些采集编码工作，但在推流稳定性、延迟控制、服务端搭建上卡住了。无论哪类，这篇内容的核心目标都是让你少走弯路，我踩过的坑，你尽量别再踩一遍。

2. 整体设计与技术选型拆解

2.1 技术方案的取舍逻辑

RTMP 推流在技术选型上，最先要决定的是推流库的路线。我试过两条路，一条是全套自研，从连接握手到分包发送全手写；另一条是集成开源库，比如 rtmp-rtsp-stream-client-java 或者原生自研实现。两条路各有优劣势，这里列个表直观对比一下。

方案	优点	缺点	适用场景
基于开源库二次封装	开发周期短，已有大量现成实现	依赖库的质量参差不齐，出问题时调试链路较长	快速上线、验证产品逻辑
基于协议规范手写推流	完全可控，方便定制协议细节	开发和调试成本高，需要深入理解 RTMP 协议	学习研究、定制化需求强的场景

我最终选择了基于协议理解程度较高的开源工程做二次开发，理由是推流的核心难点不在 RTMP 协议本身，而在于音视频数据的同步和编码参数的匹配。协议层面的握手和 chunk 分包，在标准实现中已经非常成熟，没必要重复造轮子。

2.2 为什么硬编码优先于软编码

在 Android 端做编码，MediaCodec 硬编码是绝大多数场景的优先选择。原因直观：硬编码充分利用了手机 SoC 里专门的视频编码硬件单元，在功耗、发热、帧率稳定性上都有明显优势。软件编码在低端机上跑 720p，帧率波动大是常态，真机发热后还会触发系统降频，造成帧率进一步下跌，形成恶性循环。

我用 MediaCodec 配置 H.264 编码器时，关键的参数选择如下：

MediaFormat videoFormat = MediaFormat.createVideoFormat("video/avc", 1280, 720);
videoFormat.setInteger(MediaFormat.KEY_COLOR_FORMAT,
        MediaCodecInfo.CodecCapabilities.COLOR_FormatSurface);
videoFormat.setInteger(MediaFormat.KEY_BIT_RATE, 2_000_000);
videoFormat.setInteger(MediaFormat.KEY_FRAME_RATE, 30);
videoFormat.setInteger(MediaFormat.KEY_I_FRAME_INTERVAL, 2);

这里有个细节： COLOR_FormatSurface 配 setInputSurface() 是效率最高的输入方式，因为 Camera2 的预览数据可以直接通过 Surface 流转进编码器，省去了 YUV 数据的拷贝过程。如果使用 COLOR_FormatYUV420Flexible 这种方式，则必须手动拿到 YUV 数据，再通过 ByteBuffer 交给编码器，性能开销会明显增加。我实际对比过，Surface 输入模式比 ByteBuffer 输入模式在同等码率下能提升 10% 以上的编码帧率，功耗也有可感知的下降。

2.3 音频编码与音视频同步

音频方面我选择 AAC-LC 编码，采样率 44100Hz，单声道，码率 64kbps。这个配置在直播场景下是性价比很高的组合，既能保证人声清晰度，又不会挤占视频的码率空间。RTMP 的音视频同步机制依赖时间戳，推流端在每个包上都带有绝对时间戳，播放端基于时间戳做对齐播放，所以编码器输出的时间戳必须准确可靠，这一点在后续做音视频合流时尤为关键。

实际开发中，我用了同步时钟策略：视频时间戳参考编码器的 outputBufferInfo.presentationTimeUs ，音频时间戳参考 AudioRecord 的读取位置换算，两者统一从 System.nanoTime() 推导基准点，避免使用各自的独立时钟导致音画不同步。这个坑我在早期确实踩过，最初直接用了 AAC 编码后的时间戳，结果视频偶尔会比音频快几百毫秒，拉流端画面跳变感明显。

3. 环境准备与工程搭建

3.1 Android Studio 环境配置细节

工欲善其事，必先利其器。Android Studio 的安装和配置本身不算难，但有几个细节值得注意。如果你是从官网下载，需要留意 Gradle 和 SDK Build Tools 的版本匹配问题。我遇到过 The following SDK component was not installed: Android SDK Build-Tools 37 这种报错，原因是本地 SDK 缺少对应版本，Android Studio 尝试自动下载又因为网络原因失败。解决办法很简单：到 SDK Manager 里手动勾选对应版本的 Build-Tools 安装，然后重新 Sync 工程。

另一个高频问题是每次新建项目都要下载 Gradle。这是因为 Android Studio 默认会根据项目模板匹配 Gradle 版本，如果本地没有对应版本就会联网下载。建议优先使用国内镜像源来配置 Gradle 分发包和管理依赖，具体做法是在项目的 build.gradle 文件中，将仓库地址指向国内可访问的 Maven 镜像，同时在 gradle-wrapper.properties 中确认 Gradle 版本已存在本地缓存。

3.2 用 SurfaceView 桥接 Camera2 与编码器

Camera2 采集的链路，我用了比较稳的搭配： CameraCaptureSession + ImageReader 或 Surface 直通。如果追求最低延迟，建议让 Camera2 的预览目标直接指向 MediaCodec 的输入 Surface，这样相机输出的 YUV 帧直接进入编码器，没有任何中间拷贝。但直接让预览指向编码器输入的话，你会看不到预览画面，所以通常做法是同时设置两个 Surface，一个交给 TextureView 或 SurfaceView 显示，另一个交给编码器的输入 Surface。

我第一次实现时，先写了用 ImageReader 拿 YUV 再转给编码器的逻辑，实测下来 CPU 占用率在 720p 30fps 场景下会达到 35% 左右，而且摄像头预览与编码帧之间存在肉眼可察觉的延迟。后来改造为双 Surface 方案，CPU 占用率降到 15% 以内，链路延迟也缩短了。这里建议直接将 Camera2 的输出目标列表设为 [previewSurface, encoderSurface] ，系统会自动帮你完成同一份帧数据的分发。

3.3 权限与后台限制的准备工作

推流应用涉及的权限主要有 CAMERA 、 RECORD_AUDIO 、 INTERNET 三项。注意 Android 6.0 以上是动态权限，必须在运行时申请，而且 RECORD_AUDIO 属于敏感权限，如果用户拒绝，应用必须做降级处理。另外我在真机测试时遇到一个典型问题：后台推流一段时间后，系统会回收 AudioRecord 的资源，导致音频出现"滋滋"的杂音。排查下来是目标设备开启了电池优化，将应用的后台运行能力限制了。解决办法是在应用内引导用户关闭电池优化白名单，并在 onPause 之前主动释放编码器和推流连接，避免资源冲突。

4. RTMP 推流核心环节实现

4.1 推流连接与握手流程的简易理解

RTMP 的握手流程在标准实现中比较复杂，但使用现成库时你基本不需要关心这三个包的交换细节，只需要了解其作用是确认对端支持 RTMP 协议并协商 chunk 大小。真正需要关注的业务层代码，是连接建立后如何组织 FLV 格式的音视频包。

我在工程里封装了一个 RtmpPushClient 类，内部维护 Socket 连接和发送线程队列，对外暴露 connect(url) 、 publishStream() 、 sendVideoData() 、 sendAudioData() 四个核心方法。发送数据时有一个很容易忽略的点：每次发送的 FLV tag 必须包含正确的 header，其中类型标识 0x09 代表视频、0x08 代表音频，不要搞混。如果顺序反了或者 header 缺失，拉流端会黑屏但推流端看起来一切正常。

4.2 H.264 关键帧与 SPS/PPS 的处理

H.264 编码器的输出数据里，SPS（序列参数集）和 PPS（图像参数集）不是每个帧都带的。它们决定了播放器解码器是否能正确初始化，刚连接时播放器需要这两个参数才能开始解码。所以推流端必须在首个关键帧之后马上附带 SPS/PPS，或者在关键帧前面单独发一份配置信息。

我用 MediaCodec 取 SPS/PPS 的方式是通过 MediaFormat 的 KEY_CSD_0 和 KEY_CSD_1 ，拿到后在推流时先发送这两个配置包，再发送 IDR 关键帧。如果播放端总是"卡住转圈"但推流端持续有数据，优先排查是否漏发了 SPS/PPS。这个坑我印象极深，第一次调通视频推流时就是漏了这一步，后面的帧全发上去了但播放器一直黑屏。

关于关键帧间隔，我设置了 2 秒一个 IDR 帧，即 KEY_I_FRAME_INTERVAL 为 2。这个值影响的是延迟和画质恢复速度。直播场景建议 1 到 2 秒，点播场景可以适当拉长到 3 到 5 秒。注意：如果设置太长，播放端从中间开始播放时等待关键帧的时间会变长，直接影响首屏体验。

4.3 推流地址与服务端 URL 组成

RTMP 推流 URL 的格式通常是 rtmp://server-ip:port/live/streamKey 。其中 /live/ 是应用名， streamKey 是流标识。nginx-rtmp 的默认配置里， application live 会接收任意 streamKey，但生产环境建议做鉴权校验。我在本地调试时用的地址是 rtmp://192.168.1.100:1935/live/test ，拉流端也用同样的地址，中间件是 VLC 播放器，首次验证通过只花了几分钟。

需要注意的是，Android 模拟器上推流到局域网服务器通常不通，因为模拟器的网络地址映射和真机不同。我用的是真机调试，USB 连接后通过 adb shell 检查网络连通性，具体命令是：

adb shell ping 192.168.1.100

如果 ping 不通，十有八九是手机和服务器不在同一网段，检查路由器配置或者防火墙入站规则即可。

5. nginx-rtmp 服务端搭建与配置

5.1 服务端下载与编译要点

nginx-rtmp 本质上是一个 nginx 模块，需要将模块源码集成到 nginx 源码树中编译。如果你只想快速测试，直接下载带 rtmp 模块的预编译版本会更省事。我自己是从源码编译的，因为后续要加鉴权和 HLS 录制功能。

git clone https://github.com/arut/nginx-rtmp-module.git
wget http://nginx.org/download/nginx-1.18.0.tar.gz
tar -zxf nginx-1.18.0.tar.gz
cd nginx-1.18.0
./configure --add-module=../nginx-rtmp-module --with-http_ssl_module
make -j4
sudo make install

编译过程中最容易出现的问题是缺少 PCRE 和 zlib 依赖，用包管理器装上即可。如果编译报错提示找不到 openssl，也需要提前安装 libssl-dev。整体编译时间在普通机器上大概几分钟，耐心等完就行。

5.2 nginx.conf 中的关键配置

服务端的 nginx.conf 里，rtmp 块是核心。以下是我实际在用的最小配置：

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            record off;
            allow play 127.0.0.1;
            allow play 192.168.1.0/24;
            deny play all;
        }
    }
}

注意 chunk_size 直接影响了推流端打包的 chunk 大小，如果客户端与服务端不一致会导致解析异常。主流推流库默认使用 4096 或 128，nginx-rtmp 设置 4096 即可。

allow play 这段限制了播放来源 IP，保护流不被随意拉取，但推流的权限没有限制。生产环境建议使用 on_publish 回调做鉴权，这个后面有机会单独展开。

5.3 验证服务端是否正常

配置完 nginx 后，执行 nginx -t 检查语法，然后启动。接着在推流端发起推流，并在服务器上通过日志确认是否收到流。我常用的一个快速验证命令是：

tail -f /usr/local/nginx/logs/error.log

如果看到类似 play 或 publish 的日志输出，说明推流已经到达服务端。网络层面排查还可以用 lsof -i:1935 确认端口监听正常。如果是云服务器，记得在安全组规则里放行 TCP 1935 端口，这一步漏了的话，推流端会卡在连接超时。

5.4 使用公开测试地址做快速验证

在服务端搭建起来之前，如果你想先验证推流端代码是否正确，可以使用网络上公开的 RTMP 测试地址。搜索栏里的 "rtmp测试地址" 对应的是这类资源，但要注意公开地址通常带宽和稳定性有限，且可能在高峰期拒绝连接。我用公开测试地址的体验是：验证握手和音视频数据封包确实很快，但别指望它能扛住大规模的推流压力。建议测试通过后立刻切换到自建服务器。

6. 播放端验证与兼容性问题排查

6.1 拉流端播放器选型

推流成功之后，拉流验证是闭环的最后一公里。桌面端我用 VLC 验证，输入同一路 RTMP 地址，VLC 对延迟的容忍度比较高，容易掩盖推流端的细节问题。移动端我用 IJKPlayer 做真机验证，因为它对 RTMP 的支持比较完善，而且能输出详细的播放统计信息。

在 Android 上集成 ijkplayer 实际上就是添加 so 库和 java 层的封装类，开发者需要做的就是将播放器的 setOption 设置好：

ijkMediaPlayer.setOption(IjkMediaPlayer.OPT_CATEGORY_FORMAT, "rtmp_buffer_size", "1024");
ijkMediaPlayer.setOption(IjkMediaPlayer.OPT_CATEGORY_PLAYER, "packet-buffering", 0);
ijkMediaPlayer.setOption(IjkMediaPlayer.OPT_CATEGORY_PLAYER, "framedrop", 1);

第一项控制 RTMP 缓冲大小，第二项关闭包缓冲以降低延迟，第三项允许丢帧以保持实时性。这三个参数组合下来，局域网环境下端到端延迟能控制在 1 到 2 秒以内，基本满足互动直播的体验需求。

6.2 播放黑屏时的排查顺序

黑屏是推流调试中最常见的现象，按我的经验，排查顺序应该是：先看服务端日志是否收到流，再看推流端发送的数据包类型是否正确，最后检查播放器初始化参数中的解码器配置。如果服务端日志有 publish 记录但播放黑屏，重点查 SPS/PPS 是否发送。如果服务端根本没有 publish 记录，那就是推流连接失败，查网络连通性和端口放行。

有一次我排查了一个多小时，最后发现是推流端把视频帧的类型标识写错了，发出来的 tag 让我做成了音频类型 0x08。VLC 不会明确报错，但解码器始终在等视频数据。这种错误很难快速定位，所以建议在推流端打印每个关键事件点的日志，包括连接成功、发送关键帧、发送音视频包的数量统计，能大大缩短排查时间。

6.3 常见报错一栏：OpenCV 打开 RTMP 失败的现象

热词里有 "opencv 打开 rtmp 失败"，这个场景我虽然没有专门去做，但大体原因可以推断。OpenCV 的 VideoCapture 并不原生支持 RTMP 协议，它底层依赖 FFmpeg 的 RTMP 解码能力，如果编译 OpenCV 时没有链接 FFmpeg 的 RTMP 支持，或者在系统环境里缺少 RTMP 相关库，打开 RTMP 地址就会失败。解决方向有两个：一是改用带 FFmpeg 后端且启用了 RTMP 的 OpenCV 构建版本，二是先通过播放器确认 RTMP 地址本身可用，再从 OpenCV 层面检查依赖库是否齐全。这里要注意，即使地址可用，OpenCV 的 RTSP 打开成功率通常也比 RTMP 高，因为 RTSP 库的支持链路相对简单。

6.4 adb shell 与日志抓取技巧

在 Android 设备上调试推流应用， adb 是绕不开的工具。我常在终端里搭配使用：

adb logcat -s RtmpClient:V MediaCodecEncoder:V AudioEncoder:V

通过 tag 过滤日志，可以快速看到推流链路每个节点的状态。如果遇到涉及文件读写路径的问题，可以用 adb shell 进入设备，检查和修改 /storage/emulated/0/Android/data 目录下的应用专属文件。特别提醒：Android 对 /storage/emulated/0/Android/data 的访问权限做了收紧，低版本上能直接读写的目录，在高版本上可能会提示 Permission denied 。这时候要检查应用是否开启了所有文件访问权限，或者在 AndroidManifest.xml 中声明对应权限。

7. 项目落地总结与经验沉淀

7.1 推流性能调优清单

整套流程跑通之后，性能调优也是一个必须做的环节。我从延迟、画质、稳定性三个维度总结了一份清单：

• 延迟相关：确认 KEY_I_FRAME_INTERVAL 设置合适；检查推流端发送队列是否出现积压，如果积压说明码率超过了上行带宽，需要适当降低视频码率；播放端设置 packet-buffering=0 并开启 framedrop。
• 画质相关：动态码率场景下，网络差时适当降低编码码率，但不要将分辨率与码率过度匹配失调；建议使用 MediaCodec 的动态码率控制接口，系统会根据硬件编码器的反馈自动调整。
• 稳定性相关：网络切换（Wi-Fi 切 4G）时，必须重建推流连接；崩溃恢复场景下，需要再次获取 Camera2 实例，并重新配置编码器。

7.2 扩展方向：把数据叠加进直播流

完成基本的音视频推流之后，我还试着把传感器数据叠加到推流中。例如基于手机麦克风计算环境声强，或者通过 BLE 连接心率带，把心率数据通过 SEI（Supplemental Enhancement Information）或辅流通道叠加到视频流中。这个思路适合做互动直播和运动健康场景的原型验证。

BLE 心率数据采集，Android 端使用系统的 BluetoothLeScanner + BluetoothGatt 就能拿到实时心率值，难点在于保活和异常断线重连。iOS 的 CoreBluetooth 设计得相对完善，Android 端则需要自己做看门狗定时器，每 5 秒检查一次连接状态。我在实测中发现，手机息屏后部分设备的 BLE 回调会被系统冻结，解决方案是使用前台服务并申请对应的后台运行权限。

声强计的实现则更简单，AudioRecord 的 read() 方法拿到 PCM 数据，按固定窗口计算 RMS 值，再映射到声强等级。如果后续要把声强和心率数据做可视化叠加，可以把数据编码成字幕轨或直接叠加在视频画面中，形成"数据 + 实时画面 + 实时声音"三位一体的直播内容。

7.3 个人实践中的几点体会

整个项目做下来，我最深的体会是音视频链路的问题排查非常依赖"单点验证"方法。同一时间只改动一个环节，然后拉流验证，这样的推进方式最稳妥。比如先只推视频不推音频，确认视频链路正常后，再放开音频，否则音频和视频的 bug 混在一起很难定位。

另外，不要轻信网上一些"直接可用"的代码片段。RTMP 推流涉及编解码器、摄像头、音频设备、网络通路多个模块，任何一个环节的版本差异都可能导致行为不同。我建议拿到别人的工程后，先跑通一个最小 Demo，再逐步添加自己的业务逻辑，这样出问题时能快速确定是自己引入的问题还是原工程的遗留问题。

最后提一句工具链：Android Studio 到目前已经非常稳定，新用户可以放心使用默认配置，把中文界面设置为非核心需求，因为绝大部分报错信息和第三方博客都以英文为主，熟悉英文界面反而能减少理解偏差。SDK 和 Build-Tools 的下载问题，使用加速镜像后基本无感。真正决定项目推进速度的，还是你对音视频基础概念的掌握程度和排查问题的耐心。

这套 Android RTMP 推拉流方案从采集、编码、推流、服务端搭建到播放验证，完整跑通后你会对整个直播链路有更本质的理解。后续如果要支持更多协议，比如 SRT 或者 WebRTC，其实很多思路是相通的，核心仍然是采集、编码、传输、播放这四个环节的衔接质量。

本文还有配套的精品资源，点击获取