简介面向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 采集的链路我用了比较稳的搭配CameraCaptureSessionImageReader或 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 或 128nginx-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-buffering0 并开启 framedrop。画质相关动态码率场景下网络差时适当降低编码码率但不要将分辨率与码率过度匹配失调建议使用MediaCodec的动态码率控制接口系统会根据硬件编码器的反馈自动调整。稳定性相关网络切换Wi-Fi 切 4G时必须重建推流连接崩溃恢复场景下需要再次获取 Camera2 实例并重新配置编码器。7.2 扩展方向把数据叠加进直播流完成基本的音视频推流之后我还试着把传感器数据叠加到推流中。例如基于手机麦克风计算环境声强或者通过 BLE 连接心率带把心率数据通过 SEISupplemental 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其实很多思路是相通的核心仍然是采集、编码、传输、播放这四个环节的衔接质量。本文还有配套的精品资源点击获取