一文带你了解webrtc基本原理（动手实现1v1视频通话）
Posted 王清培
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了一文带你了解webrtc基本原理（动手实现1v1视频通话）相关的知识，希望对你有一定的参考价值。
webrtc (Web Real-Time Communications) 是一个实时通讯技术，也是实时音视频技术的标准和框架。
大白话讲，webrtc是一个集大成的实时音视频技术集，包含了各种客户端api、音视频编/解码lib、流媒体传输协议、回声消除、安全传输等。
对于开发者来说可以借助webrtc非常方便的实现低延时视频通话能力。
现在主流的直播系统、会议系统基本都是基于webrtc来实现。
一、webrtc 三种架构
我们先大概了解下webrtc的几种架构及各自适用场景。
【Mesh】
Mesh架构，需要所有参与连接的peer建立与所有其他peer的媒体连接。
该架构需要n-1个上下行，以此带来的带宽消耗（流量）、编/解码消耗（手机性能）成线性增长。
该架构只能适用3-4个人的小型会议场景。
【MCU】
所有本房间的peer将本地媒体流推到远程媒体服务器，由媒体服务器进行混流，然后再推到所有连接的peer端。
该架构的优点就是只需要1路上下行，随着peer人数不断增加，依然不会对用户造成带宽、手机性能影响。
该架构将压力转嫁到服务端，由专用媒体服务器来完成混流，转推等功能。
【SFU】
相对于MCU来说SFU只做转发，媒体服务器压力有限。与mesh架构相比，只需要n-1个下行，1个上行。
在大规模的场合该架构具有伸缩性。
二、实现 1v1 视频通话
废话不多说，动手实践下。
（麻雀虽小，五脏俱全。通过实现1v1的功能，来整体了解下webrtc协议的原理。）
github：https://github.com/Plen-wang/webrtc-demo-1v1
由于是私有证书问题，chrome会有安全提示。（demo地址暂时还能用 -_- ）
有两个方法可以试下。
第一个方法，手动设置一个类似不安全白名单列表，然后重启浏览器。
chrome://flags/#unsafely-treat-insecure-origin-as-secure
如果不行，我们试下第二个方法肯定可以。
点击空白页输入 thisisunsafe字符。
动手之前，我们先简单了解下webrtc的连接的大致流程和涉及的相关技术点。
【WebRTC P2P】
【NAT穿透】
peer基本都在内网，需要通过nat穿透技术来与peer建立连接。
根据nat的拓扑情况大致分为如下几种：完全锥形、IP锥形、端口锥形、对称形。
stun\\turn协议：stun协议用来拿到peer公网ip，turn用来做relay数据转发。
【SDP】
sdp是会话描述协议。
是媒体协商时使用，用于将本地支持的媒体（编解码等）信息、candidate（连接候选者）信息打包发送到信令服务器。
sdp的交换是通过中间服务器（信令服务器）来完成的。
【ICE】
ICE是一个不断尝试连接的协议，不同的网络情况下ICE大概会尝试如下几种方式来建立通讯通道。
host（peers都在内网）、 srflx（nat穿透）、prflx（nat穿透-Full Cone）、relay（中继）
【服务端】
在整个连接生命周期中都是需要服务端参与。参与webrtc协作的服务端大概分为这几种类型。
stun/turn服务器（p2p穿透）、信令服务器、媒体服务器（媒体信息处理）、业务服务器（可选）
整体流程大致如下。
（上述技术点较多，感兴趣可以自行查询相关资料）
【部署STUN\\TURN服务器】
为了支持1v1公网访问，我们需要搭建一个stun/turn服务器。
这里我们使用 Coturn 开源组件，coturn的镜像有很多，可自行选择。
（注意准备coturn配置文件时，记得设置用户名和密码。）
docker run -d --rm --name turn-server --network=host \\
-v $pwd/turnserver.conf:/etc/coturn/turnserver.conf \\
instrumentisto/coturn
部署好之后可以通过ICE测试工具测试下
https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice
stun:1.15.11.173:3478?transport=tcp
turn:1.15.11.173:3478?transport=tcp:user:pwd
如果正常返回了ICE尝试的连接类型，说明部署没有问题。
【实现信令服务器与客户端代码】
我们采用golang来实现一个简单的信令服务器，使用开源组件go-socket。
同时还需要实现一个web客户端。
demo代码就不贴到文章里了，放在github上。整体代码比较简单，感兴趣可以看下。
git@github.com:Plen-wang/webrtc-demo-1v1.git
【部署信令服务器】
当在本地debug的差不多了，我们把信令服务器打个镜像发到云主机上。
（如果部署本demo，可以直接使用此镜像。）
docker push wangqingpei/rtc-signal-server:latest
docker run --name signal-server -d -p:8080:8080 wangqingpei/rtc-signal-server
【部署web服务器】
部署好信令服务器之后，我们把静态文件放到web服务器里，直接使用nginx镜像部署非常简单。
docker run -d -p 80:80 -p 443:443 --rm --name webrtc-nginx \\
-v /data/rtc-nginx.conf:/etc/nginx/nginx.conf \\
-v /data/pem/server.key:/etc/nginx/server.key \\
-v /data/pem/server.pem:/etc/nginx/server.pem \\
-v /data/rtc-static-file:/usr/share/nginx/html nginx
部署前，记得修改js里的stun服务器地址。
//创建RTCPeerConnection对象
function createRTCPeerConnection()
try
const configuration = 'iceServers': ['urls': 'stun:1.15.11.173:3478?transport=tcp']
rtcConnObject = new RTCPeerConnection(configuration);
rtcConnObject.onicecandidate = handleRtcICECandidate;//ice 交互
rtcConnObject.onaddstream = handleRtcAddStream;//远程stream加入
rtcConnObject.onremovestream = handleRtcRemoveStream;//远程stream移除
rtcConnObject.addStream(localStreamObject);//添加本地stream
console.log("create local RTCPeerConnection object ok.");
catch (e)
console.error("create RTCPeerConnection err.", e);
两边peer就可以借助stun服务器拿到公网ip实现nat穿透。
三、实现MCU/SFU 多人通话
MCU/SFU架构需要 专用媒体服务器 参与。
【媒体服务器选择】
专用媒体服务器有 OWT（open webrtc toolkit）、TWS（Kurento Media Server）等重量级的开源产品。
这两款开源框架都支持MCU、SFU架构功能。
我们选择OWT捣鼓下。
先看下部署起来的效果，默认MCU模式。
红框部分是服务端混流之后的效果。
【部署OWT】
注意，owt-server-4.3镜像与最新版chrome有兼容性问题，会报错 Empty candidate 错误。
我们直接使用5.0的镜像部署。
docker run -d --name owt-demo --network host lmshao/owt-server
由于该镜像是使用默认配置打的，启动后手动进入容器修改下相关配置，换成你云主机的公网ip，然后重启服务。
配置文件路径
vi dist/webrtc_agent/agent.toml
配置项，这里修改成你的公网ip
network_interfaces = [name = "eth0", replaced_ip_address = "1.116.175.232"] # default: []
stun服务器可选
stunport = 3478 #default: 0
stunserver = "1.15.11.173" #default: ""
然后修改下portal.toml文件，文件路径。
vi dist/portal/portal.toml
修改成公网ip
ip_address = "1.116.175.232" #default: ""
重启下相关服务
./bin.restart-all.sh
注意启动日志里有一个id、key，这是用来进入管理页面用的。（没错，owt提供了后台管理页面 -_-）
superServiceId: xxx
superServiceKey: xxx
sampleServiceId: xxx
sampleServiceKey: xxx
默认3004端口下是mcu模式，连线的人多了就会明显卡顿（看服务器配置）。
我们切到SFU模式试下流畅度和服务器负载情况。
通过 ?forward=true 参数控制
https://1.116.175.232:3004/?forward=true
OWT还配有管理后台用于控制媒体服务器的相关参数。
OWT还是比较强大的，有兴趣可以研究研究。
参考资料：
github.com/googollee/go-socket.io
《WebRTC技术详解：从0到1构建多人视频会议系统》
《WebRTC音视频实时互动技术：原理、实战与源码分析》
《FFmpeg 音视频开发基础与实战》
Android Jetpack架构组件一文带你了解Lifecycle（原理篇）
本文首发于微信公众号「后厂村码农」
前言
在上一篇文章中，我们学习了如何去使用Lifecycle，当然之会使用是不够的，还需要了解它的原理，这是成为优秀工程师必备的。这篇文章就来学习Lifecycle的基本原理。
1.Lifecycle的生命周期状态事件和状态
Lifecycle使用两个枚举来跟踪其关联组件的生命周期状态，这两个枚举分别是Event和State。
State指的是Lifecycle的生命周期所处的状态。
Event代表Lifecycle生命周期对应的事件，这些事件会映射到Activity和Fragment中的回调事件中。
Android 9.0的Lifecycle的源码如下所示。
frameworks/support/lifecycle/common/src/main/java/androidx/lifecycle/Lifecycle.java
public abstract class Lifecycle
@MainThread
public abstract void addObserver(@NonNull LifecycleObserver observer);
@MainThread
public abstract void removeObserver(@NonNull LifecycleObserver observer);
@MainThread
@NonNull
public abstract State getCurrentState();
@SuppressWarnings("WeakerAccess")
public enum Event
ON_CREATE,
ON_START,
ON_RESUME,
ON_PAUSE,
ON_STOP,
ON_DESTROY,
ON_ANY
@SuppressWarnings("WeakerAccess")
public enum State
DESTROYED,
INITIALIZED,
CREATED,
STARTED,
RESUMED;
public boolean isAtLeast(@NonNull State state)
return compareTo(state) >= 0;
Lifecycle是一个抽象类，其内部不仅包括了添加和移除观察者的方法，还包括了此前说到的Event和State枚举。可以看到Event中的事件和Activity的生命周期几乎是对应的，除了ON_ANY，它可用于匹配所有事件。
State与Event的关系入下面的时序图所示。
2.Lifecycle如何观察Activity和Fragment的生命周期
在Android Support Library 26.1.0 及其之后的版本，Activity和Fragment已经默认实现了LifecycleOwner接口，LifecycleOwner可以理解为被观察者，那么Lifecycle是如何观察Activity和Fragment的生命周期的呢？
在上一篇文章举的例子中，MainActivity继承了AppCompatActivity，而AppCompatActivity继承了FragmentActivity。在Android 8.0时，FragmentActivity继承自SupportActivity，而在Android 9.0，FragmentActivity继承自ComponentActivity 。SupportActivity和ComponentActivity的代码区别不大，这里以ComponentActivity举例，如下所示。
frameworks/support/compat/src/main/java/androidx/core/app/ComponentActivity.java
@RestrictTo(LIBRARY_GROUP)
public class ComponentActivity extends Activity implements LifecycleOwner
private SimpleArrayMap<Class<? extends ExtraData>, ExtraData> mExtraDataMap =
new SimpleArrayMap<>();
private LifecycleRegistry mLifecycleRegistry = new LifecycleRegistry(this);//1
@RestrictTo(LIBRARY_GROUP)
public void putExtraData(ExtraData extraData)
mExtraDataMap.put(extraData.getClass(), extraData);
@Override
@SuppressWarnings("RestrictedApi")
protected void onCreate(@Nullable Bundle savedInstanceState)
super.onCreate(savedInstanceState);
ReportFragment.injectIfNeededIn(this);//2
@CallSuper
@Override
protected void onSaveInstanceState(Bundle outState)
mLifecycleRegistry.markState(Lifecycle.State.CREATED);//3
super.onSaveInstanceState(outState);
@RestrictTo(LIBRARY_GROUP)
public <T extends ExtraData> T getExtraData(Class<T> extraDataClass)
return (T) mExtraDataMap.get(extraDataClass);
@Override
public Lifecycle getLifecycle()
return mLifecycleRegistry;//4
@RestrictTo(LIBRARY_GROUP)
public static class ExtraData
注释1处创建了LifecycleRegistry，它是Lifecycle的实现类。注释4处实现了LifecycleOwner接口定义的getLifecycle方法，返回了LifecycleRegistry。在注释3处，将Lifecycle的State设置为CREATED。正常来说应该在ComponentActivity的各个生命周期方法中改变Lifecycle的State，显然在ComponentActivity中没有做这些，而是将这个任务交给了ReportFragment，注释2处的将ComponentActivity注入到ReportFragment中。
frameworks/support/lifecycle/runtime/src/main/java/androidx/lifecycle/ReportFragment.java
@RestrictTo(RestrictTo.Scope.LIBRARY_GROUP)
public class ReportFragment extends Fragment
private static final String REPORT_FRAGMENT_TAG = "androidx.lifecycle"
+ ".LifecycleDispatcher.report_fragment_tag";
public static void injectIfNeededIn(Activity activity)
android.app.FragmentManager manager = activity.getFragmentManager();
if (manager.findFragmentByTag(REPORT_FRAGMENT_TAG) == null)
manager.beginTransaction().add(new ReportFragment(), REPORT_FRAGMENT_TAG).commit();
manager.executePendingTransactions();
static ReportFragment get(Activity activity)
return (ReportFragment) activity.getFragmentManager().findFragmentByTag(
REPORT_FRAGMENT_TAG);
...
@Override
public void onActivityCreated(Bundle savedInstanceState)
super.onActivityCreated(savedInstanceState);
dispatchCreate(mProcessListener);
dispatch(Lifecycle.Event.ON_CREATE);
@Override
public void onStart()
super.onStart();
dispatchStart(mProcessListener);
dispatch(Lifecycle.Event.ON_START);//1
@Override
public void onResume()
super.onResume();
dispatchResume(mProcessListener);
dispatch(Lifecycle.Event.ON_RESUME);
...
private void dispatch(Lifecycle.Event event)
Activity activity = getActivity();
if (activity instanceof LifecycleRegistryOwner) //2
((LifecycleRegistryOwner) activity).getLifecycle().handleLifecycleEvent(event);
return;
if (activity instanceof LifecycleOwner) //3
Lifecycle lifecycle = ((LifecycleOwner) activity).getLifecycle();
if (lifecycle instanceof LifecycleRegistry)
((LifecycleRegistry) lifecycle).handleLifecycleEvent(event);
...
ReportFragment的onStart方法中会调用注释1处的dispatch方法。在dispatch方法的注释2处，判断Activity是否实现了LifecycleRegistryOwner接口，LifecycleRegistryOwner继承了LifecycleOwner接口，这两个接口不同的是，LifecycleRegistryOwner定义的getLifecycle方法返回的是LifecycleRegistry类型，而LifecycleOwner定义的getLifecycle方法返回的是Lifecycle类型。注释3处如果Activity实现了LifecycleOwner接口，会调用LifecycleRegistry的handleLifecycleEvent方法。
frameworks/support/lifecycle/runtime/src/main/java/androidx/lifecycle/LifecycleRegistry.java
public void handleLifecycleEvent(@NonNull Lifecycle.Event event)
State next = getStateAfter(event);
moveToState(next);
getStateAfter方法会获取“即将的事件” ：当前事件执行后，即将会处于什么事件，代码如下所示。
static State getStateAfter(Event event)
switch (event)
case ON_CREATE:
case ON_STOP:
return CREATED;
case ON_START:
case ON_PAUSE:
return STARTED;
case ON_RESUME:
return RESUMED;
case ON_DESTROY:
return DESTROYED;
case ON_ANY:
break;
throw new IllegalArgumentException("Unexpected event value " + event);
这个和文章开头给出的State与Event关系的时序图对照看会比较好理解，比如当前执行了ON_CREATE事件或者ON_STOP事件，那么状态就会处于CREATED。回到handleLifecycleEvent方法，其内部还会调用moveToState方法。
private void moveToState(State next)
if (mState == next)
return;
mState = next;
if (mHandlingEvent || mAddingObserverCounter != 0)
mNewEventOccurred = true;
return;
mHandlingEvent = true;
sync();
mHandlingEvent = false;
如果当前所处的状态和即将要处于的状态一样就不做任何操作，sync方法如下所示。
private void sync()
LifecycleOwner lifecycleOwner = mLifecycleOwner.get();
if (lifecycleOwner == null)
Log.w(LOG_TAG, "LifecycleOwner is garbage collected, you shouldn't try dispatch "
+ "new events from it.");
return;
while (!isSynced())
mNewEventOccurred = false;
if (mState.compareTo(mObserverMap.eldest().getValue().mState) < 0)
backwardPass(lifecycleOwner);
Entry<LifecycleObserver, ObserverWithState> newest = mObserverMap.newest();
if (!mNewEventOccurred && newest != null
&& mState.compareTo(newest.getValue().mState) > 0)
forwardPass(lifecycleOwner);
mNewEventOccurred = false;
sync方法中会根据当前状态和mObserverMap中的eldest和newest的状态做对比 ，判断当前状态是向前还是向后，比如由STARTED到RESUMED是状态向前，反过来就是状态向后，这个不要和Activity的生命周期搞混。向前还是向后的代码大同小异，这里以向后为例。
private void forwardPass(LifecycleOwner lifecycleOwner)
Iterator<Entry<LifecycleObserver, ObserverWithState>> ascendingIterator =
mObserverMap.iteratorWithAdditions();
while (ascendingIterator.hasNext() && !mNewEventOccurred)
Entry<LifecycleObserver, ObserverWithState> entry = ascendingIterator.next();
ObserverWithState observer = entry.getValue();//1
while ((observer.mState.compareTo(mState) < 0 && !mNewEventOccurred
&& mObserverMap.contains(entry.getKey())))
pushParentState(observer.mState);
observer.dispatchEvent(lifecycleOwner, upEvent(observer.mState));//2
popParentState();
注释1处的用于获取ObserverWithState，后面会在提到它。
注释2处的upEvent方法会得到当前状态的向前状态。ObserverWithState的dispatchEvent方法如下所示。
frameworks/support/lifecycle/runtime/src/main/java/androidx/lifecycle/LifecycleRegistry.java
static class ObserverWithState
State mState;
GenericLifecycleObserver mLifecycleObserver;
ObserverWithState(LifecycleObserver observer, State initialState)
mLifecycleObserver = Lifecycling.getCallback(observer);//1
mState = initialState;
void dispatchEvent(LifecycleOwner owner, Event event)
State newState = getStateAfter(event);
mState = min(mState, newState);
mLifecycleObserver.onStateChanged(owner, event);
mState = newState;
从名称就可以看出来，它内部包括了State和GenericLifecycleObserver，GenericLifecycleObserver是一个接口，它继承了LifecycleObserver接口。
ReflectiveGenericLifecycleObserver和CompositeGeneratedAdaptersObserver是GenericLifecycleObserver的实现类，这里主要查看ReflectiveGenericLifecycleObserver的onStateChanged方法是如何实现的。
frameworks/support/lifecycle/common/src/main/java/androidx/lifecycle/ReflectiveGenericLifecycleObserver.java
class ReflectiveGenericLifecycleObserver implements GenericLifecycleObserver
private final Object mWrapped;
private final CallbackInfo mInfo;
ReflectiveGenericLifecycleObserver(Object wrapped)
mWrapped = wrapped;
mInfo = ClassesInfoCache.sInstance.getInfo(mWrapped.getClass());
@Override
public void onStateChanged(LifecycleOwner source, Event event)
mInfo.invokeCallbacks(source, event, mWrapped);//1
注释1处会调用CallbackInfo的invokeCallbacks方法，在讲这个方法前，需要先了解CallbackInfo是怎么创建的，是由createInfo方法创建的，如下所示。
private CallbackInfo createInfo(Class klass, @Nullable Method[] declaredMethods)
Class superclass = klass.getSuperclass();
Map<MethodReference, Lifecycle.Event> handlerToEvent = new HashMap<>();
...
Method[] methods = declaredMethods != null ? declaredMethods : getDeclaredMethods(klass);
boolean hasLifecycleMethods = false;
for (Method method : methods)
OnLifecycleEvent annotation = method.getAnnotation(OnLifecycleEvent.class);//1
if (annotation == null)
continue;
hasLifecycleMethods = true;
Class<?>[] params = method.getParameterTypes();
int callType = CALL_TYPE_NO_ARG;
if (params.length > 0)
callType = CALL_TYPE_PROVIDER;
if (!params[0].isAssignableFrom(LifecycleOwner.class))
throw new IllegalArgumentException(
"invalid parameter type. Must be one and instanceof LifecycleOwner");
Lifecycle.Event event = annotation.value();//2
...
MethodReference methodReference = new MethodReference(callType, method);//3
verifyAndPutHandler(handlerToEvent, methodReference, event, klass);//4
CallbackInfo info = new CallbackInfo(handlerToEvent);//5
mCallbackMap.put(klass, info);
mHasLifecycleMethods.put(klass, hasLifecycleMethods);
return info;
关键点在注释1处，不断的遍历各个方法，获取方法上的名为OnLifecycleEvent的注解，这个注解正是实现LifecycleObserver接口时用到的。注释2处获取该注解的值，也就是在@OnLifecycleEvent中定义的事件。注释3处新建了一个MethodReference，其内部包括了使用了该注解的方法。注释4处的verifyAndPutHandler方法用于将MethodReference和对应的Event存在类型为Map<MethodReference, Lifecycle.Event> 的handlerToEvent中。
注释5处新建CallbackInfo，并将handlerToEvent传进去。
接着回头看CallbackInfo的invokeCallbacks方法，代码如下所示。
frameworks/support/lifecycle/common/src/main/java/androidx/lifecycle/ClassesInfoCache.java
static class CallbackInfo
final Map<Lifecycle.Event, List<MethodReference>> mEventToHandlers;
final Map<MethodReference, Lifecycle.Event> mHandlerToEvent;
CallbackInfo(Map<MethodReference, Lifecycle.Event> handlerToEvent)
mHandlerToEvent = handlerToEvent;
mEventToHandlers = new HashMap<>();
for (Map.Entry<MethodReference, Lifecycle.Event> entry : handlerToEvent.entrySet()) //1
Lifecycle.Event event = entry.getValue();
List<MethodReference> methodReferences = mEventToHandlers.get(event);
if (methodReferences == null)
methodReferences = new ArrayList<>();
mEventToHandlers.put(event, methodReferences);
methodReferences.add(entry.getKey());
@SuppressWarnings("ConstantConditions")
void invokeCallbacks(LifecycleOwner source, Lifecycle.Event event, Object target)
invokeMethodsForEvent(mEventToHandlers.get(event), source, event, target);//2
invokeMethodsForEvent(mEventToHandlers.get(Lifecycle.Event.ON_ANY), source, event,
target);
private static void invokeMethodsForEvent(List<MethodReference> handlers,
LifecycleOwner source, Lifecycle.Event event, Object mWrapped)
if (handlers != null)
for (int i = handlers.size() - 1; i >= 0; i--)
handlers.get(i).invokeCallback(source, event, mWrapped);//1
注释1处的循环的意义在于将handlerToEvent进行数据类型转换，转化为一个HashMap，key的值为事件，value的值为MethodReference。注释2处的invokeMethodsForEvent方法会传入mEventToHandlers.get(event)，也就是事件对应的MethodReference的集合。invokeMethodsForEvent方法中会遍历MethodReference的集合，调用MethodReference的invokeCallback方法。
Android Jetpack架构组件一文带你了解Lifecycle（原理篇）
Android Jetpack架构组件一文带你了解ViewModel的使用和原理
『Python开发实战菜鸟教程』实战篇：一文带你了解人脸识别应用原理及手把手教学实现自己的人脸识别项目