点击礼物按钮？
ChatView向左移动、底部BottomView向下移动，礼物选择界面向上移动
选择礼物确认送礼？点击屏幕取消送礼？
礼物界面的向下移动，ChatView向右移动、底部BottomView向上移动
点击倒计时按钮？
点赞的View上显示,等级 名字 送给主播：【黄瓜】X100，当然每点击一次就发一条消息，不过这个消息有些特别，比如说，内容完全不能少，但是我得把消息类型变成一个6点赞的那种，可是这样又不能发送礼物了呢，但是可以这样，给消息类型为6的处理方法里添加判断，比如说如果是giftID和giftNum都不为0，就是单机版的连击礼物，这时候需要做两件事情：第一就是将这条消息变成一个侧弹动画，第二就是将侧弹动画的调用次数记录下来，这个侧弹动画的调用次数就是连击的次数。还记得么，当初过滤服务器消息的时候，如果我判断这是个我自己的礼物消息，直接就return了，意味着我本地必须发一个一模一样的礼物消息，然后逻辑根据我本地发的礼物消息去处理动画，可是我现在遇到问题就是说，我的动画是严格与消息相关的，20个黄瓜礼物无论你是20个礼物消息，还是一个消息20条黄瓜，我都能处理。对于本地来说，20个黄瓜礼物我是分20条消息发还是一个消息发20条黄瓜是有区别的，这个区别就是出现的时间不一样，我可以这样，我发一条黄瓜就发一条黄瓜信息，但是我将这条消息保存在缓存里不显示出来，只是处理这个黄瓜而已罢了，那么如何实现，只处理消息，但是不显示消息，也不是不处理，而是这个处理不能是去刷新TableView那样处理，必须是通过点赞的累加【黄瓜】X100对就是这么简洁，富文本都免了，我需要做的就是分析发出去的消息，只要点击倒计时按钮一次，把这个事件传递给视图控制器，当初想要把这个事件传递给控制器，两个办法，一个是本地处理一条礼物消息，处理消息结束后会放到控制器，一个是请求服务器发送礼物。先说第一种方法，直觉告诉我，依然可以使用这个方法，只要改变一下消息类型，消息类型改为6，点赞的消息类型，但是我又不能直接就进入点赞的事件里，必须与点赞相区分，比如说，我要直接写一个专门处理本地送礼的界面。一旦判断是单机礼物，就执行单机动画，同时显示到一个新的地方。那么问题来了，当我倒计时结束，准备发送请求的时候务必要先发一条消息，这条消息还不能处理，只能看，那这就不科学了，换句话说，我不能把单机的动画，完全交给消息掌控，我应该直接在倒计时的按钮事件里写入单机动画，可是执行单机动画也是需要礼物模型呀，我还是得构建模型然后执行单机动画，就这个简单。现在我通过一个异常简单的办法解决了单击倒计时按钮执行礼物动画，直接就是在按钮点击的时间里回调单机动画到控制器，然后执行chatView的实时技术响应，只是在动画执行完毕的时候，我也可以不经动画过滤就直添加捆绑打包的礼物消息呢！简直棒得不要不要的。
连击礼物搞定，现在又搞定了特效礼物，其实特小礼物没有什么好改动的，就是发一个网络请求，等待服务器响应，在接收到LeanClound消息后判断是礼物消息，然后就是在判断是特效礼物，肯定是执行动画啦，可是呀可是，我需要刷新一下波劵数量，这很关键，我当然是希望在接收到LeanClound消息的时候刷新波劵数量，可是我该在哪里去刷新波劵熟练呢，干脆提前一个判断吧，在执行特效动画后立即更新主播的波劵数量。我现在就是把刷新主播波劵数量的代码抽离出来，直接告诉这个方法一个礼物ID，主播的波劵数量自动加一个数量礼物的单价。那我刚刚在执行单机动画的时候，每点击一次倒计时按钮，本质上属性主播的波劵数量，需要知道礼物类型，礼物单价，礼物数量，那干脆传个模型算了。
现在还有一个问题，当我连击连击的时候，我希望是没连击一次，就能够在View上直接展示出来，可是现在无论我连击多少次然后View上面就累加多少次，简直不要不要的。
每次点击连击按钮，构建的礼物消息模型传递到本地成为单机动画，礼物个数都是1，也只能是1，因此，我想要知道已经点击了多少次，那么我就必须为礼物消息模型新添加一个属性用来记录到底现在已经连击了多少次。
现在思路很清晰，就是连击按钮，单机动画、展示View、累计波劵。好的，先实现吧！
现在我一直疑惑一个问题，就是当我执行View的出场动画的时候，我需要确定一点，就是一个View执行UIView的Block动画，会不会影响这个View的frame，我的这个判断是建立在UIView的Block动画会改变View的frame的基础之上的，只能判断了。
现在更新波劵数量，首先得就是我需要更具礼物ID找到这个礼物的单价，这个礼物的单价是多少得用一个字符串来展示！首先获取礼物的单价，这个字符创在我计算用户允许最多发送多少个连击礼物的时候计算过，因此，我可以直接拷贝，然后累加到波劵Lable,现在都弄好了，那么现在的问题就是我现在
现在已经完美的实现了单机动画和连击反馈，就差一个波劵数量实时更新，
现在有两个问题需要及时处理，其一就是我考虑漏了一个逻辑，当我停止连击，点击礼物按钮的时候，调用了停止连击的方法，可是那个方法里面我需要做一个事情，就是我只要请求服务器发送礼物，就必须将已经存储起来的礼物数量变成0，防止我点击礼物按钮，🈶执行了这套方法，干脆这样吧，我如果能够判断一个界面上有没有倒计时按钮，再决定是否调用停止连击的方法就会好很多呢，可是我应该怎么去衡量？说白了，就是一个诉求，就是我该判断什么条件，来决定我点击礼物按钮，是否触发请求服务器发送礼物。当然判断礼物界面为真才可以重复调用方法，将倒计时按钮属性暴露在.h文件之中，只有判断倒计时按钮在屏幕上的时候，在请求服务器发送礼物。现在还有一个问题，就是当我
确定哪一个View
送了多少个礼物，同时实时显示还能送了多少个，至于界面，随便写一个，关键显示信息，这才重要，怎么好看，UI考虑。添加一个长Lable,然后写入格式包括【黄瓜：20/10000】，通过那个扇形图来展示，直接就是中间一个大圆圈，只要点击连击按钮，这个数就不断的的增加，可是我需要一个立即送出的按钮，就是我连续点击100次之后，我立马点击立即送出，就立马送出礼物和开始执行单机动画。这个时候不发消息，也不执行动画，我只需要静静的看另一个单机交互动画，
现在遇到问题了，就是不明白，这个倒计时按钮消失之后，我开始请求服务器，我应该在chtsubView里面插入一句话，可是我应该写在那个地方呢？该写在哪里呢？如何同时能够兼顾到特效礼物这就是另一个问题了,
今天早上的时候我居然又想到了一个礼物单价的好处，就是波卷数实时地变化，这多么好，我就应该这么做，首先考虑连击礼物哈，我点击连击按钮，这个事件回调到控制器中，然后执行了几个任务，任务一是本地的黄瓜单机动画，任务二将这个点击装换成一个事件展示到View上，任务三累计主播的波卷数量，就三个任务，还有的话再说，这里需要先解决另外一个问题，就是连击结束时我该做点什么，任务一就是请求服务器发送连击礼物，任务二就是构建一个消息模型直接展示到聊天框。
现在考虑特效礼物，选中特效礼物，点击发送，计算用户最多可以发送多少个，如果允许发送，本地直接构建礼物消息，进入消息过滤模型，首先开始展示特效礼物动画，然后将这条消息显示到聊天框，同时请求服务器发送礼物，还要刷新主播的波卷数量，当然这些都不能轻举妄动，必须一会儿与主播端接收礼物联系起来统筹考虑，不然又是写Bug了
主播端接收礼物时，现在无论怎样都是接收到一条消息，那么必然直接进入礼物过滤了呀，特效礼物进数组，连击礼物进队列，然后把礼物消息展示在聊天框，问题在于，我需要每展示一个礼物，就刷新一次波券，这该如何实现。反正是挺好实现的。发礼物也发了，接收礼物也接了，现在就是展示了。
处理几个任务，第一个就是回调单击礼物的事件，这真的是太简单了，我需要考虑一个为，就是我应该如何去处理这个任务，首先，就是单机动画，我需要做的事情是，展示这个单机动画，首先就是然后将消息展示到聊天框，再然后累加主播波券数。这还只是说连击动画，这只是连击的过程之中，最关键的还是得看点击连击按钮，开始一个新的倒计时动画，倒计时结束之后执行的方法这才是最最重要的，典型就是这个方法里处理两个任务，第一个任务就是请求服务器发送礼物，任务二，将这条消息直接显示在聊天框上。至于特效礼物，点击发送，也是两个任务，第一个任务请求服务器发送礼物，这跟普通的连击礼物一样，至于任务二就是发送一条礼物消息，发送一条礼物消息跟直接简简单单地把礼物消息展示在礼物框上是完全不一样的，所以，思考着其中的本质区别就是一个需要经过礼物逻辑过滤，一个绝对不能经过礼物消息过滤，这很简单呀，直接合二为一，都不经过礼物逻辑过滤，尤其是对于特效礼物来说，干脆就不本地展示礼物了，直接就是直接请求服务器发送礼物，那么问题又来了，这个时候会有一个很新很新的问题，就是说服务器在响应我们的发送礼物的请求之后，会推送过来一条消息，我已经完完全全屏蔽了这条消息，现在的诉求是只屏蔽连击礼物消息，不屏蔽特效礼物消息，这就问题很大了。特效礼物消息和连击礼物消息的唯一区别就是礼物ID不同，当然一键将礼物消息对象转化成消息模型，然后直接判断礼物ID号，如果用户ID是自己和礼物ID又是连击的时候，就不处理，我们分析这么一个逻辑，我的最终诉求是用户ID是自己的且这个礼物是连击礼物不处理动画逻辑，直接显示出来就行，对啊，这连个判断条件是没有先后之分的，因此，可以这样，干脆，我本地不再自己构建礼物消息展示到聊天框，全靠服务器返回回来的消息，反正都是要显示在聊天框的，只不过是否执行动画则是看这个消息的用户ID了，这样岂不是更加简单，同时，自己发送的连击礼物在本地单机化操作丝毫不会影响到其他观众发送连击礼物的消息时执行动画逻辑过滤。这样才是帅到爆，每个以为很复杂的问题，最后解决起来，总是那么的容易，这就简直不能认了呀，直接就是特效礼物点击发送请求服务器，连击礼物在道理是按钮消失之后请求服务器，都会返回礼物消息，都会处理，只不过连击礼物的动画过滤需要添加一个逻辑，就是判断这个礼物消息的用户ID是不是自己，这真的很重要。这个时候根本不需要执行动画，动画早就在点击倒计时按钮是就执行了，没想到很凌乱的逻辑最后是这么简单，这样还可以更直接的看到请求服务器有没有成功呢！当然还有一点需要注意，就是我应该怎样去琢磨一下那个当停止点击倒计时按钮，点击礼物按钮，立马结束倒计时，开始请求服务器发送礼物。对的，就是这样！
对了，我还得想一下，明天做点什么呢？就是开始梳理直播的逻辑，总感觉没有掌握直播的精髓。这太伤人了。必须梳理重新整理一下直播的逻辑，进入和退出来出现问题，坑爹了都！
现在有一个问题，就是倒计时按钮在倒计时大0的时候回删除这个按钮，同时我又延时执行了一个3秒方法，只要在按钮点击后地秒就会调用一次，这两句代码本质上诉求都是一样的，都是想要在点击按钮后，执行一个3秒的倒计时，3秒后删除这个按钮，同时请求拂去其发送礼物，可是我为什么要写两次呢？这严重不科学呀！我能想到的原因就是说可能我担心在点击倒计时按钮后，倒计时的动画并没有正常执行，所以写了这么一个延时3秒执行的方法，当然，现在确实是这样，当本地单机动画不断显示的时候，又加上倒计时按钮在不断的被点击，造成这种倒计时动画严重受到单机动画的影响，毕竟这个动画实在主线程执行了，势必我可能需要另外一种方法来规避这一点，当然还可以使用定时器或是CDdisplayLink可是哪一个效率更高呢，这是我一直很疑惑的地方。当然肯定啦。我可以暂且先不动这个定时器，毕竟无论是使用NStimer还是CAdisplayLink都是轻松easy的事情。因此来说，我现在最需要做的还是说不用监听动画的倒计时状态，直接开启3秒的延时操作来得更加直接，这才是我想看到的结果，可以来一个判断嘛，如果在延时3秒后执行的方法里判断礼物数量不为0，说明什么，说明我不需要请求服务器发送礼物，因为观众根本就没有点击那个倒计时按钮。所以不要把那个写那个的倒计时动画的complete的监听了，毕竟如果我以后把倒计时改成NSTimer或是CADisplayLink也是可以直接搞定的啦。所以根本就不用担心浙西东西，直接用那个3秒延时操作，感觉来得更靠谱一点呀。
现在分析一下点击倒计时按钮都做了什么事情，首先就是移除旧的倒计时动画，开启一个新的倒计时动画，接着开启新的波浪动画，再然后延时3秒执行方法，这个方法包括请求服务器发送礼物和UI界面归零。然后每点击一次倒计时按钮，礼物数量的变量累加一次，同时通过委托代理将这次倒计时按钮点击事件回调到控制器中，构建一个礼物消息模型，然后做三件事情，第一实时更新观众点击次数，第二开始执行本地单机动画，第三更新一下波卷总数。这里面还有一点需要特别注意，就是，我不能一直点击倒计时按钮，我的诉求是一旦我点击倒计时按钮的次数，我就需要判断一下这个单机动画是否还需要执行，如果礼物次数已经等于允许最大发送的礼物数量，那么就直接进入3秒延时执行的那个方法，自然如果用户疑惑为甚不让点的时候，肯定会直接点击礼物按钮，选择礼物，这时候再去提醒他充值，我也不用添加字段，说白了，就一句话，如果可以送那就继续送，如果不能送了我就直接请求服务器发送已经点击的礼物同时UI恢复初始位置。现在已经连击礼物的按钮点击事件了，接下来就是去处理这个单机动画的逻辑，不够在处理单机动画之前，我还有一个诉求，就是在我停止连击之后，只要我点击了礼物按钮，立即结束停止连击，移除连击按钮，可是这里有一个问题需要解决，就是这个点击礼物按钮是在控制器里面，我需要在控制器的事件响应里面去操作停止礼物连击，这其实也是蛮容易的，只需要把停止连击的代码写在一个方法里，然后把这个方法暴露在头文件里面就完美解决了这个问题嘛！现在停止礼物连击的问题解决了，就剩下单机礼物了，我需要做点什么呢？首先就是将单机礼物展示出来，特容易，传入一个模型和父视图就搞定了，把礼物连击了多少次的数量展示出来，这个地方有必要去做一个处理，就是这个消息模型里面的消息类型是2，但是直接就把这条消息展示到礼物框的下面，我展示添加这个View很正常，我应该什么时候移除或是设置这个View为不可见状态呢，这就是另一个问题了，我需要做的事情是如何在我停止连击的时候，将这个View从父视图移除掉，这就要考虑我之前的点赞逻辑了，之前是一个ImageView上面添加了Lable，然后呢，如果有人点赞，首先将消息存储在数组里，只有当数组的元素累计超过多少个的时候，在执行点赞的提示，当时是通过CDisplayLink来实现的，毕竟我需要一个定时器不断切换我数组里面的点赞消息，UI的表现就是切换Lable上面的文字。可是我又一个问题就是我如果这个时候又来了一个点赞消息怎么办，所以最好的办法就是在处理新的数组时，通过新的数组来接收原来的数组，然后将原来的🔢置空，新数组一个个遍历里面的点赞消息模型，然后展示出来，这样就可以实现了，点赞消息干脆也一个就出来吧，毕竟这又不需要reloadTableView，所以我需要做的事情就是不断显示，只不过开启一个两秒的延时就可以了，如此也方便我处理礼物消息嘛，当然这个时候就不要通过CDisplyLink来处理了，唯一需要的就是需要在处理消息的方法里面创建一个2秒延时执行的方法，这样才是正常的节奏嘛，其实聊天框上面的谁谁谁来了，也是同样的道理。唯一需要做的就是添加一个两秒的延时操作，就算我要处理Lable文字的定时器快速切换，那也是需要2秒的延时操作的，这个延时操作里面来执行小时动画呀！既然说道消失动画，那出现时的动画该写在哪里呢？假如把动画写在消息的处理初始之时，必然造成每次处理消息的时候都会执行这个动画，这并不是我想看到的，我的诉求是，出厂动画和消失动画一一对应，这就是我想看到的结果，我需要去处理，如何才能一一对应呢？我的出场动画是写在哪里呢，才能保证我应该把这个出场动画写在哪里呢？既然出场动画是一个新的方法来实现，那么开场动画貌似也只能是一个新的方法来实现，就是来了出场，当然既然来了和点赞的出场动画都很类似，干脆就写在一个方法里吧，算了，这样没什么意义呢，多些一个方法又不会影响什么。
那天你戴着个帽子让我突然想到了一件事情，那就是你是走可爱风路线的，你并不喜欢那种正经严肃的气氛，你喜欢的是轻松愉悦的感觉，从你喜欢鹿晗就更加可以证明这一点，我说得对不对，既然这样，那我肯定在你面前扮演错了角色，我拿错了面具，我扮演了一个梁家辉那样的角色，当初我说话的时候，你超过42秒没理人，我顿时就不开心的，心想，就是你长得像个仙女儿那也不能随便不理人呀是不是，太没礼貌了，果断删QQ删微信，当然我删也要删的落落大方，果断找了一个好借口。哈哈！然后就没有然后啦，但是有一天我看书，一句话惊醒了我，还是我见的女生不够多的原因呀，对于走高冷女神范儿的女生，你只需要保持距离，创造吸引，深度思考，营造严肃，然后在委婉含蓄，自然赢得好感，对于这种女生来说，深沉才是安全感，时而皱眉，时而叹气，时而目光深邃地望着远方，一副饱经世事沧桑的样子是最打动高冷女生的角色。最开始我以为你也是这样，后来发现，很明显，不是。从那天看到你戴帽子，我就知道，你肯定是走可爱路线的。走高冷路线的人几乎很少戴帽子。对于可爱的女生来说，赢得好感的最佳策略就是营造轻松愉悦的氛围呀，这是我的长项呀，当然啦，千万千万不要误会，赢得好感仅仅是为了你以后买辣条的时候能撕给我一点点就行，就像小时候那样，等我买辣条了我也撕给你。咱们是好朋友，从中间撕给你好不好。哎，估计这种话也只有在你这种走可爱路线的菇凉面前我才说的出口呀，我本该谈论伊朗核问题的。哎，为了赢得好感我把灵魂都卖了，你还好意思下次不带点好吃的么。不过，还是谢谢你，我仔细一想，我身边走可爱路线的菇凉还是挺多的，为了全面发展，我还是得在这个方面扩展点内涵，什么奔驰，什么老板，什么财务自由，通通先放一放，拓展一下对可爱路线的理解才是当务之急。
现在有一个问题，就是我到底该如何处理你这么一个逻辑，我把来了和点赞柔和在一起，处理消息分析消息模型，然后入场动画，然后就是判断这个View的初始View的原始尺寸，如果原始尺寸为-的父视图宽度，毫无疑问，我必须通过出场动画把它展示出来。但是这里又有一个问题，就是UIView的Block是否会改变View的originFrame。这太重要了。
观众不知道自己送了多少个礼物？
第一次点击倒计时按钮，在点赞的那条提示View上显示点击了多少次，，每点击一次，数字累加一次，停止连击，就执行这个界面的三秒小时动画，消
