方案简介
本方案面向 Web3与泛金融行业,聚焦直播、消息推送、社群运营等实时互动核心场景,基于 Tencent RTC 产品体系(TUILiveKit、IM、Push)提供实时音视频、即时通信、转录与翻译等能力,满足全球化用户接入、行情实时触达、多语言交流等需求。方案沉淀了实时互动系统建设的最佳实践,将跨行业共性需求统一抽象为标准化参考架构,帮助开发者快速构建直播与即时通信系统。同时提供了 直播字幕实时转录与翻译、机器人推流与数字人直播 等高级能力的接入指引,覆盖全球化运营、数字化内容生产及合规管理等高频需求,适用于加密交易所、投顾社区、互联网券商、社交钱包等业务场景。

行业洞察与架构设计
本章节梳理 Web3与泛金融行业中的几类典型互动场景玩法与可复用的工程实践,帮助您在动手编码之前明确技术选型与业务边界。同时,梳理完整的系统边界与核心子系统,提供整体系统架构设计以及核心子系统拆解。
典型场景玩法
场景 | 玩法摘要 | 关键能力 |
AMA(Ask Me Anything) | 项目方与社区 1:N 互动;连麦、投票、文本转录、屏幕共享共读白皮书 | 视频直播、连麦互动、投票卡片、字幕转录、屏幕共享 |
社区管理与去中心化协作 | KOL 群聊、富媒体(图片 / 语音 / 文件 / 表情)、群权限管理、消息搜索 / 引用 / 历史漫游 | 百万人社群(Community)、消息卡片、文件传输 |
Market Alert 市场警报系统 | 行情异动、空投预热、风控告警秒级触达;按语言 / 标签 / 持仓分组推送 | Push 高并发、标签分组推送、离线消息推送 |
直播投顾与解盘 | 行情共读、社交跟单(Social / Copy Trading)、链上声誉 / 持牌资质、打赏转化 | 视频直播、屏幕共享、礼物系统、跟单卡片、订单回写 |
MemeFi Live Interaction | 主播发起链上互动,观众通过链上合约或代币质押参与;游戏化交易(GameFi 玩法) | 互动直播、链上事件回调、智能合约、礼物系统 |
注意:
Meme Coin 直播互动、MemeFi、LiveFi 等形态涉及链上交易、代币激励与高波动投机风险,本方案只描述技术形态与所需能力,不提供具体合约设计、玩法机制或代币经济参数(Tokenomics)。如您计划上线该类业务,请就具体合规要求咨询当地金融监管与法务团队。
整体架构设计
一个完整的 Web3与泛金融实时互动业务系统至少涉及六大业务域,每个业务域有独立的技术底座和数据模型。
业务域 | 核心职责 | 技术基座 | 提供方 |
直播域 | 房间管理、音视频通信、连麦互动、弹幕礼物、转录翻译 | AtomicXCore + AI 转录/翻译 | 腾讯云 |
即时通信域 | 单聊、群聊、社群(Community)、公众号、智能客服 | IM | 腾讯云 |
触达推送域 | 行情秒推、营销通知、订单提醒、离线触达 | Push | 腾讯云 |
资产交易域 | 钱包、跟单、订单、链上结算、红包 / 转账 | 业务自建(钱包 / 支付 / 链上服务) | 客户侧 |
风控合规域 | KYC、内容审核、风险提示、操作审计 | 云端内容理解 + 业务自建风控 | 腾讯云 + 客户侧 |
客服服务域 | 售前咨询、纠纷拉群、坐席流转、机器人 FAQ | 智能客服(Desk) | 腾讯云 |
客户端分层架构
从客户端视角看,整个 Web3与泛金融行业 App 一般按以下五个层级组织:
各层级职责说明:
Client Layer:基于声明式框架构建(例如 Android 使用 Jetpack Compose、iOS 使用 SwiftUI、Flutter 使用 Widget 体系),负责所有页面的响应式渲染。直播间页面是最复杂的 UI 场景,需要在视频流之上叠加弹幕、行情卡、跟单卡、礼物动画、连麦浮窗、字幕条等多个交互层。
ViewModel:遵循 MVVM 架构,每个页面对应独立的 ViewModel。ViewModel 的核心工作是组合来自不同数据源的状态,例如直播间 ViewModel 需要同时订阅 AtomicXCore Store 的直播状态(房间信息、连麦状态、弹幕列表等)和业务 Repository 的金融数据(行情、持仓、跟单状态等)。
Core SDK:直播能力由 AtomicXCore SDK 的 Store 体系提供(如 LoginStore、DeviceStore、BarrageStore、GiftStore 等);IM 能力由 IM SDK 提供;业务能力由开发者自建的 Repository 层提供,每个 Repository 封装对应服务端 API 的网络调用、数据缓存和错误处理(如 MarketRepository 封装行情接口、WalletRepository 封装钱包接口)。
Server Layer:集成腾讯云底层的 Tencent RTC、IM、Push、AI 实时转录与翻译、内容理解等能力,以及链上服务、支付等第三方 SDK。开发者通常不需要直接操作该层,而是通过 L3 的 Store 和 Repository 间接调用。
Business:承载所有服务端业务逻辑,客户端通过 REST API 或 WebSocket 与之通信。
服务端架构概览
服务端建议按微服务或模块化方式组织,核心服务拆分如下:
服务 | 核心职责 | 对外接口 | 依赖的能力 |
直播服务 | 房间管理、成员管理、连麦管理、消息管理、字幕服务 | REST API | TUILiveKit REST API + AI 转录 |
鉴权服务 | UserSig 生成与刷新、STS 临时凭证签发、Role 授权 | REST API | TRTC / IM 鉴权服务 + STS |
钱包/资产服务 | 账户体系、链上托管、链上提现、转账、风控 | REST API | 支付系统 + 链上服务 |
红包服务 | 红包活动管理、抢红包、退款、幂等控制 | REST API | 支付系统 + 钱包服务 + IM 自定义消息 |
跟单/订单服务 | 跟单卡片下发、一键跟单、订单回写、撮合接入 | REST API | 业务交易系统 |
推送编排服务 | 多语言推送编排、标签分群、转化统计 | REST API | Push 服务 |
审核合规服务 | 内容审核回调、KYC、强禁言、风险事件 | REST API + Webhook | 内容理解 + 业务风控 |
用户服务 | 账号体系、KYC 等级、粉丝关系、链上身份 | REST API | IM 账户体系 |
客服服务 | 会话路由、机器人接待、智能应答 | REST API + Webhook | 智能客服(Desk) |
数据服务 | 直播数据统计、转化分析、用户画像 | 异步消息 + 批处理 | 数据仓库 |
核心子系统拆解
直播子系统
Store-Driven 架构
AtomicXCore SDK 采用 Store-Driven 架构,业务能力按域拆分为多个 Store;状态通过 StateFlow 响应式暴露,事件通过 Listener 回调分发。全局 Store 在应用级共享,房间级 Store 按 liveID 管理生命周期,退出房间时需主动释放监听与资源。
Store 模块分类
SDK 中的 Store 模块按生命周期可以分为两类:
全局单例 Store,在应用生命周期内共享,适用于跨房间的通用能力管理。
房间维度 Store,通过
create(liveID) 获取,内部实现为同一 liveID 返回同一实例。Store/Component | 功能描述 | API 文档 |
LiveCoreView | 直播视频流展示与交互的核心视图组件:负责视频流渲染和视图挂件处理,支持主播直播、观众连麦、主播连线等场景。 | |
LiveListStore | 直播间全生命周期管理:创建 / 加入 / 离开 / 销毁房间,查询房间列表,修改直播信息(名称、公告等),监听直播状态(如被踢出、结束)。 | |
DeviceStore | 音视频设备控制:麦克风(开关 / 音量)、摄像头(开关 / 切换 / 画质)、屏幕共享,设备状态实时监听。 | |
CoGuestStore | 观众连麦管理:连麦申请 / 邀请 / 同意 / 拒绝,连麦成员权限控制(麦克风 / 摄像头),状态同步。 | |
CoHostStore | 主播跨房连线:支持多布局模板(动态网格等),发起 / 接受 / 拒绝连线,连麦主播互动管理。 | |
BattleStore | 主播 PK 对战:发起 PK(配置时长 / 对手),管理 PK 状态(开始 / 结束),同步分数,监听对战结果。 | |
GiftStore | 礼物互动:获取礼物列表,发送 / 接收礼物,监听礼物事件(含发送者、礼物详情)。 | |
BarrageStore | 弹幕功能:发送文本 / 自定义弹幕,维护弹幕列表,实时监听弹幕状态。 | |
LikeStore | 点赞互动:发送点赞,监听点赞事件,同步总点赞数。 | |
LiveAudienceStore | 观众管理:获取实时观众列表(ID / 名称 / 头像),统计观众数量,监听观众进出事件。 | |
AudioEffectStore | 音频特效:变声(童声 / 男声)、混响(KTV 等)、耳返调节,实时切换特效。 | |
BaseBeautyStore | 基础美颜:调节磨皮 / 美白 / 红润(0-9 级),重置美颜状态,同步效果参数。 |
资产 / 交易子系统
资产 / 交易子系统通常由业务层自建,AtomicXCore SDK 不提供对应的专属 Store。不过您仍然可复用 AtomicXCore 房间自定义信息(
MetaData)能力,在房间内存储和同步任何业务相关的信息(如当前讲解的币种、当前在播的策略 ID);复用自定义消息(CustomMessage)能力,在房间内广播任何业务相关的消息(如跟单卡片、行情卡片、订单成交回执)。功能模块 | 核心能力 | 与直播间的联动方式 |
钱包 / 账户 | 余额查询、链上托管、提现、转账 | 进房展示资产卡片;连麦 / 打赏 / 红包扣款链路 |
行情服务 | 多币种行情、K 线、深度 | 主播切换讲解币种时通过房间自定义信息存储和同步 |
跟单 / 策略 | 策略发布、跟单订阅、净值结算 | 主播通过自定义消息在直播间发布交易策略 / 跟单卡片 |
订单 / 撮合 | 下单、撤单、成交回执 | 订单卡片回写直播间,并以系统消息形式在弹幕区展示 |
风控合规子系统
功能模块 | 核心能力 | 与直播间的联动方式 |
直播审核 | 视频 + 音频内容理解,违规识别 | 审核命中触发关播 / 警告 / 封禁 |
消息审核 | 单聊 / 群聊 / 群成员资料审核 | 直播间弹幕内容审核、直播间用户资料审核 |
KYC | 实名认证、身份分级 | 连麦、提现、跟单等操作前置校验 |
审计留痕 | 消息留存、操作日志、双录系统 | 直播云端录制、合规凭证与追溯 |
用户与社群子系统
功能模块 | 核心能力 | 与直播间的联动方式 |
账号体系 | 注册、登录、关系链、用户资料 | 为直播观看、交易、连麦提供身份基础 |
会员等级 | VIP、积分、链上声誉评分(On-chain Reputation) | 影响连麦优先级、客服等级、跟单权重 |
粉丝社群 | 社群(Community)、分组、话题、公告 | 直播预热、福利发放、用户沉淀 |
公众号 | 广播推文、订阅、互动 | 品牌资讯、项目方 / 机构资讯、平台公告 |
触达推送子系统
功能模块 | 核心能力 | 与直播间的联动方式 |
行情秒推 | 高并发30秒级下发、按标签 / 指定用户分类 | 币价异动秒级触达,第一时间唤起 App |
直播预告 | 直播预约、开播提醒 | 开播前自动唤醒关注用户 |
营销推送 | 空投预热、活动通知、社区福利 | 提升 DAU 与活跃度 |
交易通知 | 订单成交、提现到账、风控告警 | 实时通知用户资产变动等重要消息 |
直播功能开发实践
本章将提供直播常见功能的开发实践,帮助您更快地找到对应功能的说明文档。
基础使用:开播及观看。
直播互动:弹幕消息、送礼点赞、观众连麦、跨房连线 / PK、屏幕共享。
全球化:直播字幕、转录翻译、多语言消息推送。
高级场景:OBS 推流、数字人直播、直播云端录制。
风控合规:音视频内容理解、弹幕消息内容理解、资料审核。
准备工作
在开始之前,您需要先完成开通服务、导入 AtomicXCore、实现登录逻辑等准备工作。
1. 开通服务:登录 TRTC 控制台,创建直播/语聊房(TUILiveKit)应用,同时领取体验版或购买正式版。
2. 导入 AtomicXCore:在当前项目中导入 AtomicXCore,添加 AtomicXCore SDK 及 IM SDK 依赖。
3. 实现登录逻辑:在您的项目中调用
LoginStore 完成登录,这是使用 AtomicXCore 所有功能的关键前提。说明:
主播端完整实现
主播开播流程如下,您只需执行以下几步操作,即可快速实现 KOL 投顾 / 项目方主播的视频直播。
说明:
LiveCoreView 集成
层级 | 作用 | 说明 |
底层 | LiveCoreView | 承载本地预览或远端视频 |
中层 | 主播信息、行情卡片、跟单卡片、字幕显示、在线人数 | 常驻轻交互信息 |
上层 | 弹幕、礼物、连麦弹窗 | 高频动态交互 |
顶层 | 结束直播确认、风控告警、合规拦截 | 阻断式操作与兜底提示 |
设备管理
管理项 | 说明 |
麦克风管理 | 打开/关闭麦克风,设置采集音量和输出音量 |
摄像头管理 | 打开/关闭摄像头,切换前后摄像头,设置镜像和视频质量 |
音频路由 | 切换扬声器和听筒 |
屏幕分享 | 开启和关闭屏幕分享功能(PC 推流助手、行情共享场景) |
网络状态 | 实时监控网络质量信息 |
创建直播间
模式一:客户端创建房间
主播客户端直接调用
LiveListStore.shared().createLive 创建房间,并自动进入房间开始推流。该模式适用于轻量验证或运营管控较少的场景,特点是接入快、链路短。
模式二:服务端创建房间
服务端调用 REST API
create_room 创建一个空房间,主播客户端还需调用 LiveListStore.shared().joinLive 进入房间开始推流。该模式的核心价值不在于多绕一次接口,而是把房间生命周期、主播资质、合规审核状态统一放到服务端进行管理。
结束直播间
模式一:客户端结束直播
主播客户端直接调用
LiveListStore.shared().endLive 结束直播。该模式适用于一般的轻量直播场景,仅客户端就能独立完成关播动作,无需服务端参与。
模式二:服务端销毁房间
主播客户端触发结束动作,服务端统一调用 REST API
destroy_room 解散房间。该模式适用于较为复杂的直播场景,服务端可统一管控直播间生命周期,并在关播时结算关联业务(如本场跟单结算、礼物结算、合规留痕)。
观众端完整实现
观众观看流程如下,通过简单几步操作,即可实现观众观看直播。
说明:
进入直播间
进入直播间成功后,还需要注意业务数据的同步完成,例如弹幕消息区、行情卡片、跟单卡片、客服入口等。
退出直播间
退出直播间成功后,还需要注意停止房间相关监听和消息订阅、清理房间级 Store、回到直播列表或推荐页。
观众连麦互动实现
连麦是直播投顾、AMA 等场景中增强互动性的重要功能,允许观众与主播进行实时音视频通话。AtomicXCore 提供了 CoGuestStore 模块,专门用于管理观众连麦的完整业务流程。CoGuestStore 支持两种最主流的连麦场景:观众申请上麦、主播邀请上麦。关于观众连麦互动功能的更多实现细节,详见 观众连线。
观众申请上麦
观众主动发起连麦请求,主播在收到请求后进行同意或拒绝。
主播邀请上麦
主播可以主动向直播间内的任意一位观众发起连麦邀请,观众在收到邀请后进行同意或拒绝。
主播连线 PK 实现
在投顾直播场景中,“投顾 PK”是高频玩法,如多空辩论、策略对决等。AtomicXCore 提供了 CoHostStore 和 BattleStore 两个核心模块,分别用于处理跨房连线和 PK 对战。
一次完整的“主播连线 PK”通常包含以下四个阶段:
1. 跨房连线:两个主播建立连线,画面出现在同一个视图中。
2. 发起 PK:连线成功后,任意一方可以发起 PK 挑战。
3. PK 对战:双方进行 PK 对战,实时更新 PK 分数(可与观众投票、礼物打赏联动)。
4. 结束 PK 连线:互动结束后,主播需要按照逻辑顺序,先结束 PK 状态,再断开跨房连线。
说明:
实时弹幕系统实现
弹幕是直播间最常见的互动形式之一,它承载着用户的即时反馈、行情询问、链上互动指令等多重诉求。使用
AtomicXCore 框架中的 BarrageStore 模块,能为您的直播应用快速集成功能丰富、性能卓越的弹幕系统。
消息分层
直播间往往同时承载弹幕、行情指令、跟单回执等多种消息流。客户端建议按消息类型进行分流:文本消息、自定义消息、本地提示等。
类型 | 用途 | 展示方式 |
普通文本消息 | 咨询、互动、情绪表达 | 飘屏 / 弹幕列表 |
自定义消息 | 跟单卡片、成交回执、特效弹幕 | 特效 / 卡片消息 |
本地提示 | 进入房间、连麦状态、风控提示 | 本地 / 系统消息 |
用户等级 / 身份标识
用户等级与身份标识功能是直播互动场景中的重要组成部分,用于区分 KOL 认证、VIP 会员、链上声誉评分(On-chain Reputation)、是否完成 KYC 等不同状态,从而实现差异化的界面展示、交互权限和功能访问控制。TUILiveKit 默认不提供基础的身份标识框架,但您可以参考以下方式进行实现:
维护用户等级 / 身份映射
在您的业务后端,根据您需要的用户等级 / 身份相关逻辑(如链上身份、KOL 认证、VIP 等),自行维护并存储与每个用户 UserID 对应的等级 / 身份。
插入用户等级 / 身份信息
客户端方案:使用
BarrageStore.sendCustomMessage() 发送弹幕消息,其中 data 插入从业务后端获取到的等级 / 身份信息。收到消息时,解析 data 中的等级 / 身份信息,之后自行在弹幕列表上渲染。服务端方案:启用 房间内发言之前回调,业务后端可以通过该回调实时查看和拦截用户在房间发送的消息。在回调应答阶段,您可以对用户发送的弹幕消息进行变动(增加自定义消息)。App 后台可以基于这一特性在用户发送的消息中增加一些特殊内容,例如用户等级、头衔等信息。
弹幕列表 UI 性能优化
弹幕列表的性能优化是高并发直播场景下的关键挑战。建议采用以下策略:
优化策略 | 实现方式 | 效果 |
列表长度限制 | 保留最近500条消息,超出部分从头部移除 | 控制内存占用 |
批量渲染 | 每300ms 批量更新一次 UI,而非逐条刷新 | 减少 UI 重绘次数 |
视图复用 | 使用 RecyclerView/UITableView 的复用机制 | 降低对象创建开销 |
异步加载 | 图文、自定义字体或复杂布局的视图异步绘制 | 避免主线程阻塞 |
说明:
礼物赠送系统实现
礼物系统是直播变现与 KOL 激励的重要渠道,也是活跃直播间氛围的有效手段。
GiftStore 是 AtomicXCore 中专门负责管理直播间礼物功能的模块。在 Web3与泛金融场景下,礼物可以是平台积分、法币打赏、加密货币(含稳定币)打赏、NFT(非同质化代币)礼物等多种资产形态。
礼物素材配置
您需要自定义直播间可用的礼物种类、分类、名称、图标、价格以及动画效果,以满足运营需求和品牌特色。
1. 服务端配置:使用 TUILiveKit 服务端 REST API 管理礼物信息、分类、多语言等。请参见 礼物配置指引。
2. 客户端拉取:在客户端调用
refreshUsableGifts 获取配置数据。3. UI 展示:使用拉取到的
List<GiftCategory> 数据填充礼物面板。
对于 SDK 内置礼物列表无法覆盖的高度定制化场景(如加密货币打赏、NFT 礼物、SBT / POAP 等链上凭证发放),可以通过
BarrageStore.sendCustomMessage() 发送自定义消息作为补充。以下为加密货币打赏自定义消息结构示例:{"type": "live_crypto_tip","tipId": "tip_20260604_001","asset": {"symbol": "USDT", // 代币符号;稳定币 USDT 在以太坊主网遵循 ERC-20 标准"amount": "100.00", // 字符串避免 JS 数字精度丢失"chain": "ethereum", // 区块链网络标识(建议使用 chainId 或标准链名)"tokenContract": "0xdAC17F958D2ee...", // 代币合约地址;原生代币(如 ETH / SOL)可省略"txHash": "0xabc123..." // 链上交易哈希,用于跨端校验与审计},"senderId": "user_123","senderName": "Alice","senderAvatar": "https://example.com/avatar.jpg","effectUrl": "https://example.com/effects/usdt-rain.json"}
计费与送礼扣费流程
当观众赠送礼物时,需要确保其平台账户余额充足,或链上交易已完成且达到目标确认数(Confirmations),并完成实际的扣费操作,然后才能触发礼物特效的播放和广播。
1. 后台配置回调:在 TUILiveKit 控制台配置您的自建钱包 / 计费系统的回调 URL。请参考 回调配置文档。
2. 客户端发送:客户端调用
sendGift。3. 后台交互:TUILiveKit 服务端调用您的回调 URL,您的钱包 / 计费系统执行扣款(或对链上交易进行确认数核验)并返回结果。
4. 结果同步:扣费成功,AtomicXCore 广播
onReceiveGift 事件;扣费失败,sendGift 的 completion 收到错误。
直播录制功能实现
直播录制支持将直播间内的音视频内容录制并进行存储,录制后的文件可用于回放、质检、审核、存档等场景。本节介绍的录制功能基于 TRTC 云端录制 能力实现,并在此基础上针对 TUILiveKit 创建的直播间预设了典型录制场景参数,帮助您更简单、快速地完成直播录制配置。更多介绍详见 直播录制功能。
步骤1:前往控制台配置录制文件存储地址
1. 前往 实时音视频控制台 > 应用管理 > LiveKit 功能,点击配置房间录制。
2. 在配置弹窗进行录制功能配置,配置项说明请参考下表。
注意:
IsCloudRecordEnabled 参数的默认值为空。若将其设为 false,即使开启全房间录制,该房间也不会被录制。步骤2:创建房间时设置录制参数
屏幕共享功能实现
本节介绍如何在 TUILiveKit 中集成屏幕共享功能。通过该功能,用户可以在进入房间后将自己的屏幕画面实时分享给房间内的其他成员。在 Web3与泛金融行业场景中,屏幕共享常被用于分享讲解的课件、共读白皮书资料等。
注意:
视频流互斥限制:TUILiveKit 屏幕分享时不支持打开摄像头。在 TUILiveKit 架构中,摄像头采集的视频流与屏幕分享视频流只能二选一,两者无法同时推流。
环境配置
开始屏幕分享直播
步骤1:SDK 集成与主播开播
步骤2:配置屏幕分享开播
配置开播的房间参数
LiveInfo.seatTemplate 为 videoLandscape4Seats(即开启适合屏幕共享的横屏多座位模板),请在 LiveListStore.startLive 成功回调后,再调用 DeviceStore.shared().startScreenShare() 开启屏幕分享。import io.trtc.tuikit.atomicxcore.api.live.LiveListStoreimport io.trtc.tuikit.atomicxcore.api.live.LiveInfoimport io.trtc.tuikit.atomicxcore.api.live.SeatLayoutTemplateimport io.trtc.tuikit.atomicxcore.api.device.DeviceStoreprivate fun startLiveForScreenShare() {val liveInfo = LiveInfo().apply {// 1. 设置直播的房间 IDliveID = "test_live_id"// 2. 设置直播的房间名称liveName = "屏幕分享直播"// 3. 核心步骤:配置适合屏幕分享的布局模板seatTemplate = SeatLayoutTemplate.VideoLandscape4Seats}// 4. 调用 LiveListStore 开始直播并进房LiveListStore.shared().startLive(liveInfo, object : LiveListStore.StartLiveCallback {override fun onSuccess(roomInfo: Any) {// 5. 调用接口开启屏幕分享,系统会自动触发前台服务与系统弹窗DeviceStore.shared().startScreenShare()}override fun onError(code: Int, message: String) {// 处理开播失败错误}})}
import AtomicXCoreprivate func startLiveForScreenShare() {var liveInfo = LiveInfo()// 1. 设置直播的房间 IDliveInfo.liveID = "test_live_id"// 2. 设置直播的房间名称liveInfo.liveName = "屏幕分享直播"// 3. 核心步骤:配置适合屏幕分享的布局模板(横屏动态 1 视频 + 3 音频)liveInfo.seatTemplate = .videoLandscape4Seats// 4. 调用 LiveListStore 单例开始直播并进房LiveListStore.shared.startLive(liveInfo: liveInfo) { [weak self] roomInfo inguard let self = self else { return }// 5. 调用 startScreenShare 开启屏幕分享DeviceStore.shared.startScreenShare(appGroup: "group.com.yourcompany.yourapp.screenshare")} onError: { code, message in// 处理开播失败错误}}
import 'package:atomic_x_core/api/live/live_list_store.dart';import 'package:atomic_x_core/api/device/device_store.dart';Future<void> startLiveForScreenShare() async {// 1. 构建开播房间参数LiveInfo liveInfo = LiveInfo();liveInfo.liveID = "test_live_id";liveInfo.liveName = "屏幕分享直播";// 2. 核心步骤:配置适合屏幕分享的布局模板(横屏动态 1 视频 + 3 音频)// 注:具体枚举名请对齐您当前 Flutter SDK 定义的横屏 4 座位模板字段liveInfo.seatTemplate = SeatLayoutTemplate.VideoLandscape4Seats;try {// 3. 调用 LiveListStore 开始直播并进房await LiveListStore.shared.startLive(liveInfo: liveInfo);// 4. 调用 startScreenShare 开启屏幕分享await DeviceStore.shared.startScreenShare(iOSAppGroup: 'group.com.yourcompany.yourapp.screenshare');} catch (e) {// 处理开播或进房失败错误}}
结束屏幕分享直播
当需要停止屏幕画面分享时,请根据以下业务场景进行选择:
场景一:仅结束屏幕分享
如果主播只想退出投屏状态,继续留在直播间进行直播,可以主动调用各平台的
stopScreenShare() 接口。import io.trtc.tuikit.atomicxcore.api.device.DeviceStore/*** 停止 Android 屏幕共享*/fun stopScreenShare() {// 停止屏幕共享,底层会自动销毁前台保活服务DeviceStore.shared().stopScreenShare()// 推荐:重新打开本地摄像头恢复露脸直播DeviceStore.shared().openLocalCamera(isFront: true)}
import AtomicXCore/*** 停止 iOS 屏幕共享*/func stopScreenCapture() {// 停止屏幕共享,底层会自动断开与 TUIKitReplay 扩展进程的通信DeviceStore.shared.stopScreenShare()// 推荐:恢复本地摄像头画面DeviceStore.shared.openLocalCamera(isFront: true)}
import 'package:atomic_x_core/api/device/device_store.dart';/*** 停止 Flutter 屏幕共享*/Future<void> stopScreenShare() async {// 停止 Flutter 跨平台屏幕共享await DeviceStore.shared.stopScreenShare();// 推荐:恢复本地摄像头画面await DeviceStore.shared.openLocalCamera(true);}
场景二:直接结束直播
如果在投屏结束后直接选择下播,开发者只需要调用结束直播的
LiveListStore.endLive,SDK 底层会自动执行关闭屏幕分享的全部逻辑。直播字幕实时转录与翻译
全球化是 Web3与泛金融业务的天然属性,主播与观众跨语种互动是常态。腾讯云 AI 实时转录/翻译解决方案 提供基于 STT + LLM 翻译的端到端能力,把直播间内说话人的语音实时转成文本,可选开启多语言翻译,UI 侧自行渲染字幕。同时支持多语种识别、临时热词表、脏词和语气词过滤等功能。
两种发起方式
客户端发起方式:
AITranscriberStore方法 | 参数 | 作用 |
startTranscription | (myLanguage: SourceLanguage, config: TranscriptionConfig, completion: CompletionHandler?) | 启动实时转录/翻译 |
updateTranscription | (myLanguage: SourceLanguage, config: TranscriptionConfig, completion: CompletionHandler?) | 转录过程中动态切换语言/开关翻译 |
stopTranscription | (completion: CompletionHandler?) | 停止实时转录/翻译 |
客户端启动、更新、停止 AI 实时转录/翻译的示例代码:
import io.trtc.tuikit.atomicxcore.api.ai.*// 1. 创建实例val store = AITranscriberStore.create(roomID)// 2. 启动转写store.startTranscription(myLanguage = SourceLanguage.CHINESE,config = TranscriptionConfig(enableTranslation = true)) { code, message ->if (code == 0) {// 启动成功} else {// 启动失败: $message}}// 3. 语言切换 / 翻译开关(运行中更新)store.updateTranscription(myLanguage = SourceLanguage.ENGLISH,config = TranscriptionConfig(enableTranslation = true)) { code, message ->// handle result}// 4. 停止转写store.stopTranscription { code, message ->// handle result}
import AtomicXCore// 1. 创建实例let store = AITranscriberStore.create(roomID: roomID)// 2. 启动转写store.startTranscription(myLanguage: .chinese,config: TranscriptionConfig(enableTranslation: true)) { result inswitch result {case .success:print("转写启动成功")case .failure(let error):print("转写启动失败: \\(error)")}}// 3. 语言切换 / 翻译开关(运行中更新)store.updateTranscription(myLanguage: .english,config: TranscriptionConfig(enableTranslation: true)) { result in// handle result}// 4. 停止转写store.stopTranscription { result in// handle result}
注意:
客户端发起方式是用户维度,即所有希望开启转录/翻译功能的用户(包括主播和观众)均需调用
startTranscription。观众端能够接收到转录/翻译结果的前提,是有主播端开启转录/翻译功能,未开启的主播语言设置默认跟随其设备系统语言。
如若开启翻译功能,客户端无需单独设定翻译的目标语言,翻译目标语言由每个用户自己的
myLanguage 参数自动确定。服务端发起方式:
CreateCloudTranscriptionTRTC 提供了如下三个服务端 REST API,分别用于发起、查询、停止 AI 实时转录/翻译任务。
接口 | 关键入参 | 作用 |
SdkAppId / RoomId / RoomIdType / TranscriptionParam / AsrParam / TranslationParam | 开始云端转录/翻译任务 | |
SdkAppId / TaskId | 查询云端转录/翻译任务状态 | |
SdkAppId / TaskId | 停止云端转录/翻译任务 |
服务端发起 AI 实时转录/翻译任务示例代码:
{"SdkAppId": 1400000000, // TRTC SdkAppId"RoomId": "room_xxx", // 被转录的 TRTC 房间号"RoomIdType": 1, // 房间号类型:0=数字房间号,1=字符串房间号;必须与实际类型一致"TranscriptionParam": {"UserId": "transcriber_robot_001", // 机器人 UserId:房间内唯一,不能与主播/观众重复"UserSig": "eJxNjs1uwjAQhN_F1xT...", // 该 UserId 的签名,由后台生成(不建议在端侧生成)"SubscribeList": [ // 转录用户白名单,为空或不填表示转录所有主播音频{ "UserId": "anchor_001" }],"MaxIdleTime": 60 // 房间内推流用户全部离开后超过 60 秒自动结束任务},"AsrParam": {"Lang": "zh", // STT 模型,例:zh-TW / en / ja / ko / fr ..."VadSilenceTime": 1000, // VAD 静音断句阈值,单位 ms,更小的值会让语音识别分句更快"VadLevel": 2 // VAD 远场人声抑制能力,范围为[0, 3],越大的值抑制能力越强},"TranslationParam": {"TargetLang": ["en", "ja"] // 翻译的目标语言(可选,不需要翻译时不填),例:en / ja / ko ...}}
两种接收方式
方式一:通过服务端事件回调接收
方式二:通过客户端 SDK 回调接收
您可以参考以下代码,从
AITranscriberStore 的响应式数据中监听回调接收转录/翻译消息,适合用于端侧字幕 UI 渲染与刷新。按以下代码订阅
realtimeMessageList 的 StateFlow,在 collect 回调中通过 DiffUtil 或 ListAdapter 更新 RecyclerView 数据源即可。lifecycleScope.launch {repeatOnLifecycle(Lifecycle.State.STARTED) {store.transcriberState.realtimeMessageList.collect { messages ->adapter.submitList(messages.toList()) // 使用 ListAdapter + DiffUtil}}}
其中
messages 是 TranscriberMessage 的列表,TranscriberMessage 参数说明:参数名 | 类型 | 描述 |
segmentId | String | 用户的每句话都对应一个唯一的 segmentId。 |
speakerUserId | String | 说话用户的 ID。 |
speakerUserName | String | 说话用户的昵称。 |
sourceText | String | 用户的语音转文本。 |
translationTexts | Map<TranslationLanguage, String> | 用户语音文本对应的翻译文本,可翻译成多种语言。 |
timestamp | Long | 当前句子的时间戳。 |
isCompleted | Boolean | 当前句子是否已经完成。 |
按以下代码监听消息列表的回调,更新到相应 UI 上。
store.state 是 StatePublisher<TranscriberState>,在 SwiftUI 中可以通过 @ObservedObject 使用,或在 UIKit 中通过 Combine 订阅。// 假如以 UITableView 显示消息列表,更新消息后,reloadData 即可store.state.subscribe(StatePublisherSelector(keyPath: \\.realtimeMessageList)).receive(on: RunLoop.main).sink { [weak self] in self?.updateMessages($0) }.store(in: &cancellables)
其中
messages 是 TranscriberMessage 的列表,TranscriberMessage 参数说明:参数名 | 类型 | 描述 |
segmentId | String | 用户的每句话都对应一个唯一的 segmentId。 |
speakerUserId | String | 说话用户的 ID。 |
speakerUserName | String | 说话用户的昵称。 |
sourceText | String | 用户的语音转文本。 |
translationTexts | [TranslationLanguage: String] | 用户语音文本对应的翻译文本,可翻译成多种语言。 |
timestamp | Int64 | 当前句子的时间戳。 |
isCompleted | Bool | 当前句子是否已经完成。 |
机器人推流与数字人直播
机器人推流专为多样化的直播需求设计,通常用于将预先录制好的视频、实时生成的画面等外部媒体流 通过 OBS Studio 推送到直播间。该方案适用于游戏直播、电竞解说或播放本地视频文件等场景。除此之外,您还可以实现如下应用场景:
场景类型 | 说明 |
内容重播 | 将热门直播内容或录播视频重新推流,吸引更多观众观看。 |
虚拟主播 | 结合数字人虚拟形象技术,通过机器人推流实现虚拟主播的直播。 |
企业直播 | 用于企业会议、产品发布会、培训等场景,将录制的视频推流到内部或外部平台。 |
游戏直播 | 将游戏画面推流到直播间,结合解说或背景音乐,提升直播效果。 |
教育直播 | 将录制的课程视频推流到教育平台,实现线上教学。 |
电商直播 | 通过机器人推流展示商品信息、促销活动等,提升销售转化率。 |
更多场景 | 任何基于媒体流的实时互动体验玩法,均可通过 RTMP 推流帮您实现,更多玩法等待您的探索。 |
步骤1:创建房间与机器人
1. 调用 REST API 创建直播间。
2. 调用 REST API 添加机器人,推荐将房主 ID 设为机器人 UserID。
步骤2:接入数智人会话交互
1. 使用数智人平台项目创建会话:请求参数
Protocol 选择 trtc,ProtocolOption 需填写 TRTC 各项进房参数。2. 开启会话:会话就绪之后,默认状态为关闭,需要调用此接口开启会话使数智人可以通过指令进行驱动。
步骤3:实现机器人上麦
说明:
您需按照 创建直播间 > 添加机器人 > 接入数智人会话交互 > 机器人上麦 的步骤实现机器人推流。
当您需要停止数字人推流,结束数字人直播时,请按以下步骤进行操作:
步骤1:机器人下麦
步骤2:删除机器人
步骤3:解散直播间
步骤4:关闭数智人会话
说明:
您需按照机器人下麦 > 删除机器人 > 解散直播间 > 关闭数智人会话的步骤实现机器人停止推流。
业务核心功能开发实践
本章聚焦直播间内“内容驱动交易”的核心转化功能:行情卡片与币种切换、社交跟单与跟单卡片、直播间弹幕投票 / AMA 互动,即如何把主播的解盘、带单、问答等内容实时转化为观众的交易与互动行为。这些功能均属于业务层自建范畴,开发者需要基于 AtomicXCore + 业务后端(行情 / 订单 / 跟单 / 钱包账户)协同实现。
行情卡片与币种切换
主播在解盘过程中切换讲解币种时,需要在观众端同步弹出对应的行情卡片。由于“当前讲解币种”本质是一个全程唯一的状态值,本方案采用房间元数据(Metadata)实现:房间元数据在 AtomicXCore 中是可订阅的响应式状态,主播更新后既会实时推送给所有在线观众,新观众进房订阅时也能立即读到当前值,可同时满足实时性与可靠性。
核心需求
主播在直播过程中切换讲解币种后,需要将行情信息推送至所有观众端并展示卡片,需满足以下要求:
实时性:已在直播间的观众即时收到变更通知。
可靠性:中途加入的观众同样能获取当前讲解币种信息。
唯一性:每位观众对同一次币种切换仅展示一次卡片,不重复触发。
实现机制
行情卡片基于 AtomicXCore
LiveListStore 的房间元数据(LiveInfo.metaData,Map<String,String>)实现。
说明:
除了客户端方法
updateLiveMetaData 更新元数据,您还可以通过服务端方法 set_room_metadata 设置房间元数据。除了响应式订阅
liveState.currentLive 获取元数据,您还可以通过客户端方法 queryMetaData 主动查询元数据。主播 / 管理员通过客户端方法
updateLiveMetaData 写入,写入后 AtomicXCore 实时同步给所有观众。// Android (Kotlin)val metaData = hashMapOf("market_focus" to marketCardJson)LiveListStore.shared().updateLiveMetaData(metaData, object : CompletionHandler {override fun onSuccess() { /* 推送成功 */ }override fun onFailure(code: Int, desc: String) { /* 失败处理 */ }})
// iOS (Swift)let metaData = ["market_focus": marketCardJson]LiveListStore.shared.updateLiveMetaData(metaData) { result inif case .success = result { /* 推送成功 */ }}
观众端只需订阅响应式状态
liveState.currentLive,主播每次更新都会自动收到最新的全量 metaData。// Android:订阅 StateFlowscope.launch {LiveListStore.shared().liveState.currentLive.map { it.metaData["market_focus"] }.distinctUntilChanged().collect { json ->if (json != null) renderMarketCard(json) else hideMarketCard()}}// 退出时 scope.cancel() 取消订阅,避免协程泄漏
// iOS:Combine 订阅 keyPathLiveListStore.shared.state.subscribe(StatePublisherSelector(keyPath: \\LiveListState.currentLive.metaData)).removeDuplicates().receive(on: DispatchQueue.main).sink { metaData inguard let json = metaData["market_focus"] else { hideMarketCard(); return }renderMarketCard(json)}.store(in: &cancellables) // 由 cancellables 统一管理订阅生命周期
行情卡片写入 metaData 的 value(
market_focus 对应的 JSON)结构示例如下。{"symbol": "BTC/USDT", // 当前讲解币对"exchange": "binance", // 行情来源"last_price": "67890.5", // 最新价(字符串避免精度丢失)"change_24h": "+3.21%", // 24h 涨跌幅"kline_url": "/kline/BTC-USDT?interval=15m", // 行情页跳转链接"deeplink": "myapp://market/btc", // App 内跳转"start_timestamp": 1773321389000, // 切换时间戳(毫秒),用于客户端 diff 去重"status": "active" // 状态:active 讲解中 / ended 已结束}
社交跟单与跟单卡片
社交跟单(Social Trading / Copy Trading)是直播投顾场景中最核心的转化形态:观众在直播间内通过跟单卡片可一键唤起业务页完成下单或跟单,下单结果再通过自定义消息广播回直播间形成闭环,实现“边看边交易”。该范式在 Web3(一键跟单加密资产)和持牌互联网券商(一键跟单股票 / 基金)场景中均已被广泛验证。
核心需求
跟单卡片承载的是“主播在某一时刻发出的带单信号”,这是一类时序事件:同一场直播中主播可连续发出多张卡片,每张对应一次独立的开仓动作,且都带有
expireAt 有效期,过期后不再可跟。需满足以下要求:实时性:主播发出带单信号后,在线观众即时收到并展示跟单卡片。
时效性:每张卡片携带
expireAt,超期后客户端不再展示跟单入口,避免观众跟入一笔已结束的单。可校验:观众点击跟单前,需校验有效期、KYC 等级、跟单白名单等条件,再唤起业务页下单。
实现机制
跟单卡片为时序事件,通过 AtomicXCore
BarrageStore.sendCustomMessage 实时广播下发。
主播 / 管理员发送跟单卡片
// Android (Kotlin)const val BUSINESS_ID = "follow_trade"BarrageStore.create(liveId).sendCustomMessage(BUSINESS_ID, // businessID,接收端据此过滤followTradeJson, // data:跟单卡片 JSON 字符串object : CompletionHandler {override fun onSuccess() { /* 广播成功 */ }override fun onFailure(code: Int, desc: String) { /* code / desc */ }})
// iOS (Swift)let barrageStore = BarrageStore.create(liveID: liveId)barrageStore.sendCustomMessage(businessID: "follow_trade",data: followTradeJson,completion: nil)
观众端订阅消息、解析渲染卡片
// Android (Kotlin):订阅自定义消息事件流private val barrageStore = BarrageStore.create(liveId)private val scope = CoroutineScope(Dispatchers.Main)fun start() = scope.launch {barrageStore.customMessageEvent.collect { event ->if (event is CustomMessageEvent.CustomMessageReceived) {val data = event.barrage.data ?: return@collectval json = JSONObject(data)if (json.optString("businessID") != "follow_trade") return@collect // 只处理跟单卡片// 校验 expireAt / KYC 等级 / 白名单后,渲染跟单卡片 UIrenderFollowCard(json)}}}// 退出直播间时 scope.cancel(),避免协程泄漏
// iOS (Swift / Combine):订阅自定义消息发布者private var cancellables = Set<AnyCancellable>()private lazy var barrageStore = BarrageStore.create(liveID: liveId)func startObserve() {barrageStore.CustomMessageEventPublisher.receive(on: RunLoop.main).sink { [weak self] event inif case .customMessageReceived(barrage: let barrage) = event {guard let d = barrage.data.data(using: .utf8),let json = try? JSONSerialization.jsonObject(with: d) as? [String: Any],json["businessID"] as? String == "follow_trade" else { return }// 校验 expireAt / KYC 等级 / 白名单后,渲染跟单卡片 UIself?.renderFollowCard(json)}}.store(in: &cancellables) // 由 cancellables 统一管理订阅生命周期}
观众端收到卡片后的处理流程如下:
1. 校验卡片有效期(
expireAt)、用户 KYC 等级与跟单白名单。2. 校验通过后渲染卡片 UI,展示主播胜率、跟单人数、币种与杠杆。
3. 用户点击卡片,唤起
deeplink 跳转至业务页确认下单,由业务系统完成撮合。4. 下单成功后,业务系统通过 发送自定义消息 广播成交回执,在弹幕区展示跟单结果。
跟单卡片自定义消息的 Body 结构示例
{"businessID": "follow_trade", // 消息类型,接收端据此过滤"version": 1,"extra": {"trader": {"uid": "trader_001","name": "Alice","winRate": 0.78,"followerCount": 12030,"kycLevel": 2},"trade": {"symbol": "BTC/USDT","side": "long", // 多头开仓;short 表示空头开仓"leverage": 10, // 永续合约杠杆倍数(仅适用于支持杠杆的产品类型)"entryPrice": "67890.5","size": "0.5","openTime": 1717477200000},"deeplink": "myapp://trade/follow?orderId=xxx","expireAt": 1717481000000 // 卡片有效期(毫秒时间戳),超期后客户端不再展示跟单按钮}}
弹幕投票 / AMA 互动
项目方在 AMA(Ask Me Anything)场景下经常需要让用户在弹幕中投票或提问。该能力基于 TUILiveKit 的 房间内发言之后回调 实现:观众在直播间发送的弹幕消息由 TUILiveKit 后台回调至业务后端,业务后端按关键词或格式筛选后进入投票 / 提问池,再聚合展示到 AMA 大屏。
整体流程如下:
1. 观众端在直播间发送弹幕(如
#vote A、#ask 问题内容)。2. TUILiveKit 后台通过 房间内发言之后回调,将弹幕消息内容回调至业务后端。
3. 业务后端按关键词或格式(如
#vote / #ask)匹配筛选,命中则进入投票 / 提问池,未命中则丢弃。4. 业务后端将投票统计或提问列表聚合后,展示到 AMA 大屏或主播端。
内容理解 / 云端审核
Web3与泛金融业务天然运行在强监管、资金强相关的环境中,易滋生荐股喊单、钓鱼链接、空投诈骗及涉政涉黄等违规内容,因此常需要对直播音视频流、直播间弹幕消息、直播间用户资料等进行内容理解与审核,以满足合规监管、保护用户资产与社区信任。
音视频内容理解
通过 TRTC 的 AI 内容理解功能,您可以将房间中每一个用户的音视频流进行云端切片并送至第三方服务商进行内容理解,无需客户端进行处理。依据您发起的云端内容理解请求,以及请求中提供的第三方服务商信息(您需要提前开通或购买第三方服务),通过 AI 内容理解接口,将云端内容理解任务中的音视频内容投递到第三方内容处理服务商进行处理。AI 内容理解服务整体架构如下,详细内容参见 AI 内容理解-功能介绍。

IM 云端审核
TUILiveKit 直播间弹幕消息和用户信息审核可以直接使用 IM 云端审核能力,此外还支持单聊审核、群聊审核、群资料审核以及群成员资料审核等。进入 IM 控制台 > 云端审核 开通云端审核服务后,默认为您开启了六大通用场景的审核功能,您也可以单击修改场景配置自定义调整或关闭审核场景及策略。更多 IM 内容理解场景策略及识别结果配置参见 配置审核场景和策略、配置审核结果。

IM / Push 开发实践
在 Web3与泛金融互动业务生态中,直播间内的实时互动(弹幕、点赞、礼物、行情 / 跟单广播)由 TUILiveKit(AtomicXCore)承担,IM / Push 则负责直播间之外的 KOL 社群运营、红包 / 转账、行情秒级触达、公众号与客户服务,是直播间外的通信核心基础设施。
直播间内互动:通过 AtomicXCore 封装的
BarrageStore / LikeStore / GiftStore 处理弹幕、点赞、礼物、行情 / 跟单广播,确保音视频与消息的高度同步(详见上文 业务核心功能开发实践)。直播间外通信:KOL 社群、智能客服、公众号、推送触达建议直接使用 IM / Push 实现,以获得更完整的即时通信功能支持。建议在 AtomicXCore 的 Store 体系之外,建立独立的 ChatService 模块,负责全局 IM 状态监听及非直播间维度的消息处理。
KOL 粉丝社群运营
KOL 粉丝群是 Web3与泛金融行业最核心的私域运营阵地之一。头部 KOL 往往拥有数百至上万个高活跃度社群,通过实时互动、行情分享和投资观点传播,持续提升用户留存与交易转化。典型运营场景包括:
直播预热与召回:开播前自动向目标社群推送预约卡片、倒计时提醒及直播链接,引导粉丝提前预约和准时观看,提升直播间流量与转化率。
行情资讯分享:通过自定义消息发送实时行情动态,支持携带 K 线缩略图、涨跌幅数据、研报摘要及外部跳转链接,帮助用户快速获取市场信息。
跟单与策略传播:将 KOL 当前持仓、交易记录或投资策略封装为可视化卡片,一键分享至社群,方便粉丝查看并跟随操作,增强社区信任感与用户粘性。
热点事件实时讨论:围绕 BTC、ETH 等主流资产价格波动、宏观经济事件、项目上线(TGE)、空投活动等热点话题,快速发起群聊讨论、投票互动和观点征集,提升社区活跃度。
活动运营与用户激励:结合签到任务、空投活动、积分体系、邀请奖励等运营玩法,持续提升用户活跃度和社区参与度,实现从关注到交易的转化闭环。
管理社群
社群(Community) 群类型,单个群最大可支持 100 万人,可满足用户规模快速扩张时的群人数容量需求。社群采用“社群 - 分组 - 话题(Community - Group - Topic)”的三级层级,支持成员分组与查看 / 发言 / 管理权限设置,适合超大规模粉丝运营与组织化协作。管理社群涉及的具体客户端接口请参考 社群管理、话题管理、话题消息。
资产橱窗
群聊右上角可配置“资产橱窗”入口,通过 群属性(Group Attributes)维护群与资产列表的映射关系。用户进入群聊后,可快速访问群主推荐的 Token、交易策略、Launchpad 项目、DeFi 产品、NFT 或运营活动页面,实现内容传播、社区运营与交易转化闭环。
卡片消息
KOL 在社群内分享当前持仓、交易记录或投资策略时,推荐将其封装为可视化卡片消息,更便于粉丝查看并跟随操作。该类卡片消息通过 IM 自定义消息(
TIMCustomElem)下发——使用 createCustomMessage(data, description, extension) 构建消息体,再调用 sendMessage 发送,群成员客户端解析后渲染为可视化卡片。步骤1:构造自定义消息体
以 KOL 分享一条策略 / 持仓卡片为例,
data 字段的 JSON 结构示例如下:{"businessID": "strategy_card", // 业务类型,接收端据此路由到对应卡片渲染器"kol": { "name": "Alice 投研", "winRate": "78%", "followerCount": 12030 },"strategy": {"title": "BTC 波段策略 · 回踩做多","symbol": "BTC/USDT","side": "long", // 多头;short 表示空头"leverage": 5, // 杠杆倍数(仅支持杠杆的产品填写)"entryPrice": "67200.0","pnlRate": "+4.2%" // 浮动盈亏(展示用)},"deeplink": "myapp://copytrade/follow?strategyId=stg_001", // 点击唤起 App 内跟单页"expireAt": 1773321389000 // 有效期(毫秒),超期后降级为纯文本}
步骤2:发送群自定义消息
步骤3:解析并渲染自定义消息
红包 / 转账最佳实践
红包与转账是 Web3与泛金融行业 App 实现新用户拉新与绑卡转化的有效工具,可用于引导未绑卡用户在提现前完成绑卡、提升用户在 App 内的资金沉淀、激活社群活跃度。方案支持一对一红包(单聊向一个用户发送)与群红包(群内多名成员参与领取)两种场景,核心思路是利用 IM 的自定义消息、消息变更与消息扩展能力,配合业务侧的红包系统与支付系统,完成红包的发送、领取、状态同步与通知全流程。详见 红包最佳实践。
整体架构
红包功能由四个核心组件协作,业务侧的红包系统是控制核心,红包业务的安全性与一致性由服务端保证。
组件 | 职责 |
客户端(发送方 / 接收方) | 发起发送红包 / 拆红包请求;渲染红包卡片 UI |
IM Service | 消息投递、状态更新、领取记录存储、领取通知推送 |
红包系统(业务自建) | 红包生命周期管理:创建、校验、拆开、金额计算 |
支付系统(业务自建) | 资金管理:扣款、转账、退款 |
核心数据结构
红包通过 IM 的自定义消息(
TIMCustomElem)承载,Data 字段的关键字段如下:字段 | 类型 | 说明 |
BusinessID | String | 消息类型标识,红包消息固定为 red_packet |
packet_id | String | 红包唯一标识。由红包系统在扣款成功后生成,并通过 REST API 写入自定义消息,使消息与红包绑定 |
money_amount | Number | 红包金额(一对一红包) |
best_wishes | String | 祝福语 |
cover | String | 红包封面图片 URL |
status | String | 红包状态: Unopened(未领取)/ Opened(已领取)/ None left(已领完) |
quantity | Number | (仅群红包)红包个数 |
total | Number | (仅群红包)红包总金额 |
random_amount | Boolean | (仅群红包)是否为拼手气红包(随机金额) |
群红包自定义消息
Data 示例:{"BusinessID": "red_packet","total": 2.00,"quantity": 3,"random_amount": true,"best_wishes": "新年快乐!","cover": "https://example.com/cover.png","status": "Unopened","packet_id": "rp_20260301_xyz789"}
核心机制:消息变更 + 消息扩展
红包方案依赖 IM 的两项关键能力,二者配合实现红包状态实时同步与领取记录分布式存储:
能力 | 用途(红包场景) | 单聊定位参数 | 群聊定位参数 |
消息变更 | 更新红包状态(Unopened > Opened > None left),修改后所有客户端可见 | From_Account + To_Account + MsgKey | GroupId + MsgSeq |
消息扩展 | 在不改原消息的前提下附加领取记录 KV,变更实时同步到所有客户端 | From_Account + To_Account + MsgKey | GroupId + MsgSeq |
注意:
受消息扩展数据容量限制,群红包最多支持 300 人领取。
发送消息时须设置
SupportMessageExtension 为 1,消息才支持扩展数据。一对一红包流程
1. 发送:客户端收集金额、祝福语、封面 → 红包系统调用支付系统扣款接口从发送方扣款至红包资金管理账户 → 扣款成功后生成
packet_id → 红包系统服务端以发送方身份通过 发送单聊消息 REST API 将红包作为自定义消息发出。2. 领取:接收方单击拆开 > 红包系统校验状态(是否已领、是否过期)> 调用支付系统转账接口将金额从资金管理账户转入接收方 > 转账成功后,红包系统服务端依次执行:通过 设置单聊消息扩展 REST API 写入领取记录、通过 修改单聊历史消息 REST API 将
status 更新为 Opened、通过 REST API 向发送方推送 XX 领取了你的红包通知。3. 详情页:展示封面、发送方、祝福语、总金额及领取列表,领取列表数据来源于消息扩展数据。
群红包流程
群红包与一对一红包整体一致,差异点如下:
发送使用 群内发送普通消息 REST API,
Data 增加 quantity / total / random_amount 字段。每位成员拆红包时,红包系统校验「是否有剩余 / 该用户是否已领」,拼手气模式在剩余金额中随机分配(常用二倍均值算法保证公平),最后一人获得剩余全部金额。
领取记录通过 设置群消息扩展 REST API 保存;全部领完后通过 修改群聊历史消息 REST API 将
status 更新为 None left。详情页对领取金额最高者标注「手气最佳」。领取人头像 / 昵称通过批量 获取群成员资料 接口拉取。
智能客服 Desk
Web3与泛金融业务的客户服务高度依赖智能客服,且对时效性、专业性要求高。在该类场景中,用户常有售前咨询、订单查询、纠纷处理、风险事件处理等诉求。本方案推荐基于腾讯云 智能客服(Desk)搭建智能客服,它将 AIChatbot(智能机器人)+ Live Agent(人工坐席)整合为一站式产品:机器人 7×24 自动应答高频问题、命中复杂或敏感场景时一键转人工,开箱即用、无需自建客服后台。
产品构成
Desk 由三个模块组成,分别面向终端用户、管理员与坐席:
模块 | 入口 | 职责 |
用户端 (Client) | 网页 / H5 / App(Web、iOS、Android UIKit) | 用户咨询入口,先由机器人接待,可一键转人工;支持文本、多媒体、卡片消息 |
管理端 (Management Panel) | 配置机器人知识库 / 任务流、会话流程与路由规则、服务模式、排队与工作时间、团队 / 角色管理、数据看板 | |
客服工作台 (Agent Workspace) | 坐席接待与结束会话、会话转接、主动发起会话、满意度评价、坐席内部会话 |
快速开通
步骤 | 操作 |
① 创建 Desk 应用 | |
② 体验客户端能力 | |
③ 进入工作台体验 | 在管理端点击「前往工作台」,以坐席身份处理转人工会话 |
AIChatbot 智能机器人
能力 | 说明 | Web3 / 泛金融用法 |
问答库 (Q&A Database) | 配置标准问题、相似问法与答案,支持手动新增 / 批量导入 / 编辑 | 交易费率、合约规则、KYC 步骤、充提币等常见问题 |
任务流 (Task Flow) | 多轮对话编排,按用户输入分步引导 | 引导式 KYC、找回账户、申诉流程 |
闲聊库 (Chitchat) | 应答问候与寒暄,提升体验 | 开场问候、等待安抚 |
问答优化 (QA Optimization) | 问题聚类、未识别问题归集,持续补全知识库 | 发现高频未覆盖问题并迭代 |
机器人提供两种模式:标准机器人(基于知识库精确匹配)与智能体(基于大模型自动作答、可处理闲聊)。若已自建 AI 或采购第三方大模型,可在管理端停用内置机器人并接入自有大模型;接入后 AI 与坐席会话打通,坐席转接后可查看 AI 对话历史。
人工坐席工作流
环节 | 说明 |
接待与结束会话 | 坐席接入排队中的用户会话并完成应答 / 结束 |
会话转接 | 复杂问题(纠纷、风控)转接至更专业的坐席或坐席组,由路由规则分配 |
主动发起会话 | 坐席可对指定用户主动发起咨询(如风险事件预警、KYC 催办) |
满意度评价 | 会话结束触发用户评分,沉淀服务质量数据 |
数据看板 | 管理端查看实时接待、会话分析、坐席绩效与历史会话(可导出) |
在 Web3与泛金融业务场景中,建议用 AIChatbot 承接标准化的售前咨询、KYC 引导、充提币状态查询等高频问题,并为转账纠纷、风控事件等敏感场景配置专属坐席组与任务流,命中即定向转人工,兼顾效率与合规。
公众号最佳实践
公众号为 Web3与泛金融业务提供面向订阅者的内容创作、精准运营与长期互动能力,弥补即时通讯在内容沉淀与服务延伸上的不足。公众号主可向订阅者推送图文内容并查看历史推文,用户订阅后自动获取更新并可与之互动。在 Web3与泛金融场景中,它适用于项目方公告、行情研报、空投与活动通知、合规披露、KOL 投研内容沉淀等。IM 提供三种公众号搭建形态,详见 公众号最佳实践。
形态对比与选型
对比维度 | 类微信公众号 | 类 WhatsApp Channel | 平台官方公众号 |
适用对象 | 开放给外部项目方 / 机构;商家端与用户端需拆为两个身份(两个 App 或双模式切换) | 开放给外部项目方 / 机构;同一 App / Web 内可同时拥有发布方与用户两种身份 | 仅搭建平台自有官方号,不开放给外部发布方 |
实现底座 | IM 原生公众号能力 | IM 社群(Community) | IM 原生公众号能力 |
管理功能 | 需自建发布方管理后台 | 需自建发布方管理后台 | |
消息互动 | 广播消息(一对多推文)+ 单聊消息(一对一私信) | 群聊消息(一对多推文)+ 表情回应(对推文贴 Emoji) | 广播消息 + 单聊消息 |
订阅规模 | 按公众号订阅人数计 | 单号 10 万 - 100 万(社群容量) | 按公众号订阅人数计 |
基于 Web3 App 常见功能特性,推荐采用“类 WhatsApp Channel 为主 + 平台官方公众号置顶”的双形态组合:
主体用类 WhatsApp Channel:承载 App 内绝大多数频道(项目方、KOL、机构),同一 App 内即可开号、单号10万 - 100万订阅、单向发布 + Emoji 回应,最贴合“项目方频道”形态。
官方资讯用平台官方公众号:平台自有的实时新闻 / 官方公告直接在控制台搭建、无需自建后台,作为 Feed 信息流中“置顶 / 加 V”的特权账号。
类 WhatsApp Channel 形态
该形态以社群(Community)承载公众号:创建公众号即创建一个 Community,用户加群即订阅,公众号主与管理员可发群聊消息(推文),普通订阅者仅接收并可用 Emoji 回应。单个公众号支持 10 万 - 100 万订阅者,适合 Web3 项目方 / 交易所在 App 内开设“项目方频道”。
公众号动作 | 底层实现 | 关键接口 |
创建公众号 | 创建 Community 社群( groupType=Community),并通过群自定义字段标记为“公众号”,区别于普通社群 | |
订阅 / 取消订阅 | 加入 / 退出社群;订阅后可用会话分组把公众号会话与普通聊天的未读分开展示 | |
获取公众号列表 | 拉取已加入社群列表,再按群自定义字段筛出标记为公众号的社群 | |
发布推文 | 公众号主 / 管理员调用群聊发送消息,支持文本、富媒体、自定义消息(如行情卡片、研报卡片) | |
订阅者互动 | 订阅者对推文进行 Emoji 表情回应 |
平台官方公众号形态
平台自有官方号无需开放给外部发布方时,可直接在 IM 控制台 创建、编辑、删除公众号并撰写 / 发布推文(支持图文 / 纯图 / 纯文字三类,可插入超链接、实时预览),无需自建管理后台。客户端集成基于 IM 原生公众号能力实现:
订阅 / 取消订阅:客户端调用
subscribeOfficialAccount / unsubscribeOfficialAccount,并通过 onOfficialAccountSubscribed 等监听器接收订阅、资料变更、销毁通知。收发消息:公众号通过 公众号用户发送广播消息 向全体订阅者推文;与订阅者的一对一私信,订阅者侧用
sendMessage(receiver 填公众号 ID),公众号侧管理员用 向单个用户发送单聊消息(From_Account 填公众号 ID、To_Account 填订阅者 ID)。推送服务 Push
Push 是一站式 App 消息推送解决方案,无需投入大量研发成本搭建基础设施,即可获得跨平台、高可靠的消息触达能力,保障消息在线和离线状态下稳定送达。在 Web3与泛金融场景中,Push 适用于行情秒推、空投预热、订单与到账提醒、风控告警、AMA 开播提醒等对时效敏感的场景,并提供全链路数据统计以评估触达与转化效果。

Push 核心价值
价值 | 说明 |
状态零维护 | 平台自动识别用户在线 / 离线状态,自建在线通道与厂商离线通道按默认全覆盖策略自动切换,业务无需自行维护用户状态系统 |
全球高可达 | 全球超3200个加速节点就近接入,配合自研最优寻址算法智能选路,有效降低跨境传输延迟与丢包,服务可靠性高于99.99% |
极速触达 | 依托长连接实现毫秒级精准下发,1000万条消息可在30秒内全部送达,保障行情、风控等关键消息第一时间抵达用户 |
极简集成 | 控制台下载并引入 JSON 配置即可一键打通各厂商通道,SDK 自动完成注册、Token 上报与数据统计;已覆盖 APNs、FCM、华为、荣耀、小米、OPPO、VIVO、魅族等全部主流离线通道 |
全端覆盖 | 一套能力统一适配 Android / iOS / Flutter / uni-app / React Native / HarmonyOS / Unity / Unreal Engine 等主流开发平台 |
合规可信 | 提供新加坡、雅加达、首尔、东京、法兰克福、硅谷、利雅得等多地境外数据中心可选,支持数据加密传输 / 存储、隐私合规与全球安全认证,满足全球化金融业务的合规要求 |
五种推送方式
Push 提供五种基础推送方式,覆盖从泛触达到精准定向、再到与业务消息深度耦合的全部场景。
推送方式 | 说明 | 典型用途 |
全员推送 | 面向全部用户的系统级触达 | 币价大涨预警、平台公告、版本更新 |
标签推送 | 按持仓 / 语言 / 地区等分群推送 | Market Alert 行情警报、空投预热、活动推送 |
指定 UserID 推送 | 批量定向推送给指定用户列表 | 风控告警、个性化运营、定向召回 |
IM 消息推送 | 即时通讯消息触发离线推送 | 私信、群聊、客服回复 |
音视频通话推送 | Call 通话呼叫触发推送通知 | AI 数字人面签邀请、KOL 1v1投顾呼叫 |
快速集成步骤
步骤 | 操作 | 关键说明 |
① 开通服务 | 获取 SDKAppID 与客户端密钥 AppKey | |
② 配置厂商通道 | 在控制台下载 JSON 配置文件并引入工程,一键完成 APNs / FCM 及各安卓厂商推送信息配置 | 插件自动完成注册、Token 上报与数据统计 |
③ 集成 SDK 并注册 | 引入 TIMPush,调用 registerPush(SDKAppID, appKey) 注册;成功后即可接收在线推送,并通过 getRegistrationID() 获取设备推送唯一标识 RegistrationID | RegistrationID 卸载重装会发生变化;如需与 IM 的 UserID 打通,可用 setRegistrationID(userID) 绑定 |
④ 发起推送 | 联调阶段可先指定 RegistrationID 做在线推送验证 | |
⑤ 点击跳转 | 建议在 Application / AppDelegate 启动时注册 |
说明:
全员 / 标签推送 API 调用频率为 1 次/秒,日调用次数免费版 / 体验版 10 次/天、专业版 100 次/天;单发推送 API 调用频率免费版 / 体验版 10 次/秒、专业版 30 次/秒,日调用次数不限。高频运营场景需提前评估套餐与频控。
推送触达效果追踪与全链路诊断
Push 提供完整的全链路数据可视化工具,覆盖从推送下发到用户转化的全生命周期。建议在生产环境中常态化使用以下能力:
能力 | 说明 | 价值 |
推送数据转化漏斗 | 按“可发送数量 → 发送数量 → 触达数量 → 点击数量”分阶段统计,并给出实发率 / 触达率 / 点击率 | 定位流失最严重的环节,针对性优化 |
推送记录查询 | 按时间窗口 / 任务 ID / 收发双方 UserID 检索历史推送(保留近7天) | 事后审计、问题复盘 |
消息链路查询 | 凭 Push ID / Task ID 对单条消息做“IM 服务器 → 厂商服务器 → 终端设备 → 用户点击”端到端追踪 | 快速解答“为什么这条没收到” |
推送折损分析 | 按“可发送数量 → 发送数量”、“发送数量 → 触达数量”分区间逐层归因(厂商驳回、Token 失效、通知栏关闭、用户卸载等) | 降低无效投递、优化成本 |
全生命周期数据统计 | 从推送下发到客户端展示与点击的完整指标,支持按厂商维度分类查看 | 结合业务数据评估 ROI |
推送问题排查工具 | 自动诊断接入与下发各环节问题,给出明确解决指引 | 降低运维投入 |
服务端可通过配置 全员/标签/单发回调 将推送结果实时回传至 App 业务后台。回调以
PushStage 字段区分“发送 / 触达 / 点击”三个阶段,并携带 TaskId、To_Account、PushPlatform 等字段,便于业务侧将推送链路与自有风控、转化系统打通做闭环归因。更多介绍详见 Push 数据统计。
Web3 实践:Market Alert 市场警报系统
Market Alert 是 Web3与泛金融业务的高频场景:币价异动、空投预热、风控告警、利率变动需要在秒级触达对应用户。它综合运用了前述的标签定向、服务端推送、离线兜底与转化追踪能力,端到端链路可按以下方式构建:
步骤 | 实现要点 |
① 行情接入 | 业务侧接入交易所 / 行情源 WebSocket,监听阈值规则(涨跌幅 / 成交量 / 链上事件,如大额转账、合约调用、空投开放) |
② 用户分类 | 基于 IM 标签 / 属性体系,按 持仓币种 / 自选股 / 语言 / 风险偏好 / 地区 进行多维分类 |
③ 推送下发 | |
④ 离线兜底 | 未上线用户走厂商离线通道;安卓未配置厂商证书的设备通过7天消息离线存储机制兜底 |
⑤ 转化回收 | Ext 携带业务标识(如 alert_id / campaign_id),客户端点击后回写转化日志,并结合推送回调形成完整数据统计链路 |
Web3关键术语说明
术语 | 英文 / 全称 | 本方案中的含义 |
Web3 | Web 3.0 | 基于区块链的去中心化网络范式,核心特征是用户自持资产与身份 |
CEX / DEX | Centralized / Decentralized Exchange | 中心化交易所 / 去中心化交易所 |
KYC | Know Your Customer | 实名认证流程,多数司法辖区对持牌业务为强制要求 |
AMA | Ask Me Anything | 项目方与社区 1:N 互动直播形态,常见于交易所、KOL、协议方 |
KOL | Key Opinion Leader | 关键意见领袖,社区中的内容创作者与意见塑造者 |
Meme Coin | Meme Coin | 起源于网络迷因或社区文化的加密货币(如 DOGE / SHIB),通常具有高波动与强社区属性 |
MemeFi | Meme + DeFi | 在 Meme Coin 基础上叠加质押、收益共享、治理等 DeFi 能力的形态 |
LiveFi | Live + Finance | 与直播深度结合的金融化玩法(如直播打赏、直播跟单、直播链上互动) |
GameFi | Game + Finance | 游戏化金融,“边玩边赚”形态,常以 NFT 资产 / 代币奖励驱动 |
NFT | Non-Fungible Token | 非同质化代币,每枚具有唯一性,常用于数字收藏品 / 凭证 / 身份 |
SBT | Soulbound Token | 灵魂绑定代币,不可转让的链上身份与成就凭证 |
POAP | Proof of Attendance Protocol | 参与凭证协议,常作为活动 / 直播参与的链上证明 |
Tokenomics | Token Economics | 代币经济学,包含发行总量、分配、释放节奏、销毁、激励等设计 |
Smart Contract | Smart Contract | 智能合约,部署在区块链上的可自动执行代码 |
On-chain Reputation | On-chain Reputation | 基于钱包地址公开行为(交易历史、协议交互、合约部署等)综合评估的可信度,常用于空投资格判定 |
Airdrop | Airdrop | 项目方将代币 / NFT 免费分发给目标用户的拉新与激励手段 |
Stablecoin | Stablecoin | 与法币(多为 USD)锚定的加密货币,如 USDT / USDC / DAI |
Custodial Wallet | Custodial Wallet | 私钥由平台代为保管的钱包,常见于交易所内置钱包 |
Social Trading / Copy Trading | 社交跟单 / 复制跟单 | 订阅信号源主播策略并自动复制下单的交易形式 |
txHash | Transaction Hash | 链上交易的唯一标识,可用于跨端校验与审计 |
Confirmations | Confirmations | 区块链对一笔交易的累计确认次数,确认数越高交易越不可逆 |
说明:
本术语表仅作为概念对齐参考,不构成投资建议或合规结论。Meme Coin、MemeFi、LiveFi、GameFi、衍生品跟单等形态在不同司法辖区的合规要求差异巨大,上线前建议咨询当地法务合规团队。