基于 WebRTC 的实时音视频剧本杀安卓 APP 的项目报告

一、概述

随着移动端的不断发展，由谷歌公司和开放手机联盟领导和开发的安卓系统占据着绝大多数的市场份额，移动端的便捷性使安卓应用软件呈井喷式增长。

WebRTC 被誉为是 Web 长期开源开发的一个新启元，是近年来 Web 开发的最重要创新。WebRTC 允许 Web 开发者在其 Web 应用中添加视频聊天或者点对点数据传输，不需要复杂的代码或者昂贵的配置，目前支持 Chrome、Firefox 和 Opera，相信后续会支持更多的浏览器，目前它有能力支持数十亿的设备在线。然而，WebRTC 一直被误解为仅适合于浏览器。事实上，WebRTC 最重要的一个特征是允许本地和 Web 应用间的互操作，所以我们可以在自己的 Android 应用中植入 WebRTC，使用 WebRTC Initiative 中提供的本地库。

在新冠疫情席卷全球的情况下，很多人出行受限，不仅影响上班上学等公事，也限制了亲朋好友之间的交流聚会，影响亲友同学关系。在这个背景下，我们提出此次选题，计划结合所学知识，将 webrtc 运用在安卓开发上，开发出一款能实时音视频通话的剧本杀 APP，使玩家在家中就可以与朋友来一局悬疑又刺激的剧本杀。

二、需求分析

2.1 业务逻辑

A需要和 B 进行视频通话，现在决定采用 webrtc 协议，实现 p2p 的连接，也就是 A 和 B 之间能直接进行媒体流的传输，不需要外加的媒体服务器进行转发。

在访问外网的时候，需要知道对方的 ip + port，我们才能访问到指点的设备。而 A 和 B 在它们各自的路由局域网内，是不知道这个 ip+port,它们各自的 ip+port 是由路由分配的，这个分配 ip+port,有个专业的名词，就是 NAT,即网络地址转换。A 和 B 之间需要实现 p2p 连接，就需要知道自己本身的 ip+port,然后告诉对方自己的这些信息，这样才能实现互联，这时就要用到 stun 服务器。

A和 B 分别向 stun 服务器发送请求，stun 服务器会返回他们各自的 ip+port，当然并不是所有的情况都能如愿获取到 ip+port 的，NAT 有多种类型，如果路由本身做了限制，通过 stun 服务器是不能返回得到 ip+port 的。这时 A 和 B 之间要进行媒体的交流，就得靠 turn 服务器了，turn 服务器是个中转站，A 和 B 之间通信的所有媒体流，都是经过 turn 服务器进行转发的。那么是采用 stun 还是 turn 服务器，这个会交由 ICE 来帮助我们决策，ICE 是一个框架，主要任务就帮助我们建立双方的连接。

那么通过 stun 服务器，A、B 都知道自己的 ip+prot,那这个信息如何告诉对方呢，这个就是需要通过信令服务器了。A 和 B 之间建立媒体连接，还需要知道对方各自处理流媒体的能力，这个信息也是通过信令服务器来转发的。信令服务器并不需要关心发送的内容，只需要负责信息的转发即可。

2.2 功能性需求

1 玩家可以先选择 app 中预置的剧本，选择好剧本后，创建一个房间，同时生成一个房间号，其他玩家通过该房间号进入游戏，根据剧本的人物限定进入房间的玩家数量，所有玩家都进入并准备后才能开始游戏。

2 玩家协商选择各自角色，选好后玩家会得到各自的剧本，同时昵称都变为相应角色名。

3 游戏按剧本需求设有若干阶段，包括但不限于自我介绍阶段，搜证阶段，提问阶段，二次搜证阶段二次提问阶段，投票阶段。所有玩家都确定后才能进入下一阶段。

4 设有小黑屋功能，在任一阶段玩家都可以请求与某一玩家进行单独通话，若另一玩家同意则两人进入另一房间（小黑屋）。其他玩家仍位于原房间，不受影响。

5 投票阶段，玩家根据自己的推理投票选出凶手，每人一票，非凶手玩家投出凶手则赢，凶手玩家根据被投的票数和此剧本玩家数，可以按情况分为完败（全投中），大败，小败，小胜，大胜，完胜（全未投中）。游戏结束，公布真相。

2.3 数据性需求

考虑到我们需要使用数据库的地方只有存储剧本和用户信息，我们选择 MySQL 作本项目的数据库。MySQL 是一种关系型数据库管理系统，关系数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。MySQL 所使用的 SQL 语言是用于访问的最常用标准化语言，而且其体积小、速度快，关键是，可以是总体成本大大降低。

三、总体架构

3.1 系统架构

我们的总体设计思路是使用 nodejs，socket.io 等技术编写信令服务器，用来交换各个客户端的信息，帮助客户端实现 p2p 连接。在安卓端引入 webrtc 库依赖，，在与信令服务器连接并加入房间后，创建 PeerConnection 对象，交换 SDP，获得可用的 Candidate，建立连接。

3.2 功能架构

为了达到简约、方便的目的，用户不需要登录，进入 APP 后即可开始游戏流程 APP 只记录一些必要的设备信息。用户进入 APP，可以开始选择剧本创建房间或者加入已有房间。待玩家都进入房间后，系统会给玩家发剧本，玩家阅读剧本并且都选择进入下一流程后，进入自我介绍阶段，玩家分别按照剧本简要介绍扮演的角色。下一流程是搜证，玩家自由选择若干证据卡，可以公开或者隐藏某张证据卡。之后进入提问，玩家根据得到的证据或者自身猜想

自由对其他玩家提问，被提问者可以根据需要适当隐瞒。再经过一轮搜证和提问后，进入投票阶段，玩家根据自己的推理投票选出凶手，每人一票，非凶手玩家投出凶手则赢，凶手玩家根据被投的票数和此剧本玩家数，可以按情况分为完败（全投中），大败，小败，小胜，大胜，完胜（全未投中）。游戏结束，公布真相。

3.3 数据架构

我们计划将剧本存储在云端，用户设备信息等存于客户端，用户在安卓端选择剧本后下载到本地。

四、详细设计与实现

4.1 信令服务器

信令服务器的 nodejs 工程中的主要文件是 chat_server.js 和 public/chatroom/。chat_server.js 用来启动信令服务器，同级的 public/chatroom/文件夹是方便测试用的 Web 端。

信令服务器使用到的技术主要是 socket.io，用来与客户端建立连接，监听客户端的消息或者转发消息到其他客户端。自带房间的概念，所以我们只需要简单地调用接口 socket.join(room)，就能使用户加入房间。

我们使用 express 发布测试文件目录

下面是测试过程：

在 a 浏览器登录，发消息

另一个浏览器登录，接收到消息

经测试，服务器能正常接收和转发消息。

4.2 Android 端

首先我们要确定申请的权限：相机，麦克风，网络，我们直接静态权限申请，在项目中的 AndroidManifest.xml 文件里增加相应的权限申请代码。

之后我们要引入两个重要的库依赖：WebRTC 和 Socket.io。直接在 Module 级别的 build.gradle 文件引入，另外还有前面申请权限用到的 EasyPermissions 库

逻辑图：

从图中我们可以知道 WebRTC 中的核心对象 PeerConnection、LocalMediaStream、LocalVideoTrack、LocalAudioTrack 都是通过 WebRTC 创建出来的。在 WebRTC 中使用了大量的设计模式，对于 PeerConnectionFactory 也是如此。它本身就是工厂模式，而这个构造 PeerConnection 等核心对象的工厂又是通过 builder 模式构建出来的。有了 PeerConnectionFactory 对象，我们就可以创建数据源了。

我们将得到的媒体流渲染到页面上，由于模拟器打开不了摄像头，我们将项目打包安装在手机上。可以看到成功渲染。

接下来是连接远端用户，需要创建 PeerConnection。要想从远端获取数据，我们就必须创建 PeerConnection 对象。该对象的用处就是与远端建立联接，并最终为双方通讯提供网络通道。

通过信令服务器，两个客户端之间交换 SDP 描述和 Candidate 等信息，找到连接通道建立 p2p 连接

4.3 搭建 STUN/TURN

在 WebRTC 通讯时，光有信令是远远不够的。因为 WebRTC 真正要传输的是媒体数据，信令只不过是其中的一部分。在 WebRTC 中他会尽可能的通过 P2P 进行数据的传输，但在 P2P 穿越不成功时，就需要用到 STUN/TURN 服务

STUN（Session Traversal Utilities for NAT，NAT 会话穿越应用程序）是一种网络协议，它允许位于 NAT（或多重 NAT）后的客户端找出自己的公网地址，查出自己位于哪种类型的 NAT 之后以及 NAT 为某一个本地端口所绑定的 Internet 端端口。这些信息被用来在两个同时处于 NAT 路由器之后的主机之间创建 UDP 通信。

TURN 的全称为 Traversal Using Relays around NAT，是 STUN/RFC5389 的一个拓展，主要添加了 Relay 功能。如果终端在 NAT 之后，那么在特定的情景下，有可能使得终端无法和其对等端（peer）进行直接的通信，这时就需要公网的服务器作为一个中继，对来往的数据进行转发。这个转发的协议就被定义为 TURN。

我们直接下载 coturn，配置文件/usr/local/coturn/etc/turnserver.conf

配置好后启动服务器，打开，输入 stun/turn 地址、用户和密码后就可以探测 stun/turn 服务是否正常

五、总结

随着网络接入带宽的逐渐改善,许多领域的应用都希望能够嵌入实时通信功能，国内外通信应用都使用私有的通信标准,无法实现跨终端通信,如微信、Skype 等。谷歌开源 WebRT 技术是为了统一互联网通信标准,并解决移动端因硬件资源不足导致的抖动、延时和 CPU 占用率高等问题。

在此次项目中，我们将 WebRTC 技术应用中移动端中，通过基于 nodejs 的信令服务器交换客户端信息，搭建 stun/turn 服务器进行网络穿透和中继转发，是客户端之间建立起 P2P 连接或者 UDP/TCP 连接，开发出一个能实时音视频的剧本杀 app。开发过程十分吃力，因为相对于 app 的搭建，WebRTC 相关知识的学习和使用需要花费更多的时间和精力，而且这部分内容的学习对刚开始接触 WebRTC 的我们来说有很多坑要踩，每一个问题背后都有若干小问题，都要查阅大量的资料来解决。虽然过程艰辛，但也是有收获的。通过学习和实践，我们了解了 WebRTC 的工作过程，学会了使用 stun 和 turn 服务进行网络穿透和中继转发，知道了如何在 Android 端嵌入 WebRTC 服务实现实时音视频，也体会到了短短几天学习新技术并实际应用的艰辛和成功实现 P2P 的兴奋。在此多谢老师的教导和培养，老师的课讲得很好，干货满满，我也会听取老师的建议，凡事早做准备，而不是等下发文件了才开始忙前忙后。