Android WEBRTC开发总结2-尝点甜头

真是痛苦，上次写完博客，上传文件时居然把网页关闭了，真是够了，好几天都不想再写 博客了，但是想了想，还是认真写完吧，做事不能半途而废，算了，闲话就是或这么多，下面开始今天的博客内容。

相信不少人看完上一篇博客，对WEBRTC移动端的开发估计都丧失了信心吧。哈哈，诚然，移动端的WEBRTC开发确实存在一定的难度，没有一定的技术基础和一个好的团队一起学习，个人进步太慢了，而且也难以有进展。我当时就是这样的状态了，做了很长一端时间也不知道WEBRTC到底要怎么做，只是测试下别人的DEMO罢，不知从何处下手。今天我们先来尝点WEBRTC的甜头，既然WEBRCT移动端这么难开发，那么浏览器端呢，该不会也这么复杂吧，好歹叫WEBRTC，针对网页开发对广大开发人员来说应该不会难吧，对，没错。网页版的WEBRTC开发确实比较简单，只需要掌握几个接口，有创意加上良好的开发能力 的话，可以开发出不错的应用来。那下面我们开始正式开发WEBRTC网页版DEMO了。开发测试WEBRTC网页版时我们首先要选对浏览器，别说我没提醒你们，目前支持的比较好的有三款 Chorme浏览器 Firefox Opera,貌似微软对WEBRTC开发也很支持的，说是IE也要支持，但是风声大，雨点小，至今我也没看到支持EBRTC的中文IE浏览器。对了，还有一句话，大家测试的时候，为了保证良好的测试效果和效率，测试的机器上最好装同一款浏览器测试，别问我怎么知道的，你自己做时就自然明白了，后期测试优化时，自己再换各种浏览器测试即可。开发WEBRTC网页版，我们首先来了解WEBRTC网页版开发的三个重要的接口：

MediaStream     RTCPeerConnection     RTCDataChannel

下面来对三个接口来个简单的解释：

MediaStream:获取本地媒体流，也就是音视频流，各个浏览器对这个接口的名称都同，但是参数都是一样的，参数填写正确就可以了

RTCPeerConnection:用于浏览器之间建立连接和音视频媒体流的传输

RTCDataChannel ：用于用户在浏览器之间传递各种自定义数据，和QQ一样，大家可以相互发送消息问题图片等

WEBRTC的核心就在于在浏览器之间建立点对点的之间通信，音视频媒体流直接在浏览器之间传递，而不需要服务器中转转发，也就是P2P。这就需要 通信双方需要知道相互的外网IP地址和端口。但是目前绝大部分的PC都是在NAT之后的，只有少数电脑才有外网地址，这就需要有一种技术来帮助获取外部地址和端口号，也就是NAT穿越，TURN STUN就是这样的技术，但是由于存在缺陷，后期又出现了ICE的综合解决方案，关于ICE到底是什么，今天就不解释了，后面会有文章来详细介绍。大家感兴趣的可以自行百度 。关于TURN STUN服务的搭建我这里也不赘述了，大家搭建官网的TURN服务器就可以了，TURN包含的STUN的功能，搭建方法网上一搜一大把，大家自行大家，搭建遇到了问题的可以私信我，我尽力为大家解答。

下面我们再来学习一下WEBRTC的信令过程，WEBRTC支持点对的点的通话，但是我们还是需要信令服务器，因为我们要找到对方，获取对方的音视频和网络配置，所以信令服务器必不可少，WEBRTC官方为了避免重复定义，而且WEBRTC核心就在音视频处理上，所以没有提供信令，需要我们自行搭建，关于信令服务器搭建和代码编写，这里也不赘述了，后面会有上传的代码，大家看看就明白了解了。现在我们来看看信令过程到底是如何建立的？

WEBRTC信令建立（这里我们假设有A B用户通信）：

1.首先A通过RTCPeerConnection的createOffer收集自己的音视频信息，通过setLocationDescription来设置本地音视频信息，然后通过信令服务器将这些信息发送给出去

2.B接收到A的信息，通过RTCPeerConnection的setRemoteDescription方法来保存对方的音视频信息，然后通过createAnswer方法来手机自己音视频信息，通过信令服务器发送出去

3.A收到B的信息，通过setRemoteDescription信息设置保存B的音视频信息，到此，音视频信息设置交换完成

下面是关于A和B的网络信息Candidate的交换设置过程，和音视频交换设置过程相同，这里不再解释，到这里才真正开始P2P的连接，一旦P2P的连接建立完成。A和B就可以进行P2P的音视频通话了，不做这里的P2P也不是一定成功的俄，没有成功的话，还是会转发音视频的。

参考的代码大家自行下载测试