需求背景：
1.用户一次送礼会依次产生三个动画效果;
2.一次送礼产生的三个动画效果需要按顺序依次播放；
方案一：
1）PCEffectDataQueueManager创建四个PCEffectDataQueue数据队列，分别对应simpleFloat，seatEffect，bigAnim，globalFloat四种动效播放类型。管理一次送礼消息按顺序依次展示四种动效播放。当有一次送礼消息的四个动效没有播放完成，收到新的送消息时，缓存到PCEffectDataQueueManager自带的送礼消息缓存队列。
2）FBPartyEffectWidget创建四个不同播放效果的播放器xxxPlayerPresenter，根据特效播放类型建立与上面四个数据队列的一一对应关系；将PCEffectDataQueueManager通过注册的方式，实现四个播放器PlayerPresenter的每次动效播放完成监听。
3）PCEffectDataQueue接收到数据后，发出该数据队列有新数据的通知。PlayerPresenter监听到该通知，pop出第一个特效数据播放。PlayerPresenter播放完特效通过dispatchPlayFinished通知告知PCEffectDataQueueManager层特效播放完成。
4）FBEffectDataQueueManager收到某个播放器特效播放完成的通知，根据该通知数据携带的transactionId，查找缓存的送礼消息，根据业务播放策略顺序将该送礼消息插入下一个动效类型的播放队列。如果该送礼消息没有待播放的动效类型，移除该送礼消息，开始处理缓存的下一个送礼消息。
方案二：
根据房间模式（游戏、语聊），将收到的特效数据按照类型拆分到各自的队列中
各特效队列作为数据存储，等待业务层调用获取数据
保存生命周期内接收到的所有特效事务ID，入队前进行ID去重操作，保证特效播放唯一性
业务模块层
播放器基础逻辑
依据当前特效类型拆分，包含麦位特效、弹道特效、礼物特效三个基础播放器逻辑
特效相关视图由播放器单独持有，并控制视图进行播放操作
每一个特效播放器，启动时默认为休眠状态，等待队列数据更新通知，循环拉取队列数据并播放
特效播放器具备播放数据间的优先级控制、播放行为挂起、停止并清除当前播放特效视图开放接口
组合特效播放器
何为组合？定义为基于基础特效数个组合，并要求特效之间顺序播放为组合特效
满足播放器基础逻辑的3、4点，考虑与其他播放器自同一父类衍生
逻辑实现基于对当前的所有基础特效播放器进行控制（基于播放器开放接口）
依据组合特效的播放顺序，控制对应播放器的行为，达到组合特效的播放效果
总结：
方案一：center层按照四个播放业务类型创建四个缓存数据队列。widget层按照四种播放业务类型创建四个播放器。四个播放器根据不同播放类型分别建立到四个缓存数据队列监听。按照生产者----（数据队列）-----消费者 模式，从数据生产者层面进行消费者数据来源的解耦合。实现一个消费者只依赖一个数据队列的单一流向，按照MVC的思想PCEffectDataQueueManager作为控制层C，通过DataQueue给View层xxxPlayerPresenter提供数据， UI层的数据流入永远只依赖一个入口，逻辑简单清晰，易于维护
方案二：center层按照四个播放业务类型创建四个缓存数据队列，同时创建一个combine的数据队列。widget层按照四种播放业务类型创建四个播放器，同时创建一个combine特效播放器。四个播放器根据不同播放类型分别建立到四个缓存数据队列监听。
通过combine播放器监听combine数据队列的数据，分析特效类型，分别插入seatPlayer，pagPlayer，globalPlaert播放器播放。 从方案二的架构图，可以看出，麦位播放器，pag播放器，全局飘屏播放器，三个消费者都依赖两个数据源流入。另外，当消费者在播放其数据队列中的数据时。combine播放器有数据需要播放时，需要在消费者中缓存该从combine播放器流入的数据。等待队列数据播放完成，再决定播放combine流入的数据，相当于一个消费者（播放器）依赖两个数据队列的数据来源，按照MVC的思想，xxxPlayerPresenter属于UI层，一个UI层依赖两个C层控制的数据流入。造成xxxPlayerPresenter不再是单纯UI层，他里面一定需要完成两个C端流入数据的处理决策，逻辑复杂，难于维护
