本文5千字,围绕社交类App的产品,对常见的9个方面的设计要点和原理,进行摘要分享。
社交App设计「音效」实现机制
在社交过程中,音效的加入,让事情变得有趣、及时。
QQ的咳嗽声和消息通知是否勾起了回忆呢?
以App「SOUL」的匹配按钮为例,匹配中有音效,匹配成功,也会有个音效。
那么音效的实现是怎样的机制呢?
是不是在后台配置音频文件,通过点击按钮调用呢?
实际上,一般不需要在后台存储音频文件。
一来是因为音效变动不大,你看QQ的加好友的咳嗽声用了那么多年。
所以在客户端写死并不影响实际需要。
二来牵扯到触发后,对交互的时效性要求较高。
因为音频文件会比图标大很多。
以「SOUL」为例,本来已经匹配到用户了,如果因为网速等导致了延迟,迟迟没有发出匹配成功的声音,那就尴尬了。
所以使用音效,一般音频文件,都是放在前端的。
至于文件压缩和音质,就是个筛选的过程。
「聊天」发表情,是怎样的机制
社交聊天,就需要发表情。
在微信发一个表情出来,你发现显示的是名称[调皮],而不是一个图标。
收到表情的一方,退出到聊天信息总列表,显示的也是[调皮]。
那么为什么不是直接放一个表情在上面呢?
实际这与实现原理有关系。
当发表情给对方的时候,实际上发的是这个表情对应的ID——>服务器拿到这个ID之后,再传给接收方的客户端——>接收方收到,再解码出一个表情,展示在客户端。
用图示如下:
因此,表情的发送,是发送给服务器一个对应ID,而不是直接发送表情文件给对方的。
所以表情文件(图文件)需要存在各自的客户端,而不需存在服务器。
此外,客户端还要存表情名称和ID。