版本记录

前言

这几年一直在做直播类和音视频相关的APP，APP运营的根本其实不外乎在于盈利，在直播类APP中很重要的一块就是礼物系统，这个地方和收益相关，可以说和主播以及公司的利益都有很大关系。下面就简单的说一下礼物系统。

礼物系统的地位

礼物系统是很大的一部分，是公司收益的重要一环。所以礼物系统的好坏影响很大，不仅影响用户的使用体验，还直接影响到了公司的收益。

礼物面板的搭建

这里大家可能觉得这有什么好说的，无非就是视图的搭建，但是，这里我还有几点需要说明：

• 关于视图的搭建，有的人喜欢用纯代码，有的人喜欢xib，我推荐的就是xib，不仅可以省很多工作量，而且出问题的时候可以快速定位，如果是纯代码，是不会有这种直观的感受的，想找个控件具体在哪里，要是纯代码而且视图还很复杂的情况下，那种感觉你懂得，夸张一点就是：找的过程花了一小时，修改bug用了1分钟。

• 可扩展性：一定要注意视图封装的可扩展性，这一点当你长时间的维护礼物系统，一年或者几年的时候，你就会深有体会。比如开始上一个A分类的礼物，后来产品增加了需求，又上了一个B分类的礼物，这个时候如果你在完成A类型的礼物的时候写死的话，那么在完成B分类的礼物的时候就没那么方便了，这个时候你就会乖乖的写成动态更改的了。这种情况在你网络层请求代码以及缓存的逻辑中一样存在，具体会在后面碰到的时候说明。

礼物系统的结构

从APP启动到呈现给用户，其实礼物系统从大处看可以分为两个部分，分别为礼物下载更新模块和礼物渲染和显示模块，具体如下图所示：

• 礼物下载更新模块

  • 主要是对大礼物的资源包的下载和解压，这里涉及到下载时机，更新时机以及解压的错误处理等，后面会详细的说明。

• 礼物渲染显示模块

  • 包括各种不同类型礼物，呈献给用户的方式也不同，这里涉及到缓存、复用和性能问题，后面会详细的说明。

礼物下载更新模块

1. 礼物类型

对于礼物来说，如果是小礼物，比如下面这种效果：

这种小礼物展示几秒就消失的，不用管下载逻辑，可以利用SDWebimage对其进行下载和管理，毕竟类似这种小的icon下载不会很慢，怎么都比视频中一帧图像要小很多吧。而且在拉去礼物面板的时候，SDWebimage已经对这个小的icon进行了下载并进行了缓存，所以在直播间里面显示这种礼物效果都是不用进行下载的，直接框架就从你内存里面拿了。

但是如果是大礼物，也就是序列帧礼物，比如下面这个：

那么这种大型序列帧礼物就需要下载礼物包进行大礼物效果渲染播放了。

2. 关于礼物更新的几个问题

这里说的礼物更新只针对大型礼物，对于小礼物不涉及到更新问题。

关于礼物更新有几个问题：

• 什么时候更新?
• 更新时，从服务端获取的是什么类型的文件？
• 下载完成后，如何解压以及解压后的文件如何命名？
• 下载或解压失败的情况下，如何进行再次更新？
• 当有新的礼物或者旧的礼物更改素材的时候，如何进行实时更新？
• 礼物包是以HTTPS协议下载还是HTTP协议？

下面就针对这几个问题进行说明。

什么时候更新?

这个就是不同人有不同的想法了，我们iOS是每一次启动APP就会进行判断。将本地存储在disk中的礼物列表拿出来，放在内存中，然后拉取目前的服务端的礼物列表大版本，如果和内存中对应的字段相对的值不相同，那么就说明需要拉取礼物列表了。所以这里涉及到一次接口的请求。

如果需要请求礼物列表，那么就拉取礼物列表，找到其中大礼物，并进行下载。那么对于每个大礼物都要再次下载和更新吗？当然不是，可以在下载前，将礼物id和礼物的version拼接成一个独有的字符串，然后在disk中进行查找，如果本地有这个文件夹说明该礼物就没有更新，就不用进行下载更新，如果没有这个文件夹就说明需要进行下载压缩包更新了。

如果不需要请求礼物列表，那么就只需要从内存中取模型，进行渲染和使用就可以了。

可能有人要问？为什么要启动时候就进行检测和下载压缩包？其实还是用户体验的一个问题，如果是点击礼物按钮或者进入直播间才开始下的话，尽管正式环境有CDN加速，但是当礼物很多的时候仍然要下载很久，如果这个时候有人送大礼物，那么客户端还没下载下来素材，就没办法进行渲染和显示效果了。

更新时，从服务端获取的是什么类型的文件？

建议是Zip等格式的压缩文件。

考虑到大型礼物数据量一般都很大，所以，都是要进行压缩，从服务端下载压缩包的。这里还需要考虑的就是不同平台对压缩包进行压缩框架的性能问题，iOS比较常用的就是SSZip那个框架对Zip文件进行解压等处理。

下载完成后，如何解压以及解压后的文件如何命名？

对于如何解压这个问题，就要看平台（iOS还是Android）以及它们的框架了，我们iOS用的就是SSZip框架对下载的Zip文件进行解压。

解压后的文件如何命名呢？

这个不是随便命名的，这个建议是以giftID，或者以giftID和该礼物的version组成的一个唯一的字符串。为什么要这么做？因为要以它进行寻址，来判断disk中是否有最新的文件，以及是否需要下载该礼物包。所以说，这么命名很关键，不能随便命名，整个都是逻辑中重要的一环。

下载或解压失败的情况下，如何进行再次更新？

下载或者解压失败会首先删除disk中不完整的zip包，然后在礼物下载逻辑manager中标记一个isHasFailed的BOOL值，然后系统每12分钟轮询服务器礼物版本，isHasFailed值别标记为YES后，就会重新下载礼物包。

在下载礼物包后，也会根据礼物id遍历礼物存储的disk文件夹，清除不要的文件夹，防止无用文件占用太多的磁盘空间。

当有新的礼物或者旧的礼物更改素材的时候，如何进行实时更新？

根据APP启动是查询版本，或者12分钟轮询一次进行查询，查找本地disk是否有对应的文件夹，如果没有就进行更新和下载。

礼物包是以HTTPS协议下载还是HTTP协议？

苹果规定2017年开始，所有上架的APP都使用HTTPS，但是礼物列表是服务端下发的，礼物包的地址可以是HTTP也可以是HTTPS，哪种比较好呢？

其实，这两种方式我都尝试过，各有优缺点：

• HTTPS

  • 优点：安全
  • 缺点：下载礼物包很慢而且失败率很高

• HTTP

  • 优点：下载速度快
  • 缺点：不安全，特别我们公司的产品要经过安全审查的，过不去安全审查的很难上架。

最后，我们从用户体验的角度出发，只能弃用HTTPS，使用HTTP下载礼物包，但是APP内部其他请求都是必须要老老实实走HTTP吧。

礼物渲染显示模块

1.小礼物的渲染显示

礼物显示模块包括大礼物和小礼物的显示，对应的就是两种不同的礼物类型。对于小礼物，就是从左向右的进入屏幕，具体效果前面已经说过了。

对于这种类型就是封装两个视图，然后布局两个弹道，每一个弹道定义一个属性isAvailable，然后顶一个小礼物队列，收到直播间礼物消息后，加入这个队列，然后哪个弹道isAvailable == YES，就哪个弹道开始显示礼物。

对于礼物视图的封装也没什么说的，里面对应图片的下载其实就是用SDWebImage就可以了，图片数据量很小不会影响视觉效果。

2. 大礼物的渲染显示

这个是很关键的一部分，因为大礼物比较贵，效果看起来也很炫，你不能让用户花了很多钱送个礼物看不到很好的效果，这样子满足不了客户的需求，慢慢你的产品也就Over了。

大礼物采用的是序列帧动画，具体还是维护一个大礼物队列，收到大礼物消息加入到队列中，然后根据礼物id在本地查找对应的disk文件夹，这个文件夹中包含两个文件，一个是.ini的配置文件，里面给出了显示位置，帧数等等数据，另一个是包含所有序列帧的文件夹。

在显示时，首先在礼物id对应的文件夹中找到是否有.ini文件，如果没有就说明是错误的或者文件夹不全，不能播放序列帧文件。找到配置文件，就会根据配置文件解析并加载对应的序列帧文件，就播放了大礼物。

后记

本篇主要讲述了礼物系统的组成，包括礼物下载更新模块以及礼物渲染显示模块，感兴趣的给个赞或者关注，谢谢~~~~