anyRTC Web SDK 是基于 WebRTC 实现音视频通信的，因此依赖于浏览器对 WebRTC 的支持。尽管移动端主流的浏览器都支持 WebRTC，但是由于平台和一些应用内置浏览器的实现各不相同，移动端对音视频编解码的支持情况比较复杂，本文详细介绍移动端各种应用场景下对发送和接收音视频流的支持。
iOS 只支持系统 WebView，因此对 Web SDK 的支持只与 iOS 系统版本有关。
|
浏览器
|
功能
|
H.264
|
|
内嵌 WebView 的应用，微信内置浏览器和Chrome 浏览器
|
收流
|
iOS 12.1.4 及以后版本
|
|
内嵌 WebView 的应用，微信内置浏览器和Chrome 浏览器
|
发流
|
iOS 14.3 及以后版本
|
|
Safari 浏览器
|
收流/发流
|
iOS 11 及以后版本
|
Web SDK 在 iOS 上的已知限制如下：
不支持调用 createScreenVideoTrack 进行屏幕共享。
不支持调用 setBeautyEffect 开启美颜。
不支持 IBufferSourceAudioTrack.seekAudioBuffer 方法。
不支持 setEncoderConfiguration 方法。
不支持获取 encodeDelay。
无法使用 H.264 编码发送 1080p 及以上分辨率的视频流。
在 iOS Safari 上发送小流时，不支持设置 LowStreamParameter.bitrate，且小流分辨率需要与大流分辨率成比例.
切换前置、后置摄像头后采集画面可能会瞬间旋转。
在 iOS 上发送视频流，被系统电话呼叫或其他语音通话和视频通话应用打断后，无法自动恢复视频流的发送，需要重新采集音视频。
在 iOS Safari 上使用 Web SDK，除了上文所列的
Safari 已知限制外
，还存在以下已知限制：
iOS 13 上可能出现远端用户音量随机变化的问题。
语音路由随机切换，即可能出现插着耳机但是仍然从扬声器出声，或者没有耳机却从听筒出声的情况。
不支持 setAudioLevel 方法。
连续两次调用 getUserMedia 获取相同媒体类型的轨道，第一次获取的媒体轨道会静音或黑屏。
Safari 上用户角色从观众切换为主播且获取麦克风权限之后，该用户听远端用户音量会明显变低。
偶现问题：使用过其他使用音视频输入设备的 app 后（例如 Siri 或者 Skype 通话），无法采集本地音频或视频。
偶现问题：音频会话（Audio Session）中断后（包括 mute、unmute、唤醒 Siri、接听电话等），听不到远端用户的声音。
Android
Android 支持自研 WebView 或引入第三方 WebView，不同设备、不同应用的 WebView 可能实现不同，因此对 Web SDK 的支持与应用版本和设备硬件有关。
不支持调用 createScreenVideoTrack 进行屏幕共享。
不支持调用 setBeautyEffect 开启美颜。
不支持 setEncoderConfiguration 方法。
对于 H.264 编解码存在以下限制：
在搭载联发科芯片的设备上无法使用 H.264 编码发送视频流。
在 Android Chrome 88 以下版本，搭载华为海思麒麟芯片的设备无法使用 H.264 编码发送视频流。
使用 H.264 编码发送视频流可能会导致发送视频流码率偏低，无法达到预期码率。
在 Android Chrome 81 以下版本，搭载联发科和华为海思麒麟芯片的设备无法使用 H.264 解码接收视频流。由于 anyRTC Native SDK 发送的视频流均为 H.264 编码，所以如果频道中有发送端使用 anyRTC Native SDK ，在使用华为海思麒麟或联发科芯片的设备上 Web SDK 接收 H.264 流必须使用 Chrome 81 或以上版本。
在 OnePlus 6 的 Android Chrome 上接收远端视频流期间熄灭屏幕，可能会导致视频流冻结。
在 Android Chrome 上无法使用 H.264 编码发送大小流。
在部分 Android 设备上可能无法获取到媒体设备的 device label。
在部分 Android 设备上音视频流被系统电话呼叫或其他语音和视频通话应用打断，可能会导致 track-ended，需要重新采集音视频。
