Android 怎么做直播推流：从原理、协议选型到代码实现
内容提要
Android直播推流需明确推流目标、延迟要求和实现方式。技术路线取决于场景：互动直播用WebRTC（<500ms），传统直播用RTMP（1-5秒）。实现方式按成本排序：商业RTC SDK最快，开源库适合学习，自研成本高。完整链路为采集、编码、上行传输、服务器分发、播放。商业SDK（如ZEGO）集成简单，支持CDN转推和屏幕共享，适合产品级应用。
延伸解读
选型先看延迟与场景
文章强调，技术路线首先取决于延迟要求：互动场景（如连麦、PK）需选WebRTC/RTC方案，延迟低于500毫秒；传统直播（如秀场、电商）可接受1-5秒延迟，RTMP仍是主流。形态决定协议，协议又影响服务器选型和代码实现。因此，动手前应明确推流目标、延迟容忍度和观众互动需求，避免盲目选择技术栈。
开源库维护状态是关键
文章提醒，评估开源推流库时，不能只看star数，更要关注最近提交时间和Issues处理速度。音视频库与系统版本深度耦合，长期不更新的库在新机型上可能无法正常工作。例如，librestreaming停更于2020年，仅适合教学参考；而RootEncoder等活跃项目则更适合实际使用。选择时需谨慎考察维护活跃度。
上行带宽决定推流质量
文章指出，推流成败一半看上行带宽。若码率设为1500kbps，上行至少需1.5-2Mbps稳定余量。观众端卡顿，90%的根因在推流端上行或服务器，而非观众手机。因此，推流前应进行上行测速，确保网络条件满足要求，否则即使编码和协议选择正确，也可能因带宽不足导致直播质量下降。
Q&A
Android直播推流有哪些实现方式？
Android直播推流的实现方式按成本排序：商业RTC SDK（如ZEGO）最快上线，适合产品级应用；开源推流库（如RootEncoder）适合学习和原型开发；从零自研（MediaCodec+librtmp）成本高，仅建议作为原理练习。
RTMP和WebRTC在直播推流中如何选择？
选择取决于延迟要求：互动场景（如连麦、PK）需要低延迟，选WebRTC/RTC方案（<500ms）；传统直播（如秀场、电商）可接受1-5秒延迟，选RTMP方案。RTMP仍是手机推流到CDN或平台的事实标准。
Android直播推流需要服务器吗？
需要接收方。可以选择自建服务器（如SRS、MediaMTX、Nginx-RTMP），或使用云直播/CDN服务，或采用商业RTC SDK（如ZEGO）的实时云，此时服务器由厂商提供，无需自己搭建。
如何获取RTMP推流地址和推流码？
获取方式取决于目标：自建服务器可自定义（如rtmp://IP:1935/App/流名）；云厂商在控制台地址生成器生成；公域平台（如抖音、B站）在创建直播场次后下发。推流码等同直播密钥，需保密并定期轮换。
Android屏幕共享推流需要哪些权限和条件？
屏幕共享推流需要用户主动授权（系统弹窗），且依赖前台服务运行。需要声明FOREGROUND_SERVICE权限，targetSdk 34及以上还需FOREGROUND_SERVICE_MEDIA_PROJECTION权限。使用SDK时，可通过setVideoSource和setAudioSource切换采集源。
直播推流延迟一般是多少？如何降低？
RTMP传统直播延迟1-5秒，SRT约1秒，WebRTC/RTC可低至200-500ms。要降低延迟，应选择低延迟协议（如RTC），并检查编码缓冲和CDN分发链路。
如何将直播流推到CDN供大量观众观看？
使用商业RTC SDK（如ZEGO）时，可在推流成功后调用addPublishCdnUrl将流转推到CDN，观众即可通过RTMP或HLS/FLV地址观看。也可使用直推CDN模式（enablePublishDirectToCDN），但两者互斥。
Android直播推流中，推流和拉流有什么区别？
推流是主播端将采集编码后的音视频上传到服务器的过程，依赖上行带宽；拉流是观众端从服务器获取流并播放的过程，依赖下行带宽和服务器分发能力。
