短视频直播SDK的直播推流失败的常见原因排查
做过直播开发的朋友应该都有过这样的经历：信心满满地接完SDK，测试推流的时候却发现画面一动不动，或者报出一个看不懂的错误码。这种感觉说实话挺让人沮丧的，尤其是当你不知道问题出在哪里的时候。我自己也踩过不少坑，所以今天想把一些常见的推流失败原因整理出来，跟大家聊聊怎么一步步排查。
这篇文章不会讲太理论的东西，更多是从实操角度出发，看看哪些环节容易出问题，以及对应的解决思路。话不多说，我们直接进入正题。
一、网络问题：最容易忽视也最常见
说真的，在我接触到的推流失败案例里，网络问题至少占了六成以上。但有意思的是，很多开发者第一反应会觉得是SDK本身的问题，反而把网络这个最基础的因素忽略了。
1.1 网络连接状态
首先要确认设备有没有真正的网络连接。有些时候Wi-Fi图标显示是满的，但其实网络根本不通。最好的办法是在推流前先做一些网络检测，比如尝试访问一下外网，或者用代码检测socket能否正常建立连接。
移动端还需要特别注意网络切换的场景。比如用户从Wi-Fi切到4G，或者从4G切到Wi-Fi，这种时候如果你的推流没有做好断线重连，就会出现推流失败。另外，有些地区运营商网络会有QoS限流，导致推流报文被丢弃，这个靠普通的网络检测不太容易发现。
1.2 带宽不足
带宽这个问题有点复杂，因为它不是简单的"够不够"，而是一个动态变化的东西。推流需要稳定的上行带宽，而很多家用宽带的上行带宽本来就被限制了。比如你用的是50兆宽带，上行可能只有5兆甚至更少，这时候推高清流肯定会有问题。
怎么判断是不是带宽的问题？一个比较实用的方法是在推流前做一个带宽探测。现在主流的SDK都会内置带宽探测功能，它会试着推一小段数据，然后根据成功率反推可用带宽。如果发现可用带宽低于推流所需带宽，这时候就应该降低码率或者分辨率，而不是强行推流。
还有一个容易被忽视的点是无线路由器的性能。我见过很多情况，路由器本身处理能力不行，同时连接太多设备的时候，无线信号虽然满格，但数据转发就是会丢包。这种问题，换个位置或者重启一下路由器可能就解决了。
1.3 DNS解析问题
DNS这个问题说出来感觉有点古老，但它确实还会发生。特别是某些地区性的DNS服务器，会出现解析延迟或者解析失败的情况。当DNS解析失败时，推流地址就无法转换成实际的服务器IP，自然就会推流失败。
解决方案有几个层面。第一个层面是在应用里做一个DNS预解析，在正式推流前先把域名解析成IP，然后直接用IP来推流。第二个层面是准备多个备用的推流地址，当主地址解析失败时可以自动切换。第三个层面可以考虑使用HTTPDNS服务，这种服务比传统的UDP DNS更稳定，解析速度也更快。
二、编码配置问题：参数不对努力白费
编码这块水比较深，很多问题都是因为编码参数配置不当导致的。我分几个方面来说说。
2.1 编码器选择与支持
主流的编码器有H.264和H.265两种。H.264的兼容性是最好的，几乎所有设备和浏览器都支持。H.265压缩效率更高，但并不是所有设备都支持硬编码，有些设备只能软编码H.265，而软编码又特别吃CPU，容易导致发热和卡顿。
所以在选择编码器的时候，不能只看压缩效率，还要看目标设备的支持情况。一个比较稳妥的做法是默认使用H.264，如果设备支持H.265硬编码再切换过去。现在很多SDK都有自动检测能力，会根据设备特性选择合适的编码器。
2.2 码率设置不合理
码率设置是个技术活。码率太低画面质量差，码率太高又可能推不上去而且还费流量。关键是码率还要跟分辨率和帧率配套。
| 分辨率 | 帧率 | 建议码率范围 |
| 720p | 15fps | 800kbps - 1500kbps |
| 720p | 30fps | 1500kbps - 2500kbps |
| 1080p | 30fps | 2500kbps - 4500kbps |
这只是参考值，实际使用中还要根据内容类型来调整。比如游戏直播画面变化快，需要更高的码率来保证清晰度；而静态场景多的直播，码率可以适当降低。
另外有个概念叫CBR（固定码率）和VBR（可变码率）。推流场景建议用CBR，因为网络传输需要稳定的码流，VBR虽然平均码率更低，但峰值可能很高，容易导致网络拥塞。
2.3 分辨率与编码不匹配
有时候你会遇到这样的情况：推流参数都设置了，但画面要么是黑屏要么是拉伸变形。这往往是分辨率设置和编码器预期不匹配导致的。
举个常见的例子：有些摄像头的原始分辨率是1280x720，但如果你设置的推流分辨率是1920x1080，编码器就会尝试拉伸画面，结果就是画面模糊或者变形。反过来，如果原始分辨率是4K，你设置720p推流，虽然能推，但画面质量就浪费了。
所以在设置分辨率之前，最好先获取一下摄像头或者屏幕采集的实际分辨率，然后选择一个与之成比例的目标分辨率。
2.4 GOP设置问题
GOP（Group of Pictures）就是两个关键帧之间的间隔帧数。这个参数影响的是延迟和视频Seek的效率。GOP设置得越大，视频压缩率越高，但延迟也越大；GOP设置得小，延迟低，但码率会上去。
推流场景建议把GOP设置成帧率的2到4倍。比如30fps的直播，GOP设置成60到120是比较合理的。如果GOP设置得特别大，比如设置成300，那每次推流开始的时候都需要等很久才能看到画面，因为要等第一个关键帧出来。
三、推流地址问题：一毛钱关系都没有
推流地址的问题听起来简单，但实际排查起来还挺费劲的。我见过各种奇葩的地址问题，有些说出来你都不信。
3.1 地址格式错误
推流地址是有一定格式要求的，常见的是RTMP地址，格式大概是rtmp://host:port/app/stream。如果这个地址哪里写错了，比如端口号写错、streamKey拼错了、或者多了个空格，都会导致推流失败。
特别要注意的是，有些开发者喜欢把地址和key分开配置，然后在程序里拼接。这种时候拼接的逻辑一定要检查清楚，特别是在key里包含特殊字符的时候，可能需要URL编码。
3.2 地址过期或失效
很多直播平台为了安全，推流地址都是有时效性的。比如生成之后5分钟内有效，或者只能用一次。如果你生成的地址放了很久才用，那肯定就过期了。
还有一些情况是地址被复用了。比如同一个streamKey同时在两个地方推流，后推的那个就会失败。这种情况在多人协作开发的时候特别容易出现，大家都在测试，结果互相挤掉了。
3.3 鉴权参数错误
现在的直播服务一般都会有鉴权机制，推流地址里会包含鉴权参数，比如token、sign什么的。如果这些参数生成逻辑有问题，或者服务器端配置有问题，鉴权就会失败，推流也就失败了。
鉴权失败有个特点，就是网络层面看起来是连上了，但服务器很快就把连接断掉了。这种情况抓包看的话，能看到TCP连接建立了，但很快收到RST报文。遇到这种问题，重点检查鉴权参数的生成逻辑和有效期。
四、设备性能问题：硬件瓶颈
直播是个比较重的工作，对设备的CPU、内存、GPU都有一定要求。如果设备性能不够，推流就会出问题。
4.1 CPU性能不足
视频编码是非常消耗CPU的。特别是用软编码的时候，CPU占用率可能飙升到90%以上。如果这时候还有其他任务在跑，比如后台在下载东西，CPU就会成为瓶颈，导致编码不及时，进而造成帧丢失或者卡顿。
判断是不是CPU问题，可以打开系统监视器看看CPU使用率。如果编码的时候CPU长期跑满，那基本上就是这个原因了。解决思路有几个：使用硬编码代替软编码、降低分辨率或帧率、关闭其他后台任务。
4.2 内存不足
内存不足导致的问题可能比较隐蔽。有时候内存不够并不会直接崩溃，而是表现为各种诡异的问题，比如推流突然中断、图像出现马赛克、或者应用闪退。
移动端的内存管理比较激进，当系统内存紧张的时候，会优先回收后台应用。如果你发现推流经常在后台切到前台的时候失败，可能就是内存被系统回收了。这种情况要检查代码里有没有内存泄漏，必要时主动释放一些不必要的缓存。
4.3 设备发热
设备发热会导致降频，这个很多人可能没意识到。当手机温度太高的时候，系统会自动降频来保护硬件，降频后CPU性能下降，编码就跟不上了。
发热问题在夏天特别明显，如果你在户外做直播，或者边充电边直播，设备温度很容易上去。好的做法是在推流前让设备先冷却一下，必要时可以用散热背夹。
五、SDK集成问题：细节决定成败
SDK集成是个技术活，有时候一个小细节没注意到，就会导致推流失败。我整理了几个常见的集成问题。
5.1 权限没有正确配置
Android和iOS都需要申请一堆权限，摄像头、麦克风、网络访问，这些少一个都不行。特别是Android 6.0以后，权限变成了动态申请，有些开发者只写了权限声明，但没做运行时权限请求，结果用户拒绝了权限，SDK就无法工作。
iOS还有个比较坑的是需要在info.plist里添加权限描述文案，如果不加，系统直接就拒了访问。这个问题调试的时候不太容易发现，因为不会有明确的错误提示，就是摄像头打不开。
5.2 版本兼容问题
SDK版本和系统版本不兼容也是常见问题。比如某个SDK版本只支持iOS 12以上，但你跑在iOS 11上，就可能会有各种奇怪的问题。或者Android SDK的某些API在高版本系统上行为有变化，如果没做好版本适配，就会出错。
所以在集成SDK之前，一定要仔细看兼容性说明，确认SDK支持的最低系统版本。如果你的应用要支持比较老的系统版本，最好选一个兼容面更广的SDK版本。
5.3 初始化顺序问题
SDK一般都需要初始化，而且初始化往往有一些前置条件。比如有的SDK要求先初始化日志系统，再初始化核心模块；有的要求在 Application 的 onCreate 里初始化，而不是某个Activity里。
如果初始化顺序不对，SDK可能处于一个不一致的状态，推流的时候就会失败。这种问题比较难排查，因为错误信息往往不明显。建议的做法是严格按照文档里的初始化流程来写，不要随意调整顺序。
5.4 资源没有正确释放
推流结束后需要正确释放资源，包括关闭编码器、断开网络连接、释放摄像头等。如果没释放或者释放顺序错了，下次推流的时候就可能出现异常。
最常见的问题是多次初始化没有完全释放，导致资源泄漏。比如连续推流几次之后，内存越来越来大，最后崩溃。好的做法是封装一个推流管理器，统一管理推流的生命周期，确保每次推流都properly cleanup。
六、异常处理与日志分析
说完了常见问题，最后聊聊怎么系统地排查和定位问题。
6.1 建立完善的日志体系
日志是排查问题的第一步。建议在关键节点都打上日志，比如开始推流、连接服务器、开始编码、收到第一帧、发生错误等。日志级别要分明，正常情况下只打INFO，调试的时候打DEBUG，错误的时候打ERROR。
重要的是日志要包含足够的信息，比如推流地址、错误码、时间戳、设备信息等。光打一个"推流失败"是没法定位问题的，至少要打出具体的错误码和错误描述。
6.2 收集设备与网络信息
当推流失败的时候，可以收集一些辅助信息帮助排查，比如设备型号、系统版本、CPU架构、内存大小、网络类型、IP地址等。这些信息可能跟问题本身没有直接关系，但可以帮助缩小问题范围。
比如你发现所有某款特定型号的手机都推流失败，那可能就是这个型号的兼容性问题；如果某个特定网络环境下都失败，那就是网络层面的问题。
6.3 逐步排除法
如果还是定位不到问题，可以用逐步排除法。把推流过程拆分成几个阶段：采集、编码、网络传输、服务器接收。每个阶段都加个标记，看看问题出在哪个阶段。
比如先用本地录制功能测试采集和编码是否正常，确认这两步没问题；然后用本地rtmp服务器测试推流链路是否通畅；最后再用真正的推流地址测试。这样一步步排查，很快就能定位到问题环节。
写在最后
推流失败的原因确实挺多的，但只要掌握了排查方法，一个一个排除，总能找到问题所在。重要的是保持耐心，不要拿到错误信息就慌了神。
如果你用的声网的实时音视频云服务，他们的技术文档和SDK文档都写得挺详细的，出了问题可以先翻翻文档。他们在全球音视频通信这块积累很深，针对各种网络环境和设备都有优化，遇到难解决的问题也可以找技术支持帮忙看看。
直播这条路不好走，但只要基础扎实了，后面的事情就会顺利很多。希望这篇文章能对你有所帮助，祝开发顺利。
