互联网中间件
域名与网站
开发者工具
人工智能（AI）
大数据基础服务
大数据可视化服务
大数据应用服务
行业解决方案
大数据与AI解决方案
安全与运维解决方案
微信解决方案
资源与工具
资源与工具
合作与生态
小程序音视频解读
小程序音视频解读
世界上杀伤力最大的武器不是核弹，而是AK-47，这款由卡拉什尼科夫所设计的突击步枪，全世界一共生产了约一亿支。它具有不俗的杀伤力和极为优秀的可靠性。从不卡壳，不易损坏，不管是沙漠还是雨林，都能稳定地倾泻火力。并且操作非常简单，以至于很多非洲兄弟在射击时会将其举过头顶，因为他们相信这种动动手指就能摧毁对方的武器，完全是“白人的巫术”。
抱着同样的想法，我们跟微信团队一起，致力于在小程序上打造出一款效果出色、稳定可靠并且简单易用的音视频组件。本文接下来的部分，我希望能用简单的文字，让您了解那些界面丰富且体验优异的音视频功能背后的故事。
&分子由原子组成&无论多么复杂的音视频功能，我们都可以将其拆解为两个基本“原子”的组合，一个是音视频上行，一个是音视频下行。
音视频上行音视频上行，就是把自己的声音和画面传送出去。只有这样，别人才能看到您的影像，听到您的声音：
采集预处理最开始，我们要对摄像头的画面进行捕获，对麦克风的声音进行采集。但是，原生采集和捕获的画面和声音是需要进行预处理的，直接采集的画面可能有很多噪点，所以我们要进行图像降噪； 100% 还原真实的皮肤可能并不符合人们的预期，所以我们需要进行磨皮和美颜；直接采集的声音可能也有很多的环境噪音，所以我们需要进行前景和后景音的分离然后进行底噪抑制。
经过预处理之后的画面和声音相比于原始采集的一般会有较大改善，因为所有的预处理都是以“讨好”人类的视听体验为目的，所以这一看似不起眼的部分会吸引很多公司在其上做不少的技术投入。举个身边的例子，以 LCD 平板电视为例，SONY虽然没有自家的液晶面板（以台湾和大陆液晶面板为主），却能在总体效果上一直领先其它公司，其背后的秘密就是在图像处理（基于图像数据库做超分辨率显示）和背光技术（所有动物的眼睛都是对亮度最为敏感）上的不间断的积累和投入。
编码和发送画面和声音都经过“粉饰”之后，就可以送给编码器进行编码压缩了。编码器的工作是将一张张的画面和一段段的声音压缩成 0101001... 的二进制数据，而压缩后的体积要远小于压缩前。最后要做的工作就是将编码后的数据通过网络模块发送出去。在在线直播场景中，一般采用的网络协议都是基于TCP的，而在实时通话场景中，所采用的网络协议则是 UDP 为主。
&live-pusher&小程序在新版本中加入了
标签用于实现音视频上行， 它支持两种模式：直播（标清-SD、高清-HD、超清-FHD） 和 RTC，前者用于直播推流，后者则用于实时音视频通话。
&live-pusher& 的 Live 模式即 TXLivePusher::setVideoQuality 中的前三个档位之一。&live-pusher& 的 RTC 模式即 TXLivePusher::setVideoQuality 中的 REALTIME_VIDEOCHAT。
min-bitrate
max-bitrate
audio-quality
窄带场景，比如户外或者网络不稳定的情况下适用
目前主流的APP所采用的参数设定，普通直播场景推荐使用这一档
对清晰度要求比较苛刻的场景，普通手机观看使用 HD 即可
视频客服（用户）
这是一种声音为主，画面为辅的场景，所以画质不要设置的太高
车险定损（车主）
由于可能要看车况详情，画质上限会设置的高一些
多人会议（主讲）
主讲人画质可以适当高一些，参与的质量可以设置的低一些
多人会议（参与）
作为会议参与者，不需要太高的画质和音质，audio-quality 的 low 模式，其音质和延迟感都要会比 high 模式差很多
音视频下行也叫播放（play），即从云端拉取编码后的音视频数据流进行解码和播放：
抖动缓冲（jitterbuffer）网络不是完美的，所以网速会有波动，如果服务器来一段数据就播一段数据，那么网络稍微一波动，画面和声音就会表现出卡顿。抖动缓冲技术，就像是为网络过来的数据准备一个小的蓄水池，音视频数据先在这里暂存一小会儿再送去播放，这样就可以在网络不稳定时有一定的“应急”数据可以使用。
解码和播放解码就是把压缩后的音视频数据还原成图像和声音，然后进行渲染和播放。我们采用了 openGL 进行画面的渲染，使用 iOS 和 Android 的系统接口来播放声音。
有人经常问我：“在播放器端怎么改变画面的清晰度？” 这个问题回答起来既简单又复杂。简单回答是说播放器并不能改变画面的清晰度，清晰度在视频编码之后就确定了。复杂的回答则是，通过跟云端的配合，确实可以在播放器上改变清晰度。因为腾讯云的每一条直播流都支持多分辨率实时转码，开启这个功能后，就可以在播放器上根据用户的选择播放不同的 url，进而实现不同清晰度的切换。
&live-player&小程序在新版本中加入了
标签用于实现音视频下行， 它支持两种模式：live 和 RTC，前者用于直播播放，后者则用于实时音视频通话。
&live-player& 的 Live 模式即 TXLivePlayer::startPlay 中的 LIVE_RTMP 或 LIVE_FLV。&live-player& 的 RTC 模式即 TXLivePlayer::startPlay 中的 PLAY_TYPE_LIVE_RTMP_ACC。
有了简单的“原子”，我们就可以进行初步的化学反应，从简单到复杂地构建出一些“分子”结构，接下来，我们先从一个最简单的应用场景开始 —— 单向音视频。
单向音视频：在线培训
技术解读在线培训是一个非常经典的单向音视频场景，您只需要简单的将负责音视频上行的 &live-pusher& 和负责音视频下行 的 &live-player& 组合在一起即可。
&live-pusher& 能够将讲师的影像和声音推送到云端（一般也可以使用专业的采集设备），腾讯云本身就相当于一个 信号放大器，它负责将一路音视频流扩散到位于全国各地的 CDN 机房，如此一来，观众端的 A B C 都可以在离自己最近的云服务器上，使用
&live-player& 拉取到稳定和流畅的音视频流。
由于原理简单、易于维护且支持几百万同时在线的高并发观看，所以从在线教育到体育赛事，从游戏直播到花椒映客，都是基于这种技术实现的。
在讲师端创建一个 &live-pusher& 标签，并将 mode 设置为 HD，技术参考文档见 。
学员一端的小程序只需要创建一个 &live-player& 标签，并将 mode 设置为 live 即可，技术参考文档见 。
但这种技术有个严重的缺陷，就是单向延时无法控制在 1s 以内，一般都是在 2秒-5秒 左右，甚至更长，那么在一些对时延要求很苛刻的场景下就不再适用了，比如下面这个场景：
单向低延时：在线电玩
技术解读在线夹娃娃在今年特别流行，玩家可以远程控制抓钩来抓娃娃，所以需要将单向延时控制在 500ms 以内，而且越低越好。要达到这么低的要求，普通的直播技术就不行了，我们需要新引入两个新的科技点：延时控制 和 UDP加速。
延时控制网络不是完美的，网络是波动的。在有波动的网络下，服务器上的音视频数据并不是稳稳的来到您的手机上，而是忽快忽慢。慢的时候您可能会看到卡顿，快的时候就会产生堆积，而堆积的后果就是延时的增加。所以，我们需要采用延迟控制技术，它的原理很简单，当网络慢的时候就播的慢一点，当网络快的时候就播得快一点，这样就起到一定的缓冲作用。当然，真正实现时就会发现，声音是个很不听话的“孩子”，要处理好声音的效果是一个非常高难度的技术活。
UDP加速既然网络不那么完美，总是时快时慢，那我们是不是可以改善一下呢？在经典的单向音视频方案中，一般采用的都是 TCP 协议，因为它简单可靠且兼容性极好。然而 TCP 天然就有时快时慢的坏毛病，所以我们需要用 UDP 协议替代之，相比于设计目标定位于可靠传输的 TCP 协议，自定义协议栈的 UDP 可以做得更稳且更快。
现在我们已经拥有了两个新的科技点，接下来就把它用到我们的小程序中：
玩家创建一个 &live-player& 标签，并将其 mode 设置为 RTC，此时小程序会开启延时控制 和 UDP加速，同时，src 要使用 rtmp:// 协议的播放地址，并且要为播放地址添加防盗链签名。技术参考文档见 。
观众也是要创建一个 &live-player& 标签，并将其 mode 设置为 live，此时 src 指定普通的 flv 协议播放地址就可以了，技术参考文档见 。
双向音视频：车险定损
技术解读有了单向低延时技术，那么双向视频通话自然也就比较简单了，只需要通话的双方 A 和 B 各自拉通一路低延时链路就可以了。
虽然思路正确，但实现上不是那么简单的，因为我们还需要引入额外的几个科技点：
回音消除在双向视频通话中，用户自己手机的麦克风会把喇叭里播放的声音再次记录下来，如果不将其抹除掉，这些声音会被反送给对端的用户，从而形成回声。
噪声抑制噪声抑制的目的是将用户所处环境里的背景噪音去除掉，好的噪声抑制是回音消除的前提，否则声学模块无法从采集的声音辨别出哪些是回声，哪些是应该被保留的声音。
Qos流控网络不可能一直都很完美，尤其是中国大陆地区的上行网速一直都有政策限制。Qos流控的作用就是预测用户当前的上行网速，并估算出一个适当的数值反馈给编码器，这样一来，编码器要送出的音视频数据就不会超过当前网络的传输能力，从而减少卡顿的发生。
丢包恢复再好的网络也难免会有丢包的情况，尤其是 WiFi 和 4G 等无线网络，由于传输介质本身就不是可以独享的，所以一旦受到干扰，或者高速运动都会产生大量的丢包，这时就需要引入一些丢包恢复技术，将失去的数据尽量补救回来。
现在我们又获得了四个新的科技点，接下来我们把它用到我们的小程序中：
A 创建一个 &live-pusher& 标签，mode 设置为 RTC，并将对应的低延时播放地址 urlA 交给 B。
B 创建一个 &live-player& 标签，mode 设置为 RTC，src 指定为 urlA。
B 创建一个 &live-pusher& 标签，mode 设置为 RTC，并将对应的低延时播放地址 urlB 交给 A。
A 创建一个 &live-player& 标签，mode 设置为 RTC，src 指定为 urlB。
此处所需的技术参考文档见 。
多人音视频：视频会议
技术解读既然双人视频通话已经搞定了，是不是多人也就照葫芦画瓢就可以了？您看，我们只需要将 A 和 B 之间的 url 置换，变成 A、B、C 甚至更多人之间的 url 置换，不就可以了吗？
虽然思路正确，但是真正要将功能做到商用级别，仅依靠简单的 url 交换是非常粗糙的，我们需要继续引入额外的两个科技点：
房间管理以上图所示的 A B C 之间的多人视频场景为例，要让每一个人都很清楚其它人的状态（比如低延时播放url，以及当前是否有上行等等），这个事情可是非常困难的，搞不好就容易出现各方信息不对齐。对于更复杂一点的情况，比如当有第四个人 D 进来的时候，或者第五个人 E 进来又出去的时候，这种信息同步几乎就是一场噩梦。
最好的办法就是把参会人的状态和信息都收拢在服务器端，构造一个 房间 的概念，这样就可以确保参会人都能从服务端获得同样的信息，而不需要各自去维护。
IM 系统当有新的参与者进入房间，或者有人离开时，就需要对房间里的人进行信息广播，这就需要一个不错的 IM 系统负责收发消息。比如当 D 进入时，就可以向房间内的其它成员广播这个 “I'm coming” 的事件，这样 A B C 就可以在自己的 UI 上展示 D 的视频画面了。
现在我们又获得了两个新的科技点，接下来我们把它用到我们的小程序中：
对接步骤跟之前几个科技点不同，小程序并没有默认提供房间管理和 IM 系统的微信内实现，因为房间管理跟客户业务耦合太紧密，腾讯云通讯 IM 服务也已经有了小程序端的 javascript 组件。
所以我们提供了一个叫做 RTCRoom 的 javascript 组件用于降低这里的实现复杂度，您可以在我们的
中找到 rtcroom.js。
会议发起者 A 可以用 rtcroom.createRoom 创建一个房间。
参会者 B 和 C 可以用 rtcroom.enterRoom 加入一个房间。
这期间，A B C 都可以通过 onMemberEnter 和 onMemberLeave 了解房间内参会者的进进出出。
如果参会者 B 和 C 想要离开，只需要用 rtcroom.leaveRoom 通知其他人即可。
会议发起者 A 可以随时用 rtcroom.destoryRoom 将当前的房间解散掉。
此处所需的技术参考文档见 。
以上信息是否解决您的问题？
提交成功！非常感谢您的反馈，我们会继续努力做到更好！
为了我们更有效的优化资料库，以及针对性的改善我们的服务，我们很需要您进一步的反馈信息：
页面内容不全面，不深入
页面内容更新不及时
描述不够清晰，比较混乱
系统或功能太复杂，同时文档也缺乏足够的引导
移动直播 相关文档腾讯云移动直播哪里买比较划算_百度知道
腾讯云移动直播哪里买比较划算
腾讯云移动直播哪里买比较划算选择哪种付费方式好呢
我有更好的答案
就是找腾讯云蓝色航线,划算
采纳率：75%
为您推荐：
您可能关注的内容
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。互联网中间件
域名与网站
开发者工具
人工智能（AI）
大数据基础服务
大数据可视化服务
大数据应用服务
行业解决方案
大数据与AI解决方案
安全与运维解决方案
微信解决方案
资源与工具
资源与工具
合作与生态
如何搭建聊天室？
如何搭建聊天室？
本文介绍如何使用
服务构建一些简单的聊天室功能：（1）群发普通文本消息（2）群发弹幕消息（3）群发点赞消息（4）群发系统通知，比如“XXX已加入房间”或者“主播已离开”等等。
1. 开通服务在使用腾讯云通讯服务之前，首先要将这个服务开通，可以按照如下步骤操作：
进入，如果还没有服务，直接点击直接开通云通讯按钮即可。新认证的腾讯云账号，云通讯的应用列表是空的，如下图：
点击创建应用接入按钮创建一个新的应用接入，即您要接入腾讯云IM通讯服务的App的名字，我们的测试应用名称叫做“小直播演示”，如下图所示：
点击确定按钮，之后就可以在应用列表中看到刚刚添加的项目了，如下图所示：
2. 应用配置上图的列表中，SDKAPPID 这一列显示的是腾讯云通讯业务ID，这个ID在对接各平台版本的IM SDK时都会用到，右侧有一个应用配置按钮，点击这里进入下一步的配置工作，如下图所示。
此处的配置项比较多，但大部分都不重要，你可以不配置或者之后有需要再随时调整，比如：
您可以随便填写（不要用特殊奇葩火星文等字符）
目前有且仅有“系统生成公钥”，所以这一项配置您无需关心。
账号管理员名称
是一个可以方便调试用的UserId，如果您是工程师，直接填写自己后面常用的账号id就可以了，使用云通讯服务的高级特性是才有可能用到。
验证短信签名
就是短信文本的前缀，填写App的中文名称就可以了。
这个部分我们在下面详细介绍
这些配置好以后，您要做的就是点击保存按钮就可以了。
3. 集成模式3.1 两种集成模式集成模式说的是账号集成用什么模式？ 针对客户不同的安全性要求，我们有不同的推荐方案：
访客（托管）模式
适合对身份确认要求不高的场景，比如允许App用户都可以发言的直播间聊天室场景。
采用guestLogin模式登录 IM SDK即可，对接成本极低。
设计目标是降低对接成本，让您能够不对接自由账号系统的情况下就能使用IM服务，腾讯云会为每个App用户生成一个“访客账号“，该账号可以用来收发消息，但这些账号跟您现有的账号体系没什么关系，所以它们也只能用来收发消息。
独立（鉴权）模式
对身份确认要求非常高的客户，比如要求消息收发者身份必须同自由账号体系中的 ID 一一绑定。
需要使用UserSig安全签名，对接成本比较高。
设计目标是将消息收发权限交给客户掌控，它要求在您的登录服务器确认App用户合法身份后需派发签名，腾讯云通过检查签名真实性后才允许收发消息。这样可以让消息的收发者都100%是您的账号体系里的账号。
帮助您理解
访客模式下，腾讯云通讯服务就像公共电话亭，在手机流行起来以前，公共电话服务还是很有市场的，但是我们对公共电话号码可从来没有特别在意过，确认对方身份靠的是通话里面的：“hello, this is rex！&
独立模式下，腾讯云通讯服务就像是个人手机服务，每个人都有确定的手机号码，好处就是看 “来电号码” 就能确认对方身份。代价就是买手机卡的时候要先过一下实名制，绑定个身份证什么的。
3.2 访客（托管）模式访客模式的设计目标是降低对接成本，让您能够不对接账号系统的情况下就能使用IM服务，腾讯云会为每个App用户生成一个“访客账号“，该账号只会用来收发消息。您可以将这些访客账号理解为一个个“傀儡账号”。消息发送者的真实用户信息（昵称、头像等等）不跟访客账号绑定，而是跟着消息体一起发出去。
该模式的接入流程非常简单：点点鼠标 + 写几行对接代码就能搞定。
（1）首先，在
中集成模式选项里选择 托管模式，这样能让腾讯云为访客模式的访客账号提供后台支持。（2）在客户端代码中对接 IM SDK 的访客登录模式即可，这里包括 TLS（TLS 的全称是 “Tencent Login Service” ，是腾讯云 IM SDK 的核心组件）和 IM SDK 两处的函数调用。
直接复用小直播 App 源码的话会简单很多，只需调用一个函数（iOS平台：位于TCIMPlatform.h 中的 guestLogin 函数；Android平台：位于TCLoginMgr.java 中的 guestLogin 函数）就可以达成目标，函数内部已经帮您封装了相关逻辑，如下是源码解释：
查询SDKAPPID ，ID的获取参考文章上半部分的 1. 开通服务。
调用 TLSHelper 头文件中的 TLSGuestLogin 函数，它会到腾讯云后台请求一个访客账号，如果第一步骤中的 SDKAPPID 没有设置错误，并且手机可以接入互联网，那么您会成功拿到一个 TLSUserInfo 对象，TLSUserInfo.identifier 即为访客账号的ID。
使用 TLSHelper 的 getTLSUserSig 函数可以为该 identifier 生成一个合法的 UserSig 签名。
最后，使用刚刚拿到的 identifier 和 UserSig 可以构造一个 TIMLoginParam 对象，之后使用 TIMManager 的 login 函数即可完成 IM SDK 的登录流程了。
- (void)guestLogin:(UIButton *)button {
TLSUserInfo *info = [[TLSHelper getInstance] getGuestIdentifier];
int ret = [[TLSHelper getInstance] TLSGuestLogin:self];
if (ret == 0) {
- (void)OnGuestLoginSuccess:(TLSUserInfo *)userInfo {
TIMLoginParam *loginParam = [[TIMLoginParam alloc] init];
loginParam.appidAt3rd = @"";
loginParam.sdkAppId =
loginParam.accountType = @"0";
loginParam.identifier = userInfo.
loginParam.userSig = [[TLSHelper getInstance] getTLSUserSig:userInfo.identifier];
[[TIMManager sharedInstance] login:loginParam succ:^{
} fail:^(int code, NSString *msg) {
Android 平台
查询SDKAPPID ，ID的获取参考文章上半部分的 1. 开通服务。
调用TLS（Tencent Login Service）的 TLSGuestLogin 函数完成访客登录，此时它会到腾讯云后台请求一个访客账号，如果第一步骤中的SDKAPPID 没有设置错误，并且手机可以接入互联网，那么您会成功拿到一个 TLSUserInfo 对象，TLSUserInfo.identifier 即为访客账号的ID。
使用TLS的 getUserSig 函数可以为该 identifier 生成一个合法的 UserSig 签名。
最后，使用刚刚拿到的 identifier 和 UserSig 调用 TIMManager 的 login 函数即可完成 IM SDK 的登录流程了。
public void guestLogin() {
mTLSLoginHelper.TLSGuestLogin(new TLSGuestLoginListener() {
public void OnGuestLoginSuccess(TLSUserInfo tlsUserInfo) {
TIMUser user = new TIMUser();
user.setAccountType(String.valueOf(TCConstants.IMSDK_ACCOUNT_TYPE));
user.setAppIdAt3rd(String.valueOf(TCConstants.IMSDK_APPID));
user.setIdentifier(tlsUserInfo.identifier);
String userSig = mTLSLoginHelper.getUserSig(identifier);
TIMManager.getInstance().login(TCConstants.IMSDK_APPID, user, userSig, new TIMCallBack() {
public void onSuccess() {
public void onError(int i, String s) {
3.3 独立（鉴权）模式3.3.1 原理解析独立模式的设计目标是将消息收发权限交给客户掌控：APP 用户在成功登录后，您的登录服务器需要派发imLogin ( IM SDK 运行的第一个步骤 ) 所需求的 UserSig 签名（签名的计算采用跟腾讯云后台协商的非对称密钥实现），腾讯云通过检查 UserSig 签名的有效性后，才允许其收发消息。
如此一来，就能保证：只有通过您的服务器认证的用户，才能正常的通过 IM 云通讯服务器的验证。
当然，更重要的意义是，既然没有经过您认可的用户不能使用 IM 功能，那么您就不需要将用户名和昵称放在 IM 消息体中，而是直接通过 IM 消息头里的 ID 身份确认消息发送者，因为消息头不破解 IM SDK 无法伪造，因此这种方式可以更安全的确认消息发送者的身份。
3.3.2 UserSig签名UserSig签名，是腾讯云 IM 服务后台跟您的服务器之间认证的一种手段，用于解决两家不同公司的服务器之间怎么相互信任的问题，我们打个更形象的比方来解释其原理：
某个美女用户在您的App上登录了，她使用了之前在您这里注册的ID和登录口令，ID叫做 “花仙子”。
您这边在拿到ID和口令后立刻进行了验证，并且确认她可以登录 APP 。于此同时，您还开给她一张放行条(UserSig)，上面写着“ '花仙子' 是良民的干活，到你腾讯的地盘，你可得伺候好了，不要亏待她...”，为了确保这个放行条不被伪造，您还在上面用正楷签了名。
腾讯云在看了您的放行条以后，确认签字为您本人亲笔所签，自然会提供相应的服务。
上述就是消息鉴权背后的对接方案，它的核心目标就是限制哪些没有得到您的后台服务器认可的用户收发消息，但让您的服务器检查每一条消息又是不合适的，所以才演化出了这样一套方案。
UserSig 签名使用了最普通的非对称密钥加密技术，您在开通独立模式的时候，会在腾讯云拿到一组公私密钥对，用私钥指定的信息即可。
3.3.3 对接流程
step1: 选择独立模式
确保腾讯中的集成模式为独立模式，并且下载计算签名用的公私钥。
step2: 完成后台对接
这部分由贵团队的后台工程师完成，它要使用step1中获取的签名秘钥，为您的 APP 提供一个拉取 UserSig 签名的接口，APP 登录成功后就可以通过该接口获取计算好的 UserSig。
step3: imLogin(ID, UserSig)
APP 获取到来自您的服务器签发的 UserSig 后，就可以调用 IM SDK 的 imLogin(ID, UserSig) 接口激活 IM 服务了，腾讯云后台会使用 step1 中对应的公钥对 UserSig 进行解密，从而验证当前用户是否得到了您的登录服务器的认可。
step4: 修改消息发送逻辑
修改消息发送端代码，不需要将发送者身份放入消息体中。同时修改消息接收端代码，通过 TIMMessage 的 sender 属性，来更加确定地获取消息发送者的身份。
以上步骤的示意图如下：
4. 消息收发腾讯云通讯服务支持多种消息类型的格式，比如文本、图片、表情、语音甚至小文件，这部分可以在 进行了解。
相对而言，直播中的消息形态比较简单，主要是如下几种类型：
普通文本消息：包括发送者的昵称以及消息本身。
弹幕消息：本质也是文本消息，只是消息的展示方式会更显花哨。
点赞消息：当一位观众为主播点赞时，要保证其他观众也能看到
系统通知，比如“XXX已加入房间”或者“主播已离开”等等。
针对这种比较简单的场景，我们在小直播中相应地采用了一种非常简单的办法：统一采用文本消息通道收发消息，因为有多字段（如消息类型、用户头像、昵称等）拼装需求的情况，我们采用了json格式对数据进行组装。
比如：“花仙子” 给主播发了一条消息 “帅哥笑一下” ，按照上述方案，真正发送的文本消息为：
"userAction": 1,
"userId": 27149,
"nickName": "花仙子",
"headPic": "http: //www.test.com/headpic/27149.png",
"msg": "帅哥笑一下"
其中，userAction 是我们在小直播中定义的消息类型，一共有 5 种，它们分别是：
userAction
AVIMCMD_Custom_Text
AVIMCMD_Custom_EnterLive
用户加入直播
AVIMCMD_Custom_ExitLive
用户退出直播
AVIMCMD_Custom_Like
AVIMCMD_Custom_Danmaku
接下来是小直播里的源码摘抄，源码的作用是发送一条普通的文本消息，谨供您参考：
4.1 iOS平台
- (void)sendMessage:(AVIMCommand)cmd userId:(NSString *)userId
nickName:(NSString *)nickName
headPic:(NSString *)headPic
msg:(NSString *)msgContent
if ((AVIMCMD_Custom_Text == cmd || AVIMCMD_Custom_Danmaku == cmd) && msgContent.length == 0)
DebugLog(@"sendMessage failed, msg length is 0");
NSDictionary* dict = @{@"userAction" : @(cmd),
@"userId" : TC_PROTECT_STR(userId),
@"nickName" : TC_PROTECT_STR(nickName),
@"headPic" : TC_PROTECT_STR(headPic),
@"msg" : TC_PROTECT_STR(msgContent)};
NSData* data = [TCUtil dictionary2JsonData:dict];
NSString *content = [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding];
TIMTextElem *textElem = [[TIMTextElem alloc] init];
[textElem setText:content];
TIMMessage *timMsg = [[TIMMessage alloc] init];
[timMsg addElem:textElem];
[_chatRoomConversation sendMessage:timMsg succ:^{
DebugLog(@"sendMessage success, cmd:%d", cmd);
} fail:^(int code, NSString *msg) {
DebugLog(@"sendMessage failed, cmd:%d, code:%d, errmsg:%@", cmd, code, msg);
4.2 Android 平台
private void sendMessage(int cmd, String param, TIMValueCallBack&TIMMessage& timValueCallBack)
JSONObject sendJson = new JSONObject();
sendJson.put("userAction", cmd);
sendJson.put("userId", TCUserInfoMgr.getInstance().getUserId());
sendJson.put("nickName", TCUserInfoMgr.getInstance().getNickname());
sendJson.put("headPic", TCUserInfoMgr.getInstance().getHeadPic());
sendJson.put("msg", param);
} catch (JSONException e) {
e.printStackTrace();
String cmds = sendJson.toString();
TIMMessage msg = new TIMMessage();
TIMTextElem elem = new TIMTextElem();
elem.setText(cmds);
if (msg.addElement(elem) != 0) {
Log.d(TAG, "addElement failed");
sendTIMMessage(msg, timValueCallBack);
以上信息是否解决您的问题？
提交成功！非常感谢您的反馈，我们会继续努力做到更好！
为了我们更有效的优化资料库，以及针对性的改善我们的服务，我们很需要您进一步的反馈信息：
页面内容不全面，不深入
页面内容更新不及时
描述不够清晰，比较混乱
系统或功能太复杂，同时文档也缺乏足够的引导
移动直播 相关文档