腾讯IM音视频通话开发日记:从TUIKit配置到双机联调的全记录(uniapp版)
最近在做一个需要即时通讯和实时音视频功能的跨端应用,选型时重点考察了腾讯云IM。官方提供的TUIKit和TUICallKit组件库,号称能大幅降低开发门槛。但真正上手时,我发现从基础聊天到音视频通话的完整链路,尤其是那些官方文档里一笔带过、却能让新手卡壳的“魔鬼细节”,才是决定项目能否顺利落地的关键。这篇日记,就记录了我从零开始,在uniapp框架下整合这两大组件,并最终实现双机真实联调的完整过程。如果你也打算用这套方案,希望我的踩坑和填坑经验能帮你少走弯路。
1. 项目初始化与TUIKit基础集成
万事开头难,但一个好的开始能避免后续无数麻烦。我选择从创建一个全新的uniapp项目开始,这能确保环境纯净,避免与旧项目依赖冲突。
第一步是创建项目。 在HBuilderX中新建项目时,我遇到了第一个选择:Vue2还是Vue3?官方TUIKit的uniapp版本明确要求使用Vue3。我起初不信邪,用Vue2创建了一个项目尝试导入,结果在编译阶段就遭遇了各种奇怪的语法错误和兼容性问题,折腾半天无果。所以,第一个铁律:请务必选择Vue3版本创建uniapp项目。这不仅仅是版本号不同,其底层的响应式系统和生命周期管理都与TUIKit组件深度绑定。
项目创建好后,按照腾讯云IM官方文档的指引,通过npm安装@tencentcloud/chat-uikit-uniapp。这里有个小技巧:安装后,最好在package.json里锁定一个稳定的版本号,避免后续因自动升级导致不可预知的问题。
{
"dependencies": {
"@tencentcloud/chat-uikit-uniapp": "^0.1.3" // 示例版本号,请以实际最新版为准
}
}
接下来是核心的初始化配置。你需要在腾讯云IM控制台创建一个应用,获取到至关重要的SDKAppID。此外,还需要生成一个UserID和一个UserSig。UserSig是用户登录鉴权的凭证,其生成涉及密钥计算,绝对不能在客户端明文硬编码密钥。对于开发测试,腾讯云提供了在控制台临时生成UserSig的功能,但这仅限于调试。正式环境必须由你的业务服务器按照相同算法生成并下发给客户端。
初始化代码通常放在App.vue的onLaunch生命周期中:
import { TIM, TIMUploadPlugin } from ‘tim-js-sdk’;
import { TUIStore, StoreName } from ‘@tencentcloud/tui-chat’;
export default {
onLaunch() {
// 1. 创建TIM实例
const tim = TIM.create({ SDKAppID: 你的SDKAppID });
// 注册文件上传插件(用于图片、文件消息)
tim.registerPlugin({ ‘tim-upload-plugin’: TIMUploadPlugin });
// 2. 登录IM
tim.login({
userID: ‘testUser001’,
userSig: ‘生成的UserSig字符串’,
}).then(() => {
console.log(‘登录成功’);
// 3. 初始化TUIStore,将TIM实例与UI组件库关联
TUIStore.initStore();
TUIStore.update(StoreName.USER, ‘tim’, tim);
TUIStore.update(StoreName.USER, ‘userID’, ‘testUser001’);
}).catch(error => {
console.error(‘登录失败:’, error);
});
}
}
完成这些,一个具备基础文字、图片、表情聊天功能的页面其实就已经准备好了。你可以在需要的页面引入<tui-conversation>、<tui-chat>等组件,快速搭建起聊天界面。
注意:真机调试时,如果遇到页面能显示但搜索不到用户、无法发送消息的情况,请首先检查网络环境。确保测试手机的网络能正常访问腾讯云IM服务。此外,确认登录的UserID在同一个SDKAppID下,并且已经相互添加为好友(或加入了同一个群组),因为单聊需要好友关系。
2. 跨越云端插件与自定义基座的门槛
基础聊天跑通后,我迫不及待地想接入音视频通话能力。这就是TUICallKit组件登场的时候了。然而,从TUIKit到TUICallKit,并非简单的“安装即用”,中间横亘着两道对于uniapp开发者来说可能比较陌生的关卡:云端原生插件和自定义调试基座。
第一关:购买与绑定云端插件。 uniapp为了实现某些原生能力(如这里的高性能音视频采集渲染),采用了“云端插件”机制。当你按照文档引入TUICallKit并运行时,控制台很可能会报错,提示“模块未绑定”或直接引导你到一个购买链接。
- 购买插件:你需要前往DCloud的插件市场,搜索“腾讯云音视频插件”。通常会有免费试用版(如7天试用),用于开发测试完全足够。点击购买并选择“免费试用”。
- 关键步骤:绑定应用信息。这是最容易被忽略的一步!购买插件后,必须登录DCloud开发者后台,在“我的插件”列表中找到刚购买的腾讯云音视频插件,进行“绑定应用”。
- 你需要填写当前uniapp项目的
AppID(在HBuilderX项目manifest.json中可见)。 - 对于Android平台,还必须填写Android包名(Bundle Identifier)。这个包名需要与后续你在腾讯云IM控制台配置的Android推送证书包名,以及最终打包APK时使用的包名完全一致。
- 你需要填写当前uniapp项目的
提示:包名最好在项目开始时就规划好,采用反域名格式,如
com.yourcompany.yourapp。在manifest.json-> “App常用其它设置” -> “Android设置”中可以进行配置。
第二关:制作自定义调试基座。 为什么需要这个?因为标准运行基座不包含你刚购买的第三方原生插件。只有制作了“自定义调试基座”,才能将插件代码打包进去,在真机调试时调用原生音视频能力。
操作路径在HBuilderX的菜单:运行 -> 运行到手机或模拟器 -> 制作自定义调试基座。
这个过程会进行云端打包,耗时几分钟。制作成功后,下次真机调试时,HBuilderX会自动使用这个包含了音视频插件的基座进行安装和运行。
这里有一个我踩过的“巨坑”:务必在制作自定义基座之前,完成上述插件的应用绑定。如果你先制作了基座,再去绑定插件,那么已制作的基座里仍然没有插件代码,导致音视频功能依旧无法使用。正确顺序永远是:购买插件 -> 绑定应用AppID和包名 -> 制作自定义调试基座。
3. TUICallKit的接入与企业认证须知
闯过前两关,代码层面的接入反而相对清晰。通过npm安装@tencentcloud/call-uikit-uniapp,然后在项目入口或主聊天页面进行初始化。
初始化TUICallKit需要传入TIM实例(与TUIKit共用同一个),以及一些基础配置:
import { TUICallKit } from ‘@tencentcloud/call-uikit-uniapp’;
// 假设tim实例已从TUIStore中获取
const tim = TUIStore.getData(StoreName.USER, ‘tim’);
const tuiCallKit = new TUICallKit({
sdkAppId: 你的SDKAppID,
tim: tim, // 传入已登录的tim实例
userId: ‘当前用户ID’,
userSig: ‘当前用户Sig’,
// 其他可选配置,如是否开启美颜、默认摄像头等
});
接入后,TUICallKit会自动监听来自聊天界面的音视频通话请求(通常通过自定义消息实现),并弹出接听界面。你也可以在代码中主动发起呼叫:
// 发起一个1对1视频呼叫
tuiCallKit.call({
userId: ‘目标用户ID’, // 被叫方UserID
type: 1, // 1: 视频通话,2: 语音通话
});
一个至关重要的前提:企业认证。 在兴致勃勃地准备测试通话时,你可能会发现呼叫无法成功,控制台提示权限不足。这是因为腾讯云IM的音视频通话能力,仅对完成企业认证的账号开放。个人认证账号只能使用基础IM功能。
- 如何认证:登录腾讯云控制台,进入账号中心,找到“企业实名认证”。按照指引填写企业信息(营业执照等)即可。对于中小团队或个人开发者,好消息是企业认证本身是免费的。
- 开通音视频服务:完成企业认证后,在IM控制台你的应用详情里,找到“功能配置”->“音视频通话”,点击开通。这里同样有免费试用套餐可供开发阶段使用。
完成这两步,你的应用才真正获得了发起和接收音视频通话的“门票”。
4. 双机真实环境联调实战
所有配置就绪,最后一步就是验证功能是否真的能在两个独立设备上跑通。模拟器对测试UI流程有用,但音视频的采集、编码、网络传输、解码、渲染全链路,必须在真实手机上进行联调。
我的测试方案是:准备两个独立的测试UserID,并打包成两个不同的APK进行安装测试。
步骤一:准备测试用户。
在腾讯云IM控制台的“用户管理”中,我创建了两个用户:User_Lily和User_Leo。分别记录下他们的UserID。为了生成各自的UserSig,我写了一个简单的Node.js脚本放在本地,输入UserID即可输出对应的测试用UserSig(仅用于开发测试)。
步骤二:差异化打包。 我们不能在同一个APP里动态切换登录用户来模拟两个客户端。更真实的方法是打包两个应用,每个应用内置不同的登录信息。这里有几种思路:
- 使用HBuilderX的“环境变量”:创建不同的运行配置文件(如
dev_lily、dev_leo),通过process.env.UNI_APP_MODE来区分,并在代码中根据环境变量加载对应的UserID和UserSig。 - 更直接的临时方案(适用于快速测试):直接修改源码中的登录信息,分别打包两次。虽然笨,但对于验证核心功能最快。
以修改源码为例:
- 第一次打包:将
App.vue中的登录代码里的userID和userSig改为User_Lily的信息。通过HBuilderX的“发行”->“原生App-云打包”,生成app_lily.apk。 - 第二次打包:修改为
User_Leo的信息,重新云打包,生成app_leo.apk。
步骤三:安装与测试。 将两个APK分别安装到两部实体手机上。确保两部手机连接的网络质量良好(建议使用同一Wi-Fi,以排除复杂网络环境干扰)。
- 同时打开两个APP,它们会自动登录各自的账号。
- 在APP的聊天界面(如果已实现),确保两个账号已是好友。或者,TUICallKit也支持通过UserID直接呼叫。
- 在
Lily的手机上,向Leo发起视频呼叫。 - 观察
Leo的手机是否立即响起铃声并弹出接听界面。 - 接听后,观察双方画面和声音是否清晰、流畅、低延迟。
测试要点记录表:
| 测试项目 | 预期结果 | 可能的问题与排查方向 |
|---|---|---|
| 呼叫发起 | 主叫方界面显示“呼叫中”,被叫方立即响铃 | 被叫方无反应:检查网络、检查TUICallKit初始化、确认被叫UserID正确、确认音视频服务已开通。 |
| 音视频接通 | 双方进入通话界面,看到本地预览和远端画面 | 黑屏:检查摄像头权限是否授予。只有一方有画面:检查网络上行/下行带宽。 |
| 音频质量 | 双方声音清晰,无严重杂音或回音 | 声音小或杂音:检查麦克风权限,测试环境是否嘈杂。回音:建议佩戴耳机进行测试。 |
| 挂断功能 | 点击挂断按钮后,双方均退出通话界面 | 一方挂断后另一方界面卡住:检查通话状态监听事件是否正常处理。 |
| 前后台切换 | 通话中切换到手机后台,通话应保持 | 切换到后台后通话中断:检查App的“后台运行”权限是否开启,对于iOS需配置VoIP后台模式。 |
通过这样一次完整的双机联调,你不仅能验证功能,更能切身感受通话的实时性和画质,这是开发过程中不可或缺的一环。当我第一次在两部手机上看到实时互通的画面时,之前所有的配置麻烦都觉得值了。整个过程的核心,与其说是编码,不如说是对云服务配置、原生插件机制和调试流程的精确把握。把这些关节打通,一个功能完备的即时通讯加实时音视频应用,真的可以在uniapp框架下高效地构建起来。
664



被折叠的 条评论
为什么被折叠?



