我司持续了三年的音视频聊天,一直都是以拨打方付费,接听方收费的模式运营,并且是稳定运营了3年,然而,今年开年以来,产品定位疯狂转型,导致业务迭代让人猝不及防.这里讲一下,让后来人在做这块的时候,代码多留点拖展
分钟付费
苹果审核是不允许每分钟收费的音视频通话业务存在的,这个是明确规定,这里也不好细说我司的策略,只是给大家提个醒,不要想着跟苹果刚这个业务,不可能的,刚一百遍死一百遍.还有随机陌生人聊天匹配,是会被认为"聊天轮盘",也是过不了的,不过不知道为什么 Soul 确实能过,我猜是在陌生人这块儿动手脚.
音视频增加接听方付费
今年早春突然由拨打方付费变成了有可能为接听方付费逻辑,好在扣费逻辑一直是由后端处理,但是以前的 UI 逻辑,挂断逻辑,发消息逻辑,都是以 isCallMode 处理,在这版改版下,增加类似isPayMode字段,相应逻辑需要修改成由该字段控制,这版改的有点多的,因为动的代码范围算是比较广的
音视频增加匹配模式
女用户可以一直坐麦,等待匹配到男用户,这里动的是初始化逻辑,以前一直是弹等待,可挂断页面,现在增加了初始化小窗逻辑,这块动的也很多,主要是匹配模式下,产品需求增加一个他人列表可看见推流页面,这里就需要业务在坐麦 startPreview 同时,还需要推流,所以,需要预创建一个agora房间,加入房间后先推流,等匹配到某个男用户的时候(由男用户创建好一个频道),女用户离开当前频道,并加入男创建的频道,这里的逻辑算是比较最复杂,相当于在1v1中增加了直播业务功能.不过这个业务也没持续太久,产品动了刀子又把它割掉了~~~
ps: 顺便提一句,我们公司虽然是走1v1陪聊,直播等业务,但是好的一点就是,产品风控一直比较严格,机审人审都有
音视频增加关闭摄像头拨打
产品提出的这个业务,涉及到初始化local 和 remote 大小窗问题,大小窗我们之前一直默认双方开摄像头呼起的,这块也动了初始化的摄像头 UI 逻辑,安卓做这块的时候已经定下来通过 IM 走初始化,由拨打方通过 IM 告诉接听方,初始化是关闭着摄像头呼起的,那时做感觉也没问题,也就这样先坐下来算了
音视频增加关闭摄像头接听
然后,仅仅过了不到一个月,产品又增加了音视频增加关闭摄像头接听功能,这时候自己挖的坑就来了,之前还觉得音视频应该不会有关闭摄像头接听功能,这里立马打我的脸.接听的时候,如果接听方选择关闭摄像头接听,但是这个消息拨打方是不知道的,导致初始化 UI 页面不一致 A->B,B 选择关闭摄像头,A 初始化时不知道 B 关闭了摄像头,导致初始化时设置了 remoteView 白屏,悔不当初,悔不当初.接下来,只能选择补救方案.
- 1,重构初始化 localView 和 remoteView 逻辑,完全由 agora 控制,通过远程首帧回调,判定对方开启摄像头,本地逻辑本地控制,默认认为对方没有开启.
- 2.通过 IM 回传,接听方选择接受拒绝的时候,我们是通过 自己的 IM 控制,当初在设计这个消息的时候,并没有设计 ext 字段,仅在消息结构外层定义 actionType 判断接听或者拒绝,这里没办法,直接拖展 ext 字段,将是否关闭摄像头字段放到 ext 里.这也算当初的设计缺陷.
考虑到时间问题,业务确实比较赶,所以现在准备采用的方案是2.
讲完这些,只是想给大家提供下我做音视频遇到的坑,设计音视频框架的时候不要定死了某些业务.你能想到,做了3年的产品,在短短两三个月内,业务变更如此迅速.
