Android 屏幕与麦克风/扬声器音频采集的RTMP推流与轻量级RTSP服务工程化实践：架构深度解析

​ 在各类行业数字化应用中，移动端设备正越来越多地承担“信息采集节点”的角色： 过程展示、远程协作、移动巡检、设备操作演示、培训讲解、现场可视化……这些场景都在强调同一件事——如何把终端屏幕内容与声音，以足够低的延迟、足够稳定的方式实时传输出去。

对于 Android 平台而言，要做好这件事并不轻松。屏幕采集需要在高分辨率下保持稳定输出；音频通常来自不同来源（麦克风、人声、系统音等），并且需要并行采集与混合；网络环境从 Wi-Fi 到 5G，再到企业内网，波动明显；传输方式也常常需要同时兼容外网推流（如 RTMP）与局域网的低延迟访问（如 RTSP）。

大牛直播 SDK（SmartPublisher）正是针对这些典型的行业需求，构建了屏幕采集、多路音频融合、RTMP 推流、内置轻量级 RTSP 服务的一体化能力。其 Android 端源码采用高度模块化的架构设计，并经过多行业、多场景的长期打磨，在性能、稳定性以及工程落地性上呈现出较为成熟的体系。

本文将结合大牛直播SDK屏幕采集推送的源码文件，包括：

• StreamMediaDemoService.java
• NTStreamMediaProjectionEngineImpl.java
• NTVirtualDisplaySurfaceSinker.java
• NTStreamMediaEngine.java
• NTStreamMediaServiceInterface.java
• NTStreamMediaBinder.java
• LibPublisherWrapper.java
• SmartPublisherJniV2.java

从 架构层、屏幕采集层、音频采集层、传输层、稳定性优化层 五个维度，完整、系统地解析大牛直播 SDK 在 Android 端是如何做到“高画质 + 低延迟 + 高稳定”的。

一、整体架构设计：Service → Engine → Native 的三层模型

从 Demo 工程和源码组织可以看出，大牛直播 SDK 带有鲜明的三层架构：

[最上层] 业务 Service 层：StreamMediaDemoService.java  
        ↓  
[中间层] 引擎调度层：NTStreamMediaProjectionEngineImpl.java  
        ↓  
[底层]  C++ Native 编解码与协议栈：SmartPublisherJniV2.so  

这种组织方式的优势非常明显：

• Service 层提供“进程保活 + 权限抽象 + 生命周期托管”
• Engine 层提供“采集逻辑 + 音视频调度 + JNI 桥接”
• Native 层提供“硬编 + 网络协议 + 混音 + 缓冲机制”

没有把逻辑写死在 Activity 中，而是把视频链路变成“后台可持续运行的系统服务”，这是专业级 SDK 的典型特征。

1.1 前台服务：Android 8.0+ 的保命法则

在 StreamMediaDemoService.java 中，SDK 将屏幕采集、音频采集、推流引擎全部挂在 Foreground Service 上运行：

startForegroundService();
createNotificationChannelIfNeeded();

并根据系统版本动态申请：

• FOREGROUND_SERVICE_TYPE_MEDIA_PROJECTION
• FOREGROUND_SERVICE_TYPE_MICROPHONE

这样设计有三个关键好处：

1. 大幅减少被系统强杀的概率
2. 在锁屏、切后台、长时间运行中保持稳定
3. 音视频采集链路不与 UI 层耦合

对于屏幕采集类应用，这是工业级方案。

1.2 Engine 层：高并发音视频调度的大脑

NTStreamMediaProjectionEngineImpl.java 是整个链路的核心，它控制：

• 屏幕图像的帧流转
• 麦克风 / 系统内录的数据合并
• 推流状态管理
• RTSP 服务启动与流发布
• 编码配置与动态调整
• JNI 数据投递

它采用了 HandlerThread + 多线程模型：

private HandlerThread image_thread;
private HandlerThread running_thread;

并为不同任务绑定不同线程，确保：

• 图像处理不阻塞业务控制
• 音频回调不阻塞 JNI
• 推流状态不被 UI 阻塞
• 多线程有序同步（读写锁控制）

这种线程模型是直播 SDK 的专业标配。

二、视频采集：MediaProjection + VirtualDisplay 的零拷贝设计

Android 屏幕采集的核心是 MediaProjection，但真正的工程难点在于“如何将屏幕像素高效送入编码器”。

大牛直播 SDK 采用的路径如下：

MediaProjection  
    ↓  
VirtualDisplay  
    ↓ Surface  
    ↓ ImageReader → RGBA  
    ↓ JNI （底层转换：RGBA → I420/NV12）  
    ↓ 硬件编码器 MediaCodec  

这条路径包含了多个关键工程细节。

2.1 VirtualDisplay 的创建与分辨率策略

在 NTStreamMediaProjectionEngineImpl.java 中，SDK 构造了一个专用的 Surface sinker：

NTVirtualDisplaySurfaceSinker sinker = new NTVirtualDisplaySurfaceSinker(...);

并根据用户选择动态确认输出分辨率：

• RESOLUTION_LOW
• RESOLUTION_MEDIUM
• RESOLUTION_HIGH

这不是简单放大/缩小，而是结合屏幕实际分辨率比例进行适配，使游戏、视频类画面不会变形。

绝大多数开源方案直接输出全分辨率，会导致推流码率难以压缩、弱网下严重卡顿，而 SDK 的多档策略意味着用户在弱网环境可以动态降分辨率并维持流畅。

2.2 ImageReader：丢帧优先策略降低延迟

在 NTVirtualDisplaySurfaceSinker.java 中，核心逻辑是：

Image image = reader.acquireLatestImage();

而不是：

reader.acquireNextImage();

区别非常关键：

这说明 SDK 的设计理念很明确：

直播优先实时性，而不是每一帧都要处理。

因此 SDK 默认就是 低延迟直播模式最佳实践。

2.3 JNI 层的零拷贝颜色空间转换

图像在 Java 层是 RGBA 格式，但硬编常用的输入格式是：

• COLOR_FormatYUV420Flexible
• COLOR_FormatYUV420SemiPlanar

大牛直播 SDK 并不在 Java 层做繁重转换，而是直接：

stream_publisher_.PostLayerImageRGBX8888ByteBuffer(...)

交给 Native 层。C/C++ 中通常使用：

• ARM NEON SIMD 优化
• 零拷贝内存复用
• 分块像素转换流水线

这样能让 1080p/2K 60fps 在中低端机型依然稳定。

这是专业 SDK 与普通 Demo 最大差异之一。

三、音频采集：麦克风 + 系统内录的双路混音引擎

Android 10+ 的 AudioPlaybackCapture 让系统内录变得合法，但绝大部分开源代码在“系统音 + 麦克风”并存时会崩溃、延迟巨大、或音质糟糕。

大牛直播 SDK 在这块做了完整的工程化处理。

3.1 麦克风采集（NTAudioRecordV2）

对应代码：

SmartPublisherOnPCMData()

采集特点：

• 支持 44.1k/48k 采样率
• 支持单声道/双声道
• 自动适配不同厂商（OPPO/VIVO 小米等）策略
• 对抖动、断续回调做了补偿

麦克风采集是主播声音的主要来源，因此稳定性优先。

3.2 系统音（AudioPlaybackCapture）

在 NTStreamMediaProjectionEngineImpl.java 中：

start_audio_playback_capture();

实现了：

• 合法系统音采集（Android 10+）
• 自定义 AudioPlaybackCaptureConfiguration
• 与 MediaProjection 绑定
• 防止音频重复采集（手机扬声器回灌问题）

并最终将 PCM 数据交给底层 Mixer：

麦克风PCM  \
             → Native Mix → 编码 → 推流
系统音PCM  /

混音在 C/C++ 层完成意味着：

• 减少延迟
• 避免 Java 层卡顿导致音频断裂
• 支持多个源同时混音（以后可扩展）

这是工程级音频架构。

四、传输核心：RTMP 推流 + 内置 RTSP 服务的双模引擎

大牛直播 SDK 最大亮点之一是：

手机端既能推流，也能自己变成 RTSP 服务器。

下面分别来看。

4.1 RTMP 推流：专业级配置能力

RTMP 推流在 LibPublisherWrapper.java 中进行了全封装，支持：

• H.264 / H.265（软编 + 硬编）
• 可变码率（VBR）
• 动态码率估算
• 多线程异步发送
• 自动重连策略
• GOP 自适应

启动推流逻辑如：

lib_publisher_.SmartPublisherStartPublisher(handle, rtmp_url);

并可以动态控制：

SmartPublisherSetVideoEncoderType(handle, 1 or 2);
SmartPublisherSetSwVBRMode(handle, vbr_mode);

意味着 SDK 能够根据网络情况自动选择最合理的码率模式。

4.2 轻量级 RTSP：手机瞬间变成一台“移动流媒体服务器”

RTSP 服务启动流程（摘自 LibPublisherWrapper.java）：

OpenRtspServer();
SetRtspServerPort();
StartRtspServer();
AddRtspStreamServer();
StartRtspStream();

简单说：

• 手机打开 8554 端口
• 发布一个 RTSP Stream（如 /live/stream1）
• 同局域网内的任意设备都可拉流

比如大牛直播SDK的SmartPlayer：

rtsp://192.168.1.8:8554/stream1

非常适合：

• 会议同屏
• 局域网监控
• 课堂投屏
• 车载/无人机视频链路
• 工控屏幕共享

不需要 SRS/Nginx-RTMP 服务器——这是工业级移动端极为少见的能力。

五、稳定性与性能优化：隐藏在细节里的硬功夫

大牛直播 SDK 在稳定性相关的代码细节非常多，下面列出最关键的几项。

5.1 线程安全：读写锁保护推流核心

在 LibPublisherWrapper.java 变量可见：

private final ReentrantReadWriteLock lock = new ReentrantReadWriteLock();

读锁：

• 高频回调
• PCM 数据
• RGBA 数据
• 相机/屏幕帧
• 推流状态查询

写锁：

• 启动/停止推流
• 切换编码方式
• 关闭引擎

这保证了：

推流过程中不会因状态切换导致 Native 层崩溃。

这是专业级 SDK 的基本功，也是很多开源项目缺乏的地方。

5.2 动态码率估算：自动选码率 = 更少卡顿

函数 estimate_video_hardware_kbps 会根据：

• 分辨率
• 帧率
• 编码类型（H264/H265）

动态给出建议码率。

示例：

这样避免了两个常见坑：

• 新手设置码率过低 → 画质糊
• 新手设置码率过高 → 弱网掉帧卡顿

自动化就是工程化。

5.3 弱网优化：VBR / 码率回调 / 质量监测

SDK 在 Native 层支持：

• VBR 可变码率模式
• 超时自动重发
• TCP 慢启动优化
• 丢包控制
• jitter 缓冲深度自适应

在实际 4G/5G 场景非常有帮助。

六、RTSP/RTMP 在真实业务场景中的实践价值

无论是企业内部的移动终端、工业现场终端，还是各类智能设备，在“将设备屏幕内容实时传输出去”这件事上，都有高度一致的需求特征：低延迟、稳定性、跨网络环境的适配能力。

基于大牛直播SDK提供的屏幕采集 + 多路音频 + RTMP/RTSP 双模架构，可以覆盖大量传统行业的典型场景。

1. 移动终端的远程协作与可视化支撑

许多行业需要将设备的实时画面共享给现场同事或远程中心，例如：

• 移动端进行远程培训、流程演示
• 外勤人员共享操作步骤
• 售后/客服向总部专家实时回传画面

这些应用要求：

• 屏幕内容实时传出
• 语音沟通与系统声并存
• 网络环境变化时仍保持稳定

依托 RTMP 或内置 RTSP 服务，不需要专门部署大型流媒体服务器，即可完成跨部门的实时协作。

2. 工业与能源领域的终端屏幕可视化

在工业设备、运维终端或车载设备上，屏幕往往承载着关键的运行状态，需要在后台或监控中心实时查看：

• 工控终端运行界面远程监看
• 车载/手持设备的实时状态回传
• 生产设备屏幕的远程诊断和协助

这些设备通常运行在封闭网络或专网中，使用 RTSP 的局域网低延迟传输模式能大幅降低部署成本，让移动端直接充当“可推可拉”的微型视频节点。

3. 教育、培训与讲解场景的屏幕共享

在一些组织内部培训、操作演示、技术讲解场景中，常常需要讲解者直接共享移动终端的屏幕内容：

• 内训课程的移动端演示
• 讲解人员的实时操作展示
• 多终端同时观看、延迟要求较低

使用 SDK 内置的 RTSP 服务，可在局域网内同时提供多个拉流端进行实时观看，延迟可稳定维持在较低区间，不需要额外部署流媒体服务器。

4. 专网设备或封闭系统的屏幕回传

传统行业中常见的“封闭系统”“内网设备”“专网终端”，往往不便安装大型流媒体服务。

大牛直播 SDK 的 RTSP 内置服务让移动端可以直接变成：

一台可即开即用的轻量级流媒体节点

适用于：

• 设备运行状态回传
• 专网环境下的远程监控
• 多人并发查看的实时可视化场景

无需外网，无需中心服务器。

总结

在上述类型的传统行业场景中，屏幕采集 + 多路音频融合 + RTSP/RTMP 双模传输形成了一种非常通用且工程化的实时链路能力。 既能满足跨网络的灵活传输，也能适应封闭环境中的本地低延迟回传，是很多行业场景构建“移动视频节点能力”的基础模块。

七、总结：SmartServicePublisherV2 在 Android 屏幕采集方向的工程优势

综合全文可以看到，大牛直播 SDK的SmartServicePublisherV2 demo实例，在移动端屏幕采集链路上的优势并不是某一个点，而是来自多个层面的体系化能力：

① 架构清晰：Service / Engine / Native 三层解耦

这种分层方式让屏幕采集、音频处理、推流逻辑与 UI 层完全隔离，具备：

• 较高的稳定性
• 更好的跨 Android 版本兼容能力
• 易于维护的代码结构

这也是许多生产级 SDK 与普通 Demo 的核心差异。

② 高性能屏幕采集链路：VirtualDisplay + 零拷贝传输

SDK 使用 VirtualDisplay + RGBA 直投 Native 方式，避免 Java 层重度像素处理。 丢弃旧帧、只保留最新帧的策略，使采集链路天然具备低延迟特性，适合实时展示类业务。

③ 音频采集与混合机制完善：麦克风 + 系统音并行工作

SDK 同时支持麦克风采集与系统播放音采集，并由 Native 层完成混音。 这为许多需要“操作演示 + 背景音”的传统行业场景提供了良好的技术基础，减少了业务方在音频链路上的开发负担。

④ RTMP 推流 + 内置 RTSP 服务的“双通道能力”

除了常见的 RTMP 推流外，SDK 还能在设备上直接启动 RTSP 服务，将终端变成轻量级流媒体节点。

这对需要在局域网或专网内做低延迟屏幕共享的行业十分关键，例如移动巡检、运维终端、可视化工具、内部培训等，部署成本极低。

⑤ 工程细节扎实：线程安全、动态码率、弱网优化

• 读写锁保障推流生命周期安全
• 动态码率估算减少配置门槛
• VBR 与弱网补偿提升网络适应性

这些细节让 SDK 能够在更复杂的环境下长期运行，可用于真正的生产环境，而不仅是概念验证。

八、选型建议：如何验证 SDK 是否适合你的业务？

在实际业务选型中，建议重点关注以下几个方面：

① Android 高版本（12/13/14）的屏幕采集与权限兼容性

高版本系统对 MediaProjection、麦克风权限、前台服务类型都有收紧，对 SDK 的适配能力要求更高。

② 弱网场景的推流表现（RTMP）

不同区域（例如园区 Wi-Fi、办公楼、地铁、室外 5G）网络质量差异巨大， 可以实际测试码率收敛速度、丢包时的画面恢复能力等指标。

③ 局域网多终端拉流时的 RTSP 服务稳定性

如果你的业务在企业内网、专网或封闭环境下运行， 内置 RTSP 服务能大幅简化部署，但也需要测试：

• 多人同时拉流
• 设备性能占用
• 拉流稳定性

④ 音频混音链路在不同机型上的鲁棒性

国内 Android 厂商定制系统繁多， 重点评估：

• 系统音采集是否稳定
• 麦克风 + 系统音是否存在回声或丢帧
• 是否能长期稳定运行

⑤ 最终建议：基于 Demo 做 A/B 测试

你可以直接使用 SDK 自带 Demo，在自己的业务场景中做：

• 分辨率 / 帧率 / 码率 A/B 对比
• 弱网 vs 标准网络对比
• 本地 RTSP 拉流 vs 外网 RTMP 推流对比

与常见的开源方案相比，大牛直播 SDK 在“工程可用性”“长期稳定性”“弱网适应能力”上往往会有更明显的优势。

​