封装一个动画任务到操作对象之中?

所有写在操作对象NSOperation的main方法里面的代码，都是分线程执行。只要执行完毕，就会告诉操作队列，我这个操作对象里面的任务执行完了，然后操作对列就可以取出下一个操作对象，来执行操作里面的任务代码。但是，动画任务不是下载任务，是必须放在主线程的，一旦在main方法里面写一个必须放在主线程中才能执行的代码，势必操作对象就无法准确掌控main方法里面动画任务的执行阶段，就不能实现动画的排队执行。解决方案就是手动KVO管理操作对象的执行开始和执行结束，只有在动画任务执行完毕之后再将操作对象设置为执行完毕的状态，当然这个时候操作队列才会去取出下一个操作对象，开始执行里面的动画任务，如此便可以实现动画任务的排队执行。

实现无论一个观众连击礼物是快还是慢，数字的shake动画都是等时间执行？

过去的经常出现的问题是：上一次的数字shake动画还没有执行完，下一次就开始了，造成显示混乱，解决方案就是动画状态监听，回调，递归。每次执行数字Shake动画之前先判断Shake动画的执行状态，如果是正在执行中，就先以数字动画的执行次数变量累加的形式将这次Shake动画保存起来，只要前一个数字Shake动画执行完毕，就将动画状态布尔值改为执行完毕状态，同时判断数字动画执行次数的变量是否大于1，决定是否继续执行数字Shake，如果执行，自然执行状态改为正在执行状态，同时动画执行次数变量减减。直到动画执行次数变量变为0，就结束数字动画，开始延时2秒执行礼物界面的上移消失渐变动画。自然需要把当前总共发了多少个礼物也就是数字动画总共执行了多少次通过NSCache对象保存起来。因为并不是每一个观众的礼物数量都是从1开始的嘛！

连击礼物动画处理流程？

一是右移礼物框，二是右移礼物图片，三是数字Shake，四是礼物整体界面上移渐变消失。

避重复创建动画任务操作？

创建记录操作对象的NSCache缓存类（类似字典）,创建的每一个操作都添加到操作缓存之中，添加格式：（用户ID&礼物ID）为key，NSOperation操作对象为值Value。换句话说，相同观众送的不同礼物也要创建不同操作，避免同一个观众B礼物的数量累加在已送的A礼物数量上。处理新的礼物消息模型，首先判断操作缓存是否已经有了这个操作，如果有就直接拿出这个操作，如果没有就创建一个新的任务操作添加到操作队列之中等待执行。当然，需要特别说明一点，任务操作对象添加到操作队列之后，并不能说明这个操作对象的任务就会被马上执行，这是不对的，因为这个是时候操作对象很有可能是在排队，这是多人发礼物最常见的情况。

C观众不断送礼物的处理逻辑？

前提，C观众早已就创建了动画任务操作添加到了操作对列之中，可以直接通过NSCache类将已经创建的动画任务操作取出来，这时候C观众继续送礼物需要处理的逻辑:第一种情况：此时屏幕正在处理A和B的礼物动画任务：第二种情况：此时屏幕已经在处理C的礼物动画任务。

首先说第一种情况，屏幕正在处理其他观众的动画任务。通过给操作对象再添加一个属性，这个属性专门用来记录这个将来这个操作里面的任务执行时，礼物界面至少应该执行多少次数字动画，每执行一次就表示观众连击了一次，只不过在屏幕处理其他观众的动画的时候，先把数字动画的执行次数以变量累加的形式保存起来，等到任务执行的时候再执行。

再来说第二种情况，屏幕正在处理C观众的礼物动画任务。可以直接通过从缓存中取出的任务操作对象来调用礼物界面这个属性，然后再根据这个礼物界面属性调用礼物界面里面写的抖动文字的动画，简直棒得不要不要的！

将执行礼物动画的任务封装成操作对象添加到操作队列的迷惑之处？

用户首次发礼物时，操作缓存里面没有这个动画任务的操作对象，于是需要创建一个动画操作，这个操作在初始化的时候就会创建礼物界面，同时设置礼物界面的一系列属性，包括数字礼物执行次数的变量初始默认为1，即至少执行一次数字shake佛动画，除非在数字Shake动画的执行过程中或是延时等待礼物界面上移消失的2秒时间类有与该操作相同的礼物消息进入，自然就可以实现连击的效果。

操作对象添加到操作队列之中，这个操作是什么时候被删除呢，简直好神奇，貌似只要把操作对象添加到操作队列里就永远提那几到队列里面了，那这样简直就是没法管理内存，简直就是实例化了很多的操作对象添加到了操作对列之中，我需要做的就是考虑在操作对象执行完毕的时候删除操作队列里面的操作对象。

一个动画任务的操作完全执行完毕后需要在Block的回调代码块里处理什么?

1、将礼物界面视图从父视图移除，这就问题很大呀，如果一移除，势必造成如果这个时候还有消息进来，即使操作缓存里面有这个操作，取出这个操作也不是什么问题，最大的问题是通过这个操作的礼物界面属性来开启数字动画会失效呀，有没有，那么最好的方式就是这个时候把那个操作也从操作缓存里面删除，这样即使是有新的礼物消息过来，也是创建一个新的操作对象，既然创建一个新的操作对象，自然就是给父视图新天添加了一个礼物界面View呀，这个是时候就又可以通过礼物界面这个属性开启新的数字动画了。

2、礼物界面上移渐变动画执行完毕之后Block回调手动KVO改变任务操作对象的finished属性。同时删除操作缓存里面的这个操作对象，这样才对得起刚才将礼物界面从父视图上删除。可以通过任务操作对象的completeBlock来确认确实已经关闭这一个任务操作对象。

连击的方案?数字Shake动画的数字从历史送出礼物的数字累加？

现在确定连击不算什么两次点击的时间间隔是否超过3秒，直接通过倒计时按钮是否消失来确定是否是连击，只要在倒计时按钮消失之前的点击都算作连击状态，然后捆绑打包成一个请求，如果服务器暂时失败那也添加重试3次的逻辑，确保这个发送礼物的请求能成功，这样其实比起本地的单击化操作实现连击更加简单了许多。自然这样还带了许多好处，主播段不用判断礼物消息的是否连击布尔值字段，如果是连击，还得把缓存里该用户的历史送出礼物个数取出来，当做数字Shake动画初始值，这好类似图片的那个内存缓存呀，

存储任务操作的对象的唯一标识符为什么不是用户ID也不是礼物ID，而是用户ID&礼物ID?

首先如果用用户ID来作为唯一标识符，肯定会疑惑一个问题，就是如果是同一个用户，先是送A礼物，然后又送B礼物，这怎么办？会不会发生礼物一的数量结果累加到了礼物二的头上，简直不要太伤心。其实有些多虑了，毕竟同一个用户切换礼物，时间就算是在30秒之内，发送新礼物是的连击布尔值也是NO呀。所以根本不用担心这个问题，只是这样做确实不够严谨,既然是唯一标识符，而是设置得越复杂越好吧！当然如果使用用户ID还有一个问题，如果一个用户先发了一个A礼物，这时候礼物A还处于执行状态的，那现在收到了该用户发送B礼物的消息，请问现在我是创建新操作还是不创建呢？答案是肯定是新创建一个啦，但是依照以往的逻辑，只看用户的ID实在是不能创建新操作呀，可是如果不止判断用户ID还判断礼物ID，这首先造成的问题就是到底将操作对象存入操作缓存中依据用户ID还是礼物ID呀，答案很简单，拼接用户ID和礼物ID,通过连接符&进行连接，这样简直就是完美无暇呀。

处理礼物消息模型的逻辑?

1、首次进来一个礼物消息的模型，然后需要做的就是将用户ID和礼物ID拼接成为一个操作的唯一标识符，然后用这个唯一标识符来判断这个操作是否存在操作缓存之中，如果存在，接下来判断这个任务操作是否处于正在执行的状态。如果不存在，需要新创建一个任务操作添加到操作队列同时添加到操作缓存之中。

2、已经创建任务操作之后又接收到礼物消息模型，如果判断操作处于正在执行的状态，直接就可以通过从缓存中取出的操作对象的礼物界面属性执行一次数字动画，当然啦，为了保证前一次数字Shake动画执行完毕再执行下一次，务必要判断数字动画的执行状态。如果操作处于未执行也就是正在队列里排队的状态，将这个数字Shake动画变成数字动画执行次数的变量累加记录起来。

NSOperation对象的main方法和start方法的区分?灵活考虑分线程嵌主线程的问题？

start方法：写入一个主队列然后将待执行的任务写入到这个主线程队列的Block代码块之中。 这样就会在队列被启动的时候开始执行礼物界面的平移动画，平移动画执行完毕之后接着执行数字动画，这个时候用户继续连击一次礼物，判断操作缓存里面有这个操作，同时这个任务操作也正好处于正在执行的状态，那么直接就可以去调用这个数字动画，这样没什么问题，如果数字动画正在执行中，就先把这个礼物消息变成数字动画执行次数的变量存储起来，等上一个数字动画执行完毕后再判断数字动画执行次数决定是否继续执行数字动画，如果不在需要执行数字动画，自然在2.75秒的延时（数字动画已经花了0.5秒）后开始执行礼物界面的消失动画，费事0.25，总共加起来一共3秒，可现在的问题是，假设我们新收到了一条礼物消息模型，然后根据用户ID和礼物ID去分析操作缓存，发现操作缓存里面有了这个操作对象，但是哟，但是哟，但是哟，这个操作对象仍处于排队中，换句话就是说前面有好几个操作对象等待执行呢，这个操作对象虽然已经在上一次接收礼物消息模型的时候实例化改唯一ID的操作对象且已经添加到操作缓存之中，自然这个操作对象的礼物界面属性和其它属性都已近赋值，等待的只是一步就是等待操作队列开始取出这个操作对象，然后执行这个操作对象的start方法。可是这个时候问题就在于这个时候的礼物界面是还没有添加到父视图甚至连这个礼物界面的平移动画都还未执行，这就造成了一个问题，就是那个当收到新的礼物消息模型时，你也从操作队列之中去取出了操作对象，但是如果此时你通过这个取出的操作对象的礼物界面属性去调用数字动画，将会大错特错，为什么呢？因为这个礼物界面都根本没有添加到父视图上面呀，执行数字动画根本毫无意义，那么这个地方该怎么处理呢，办法总比困难多，首先想到的办法就是判断操作的执行状态，默认为NO,只有在调用操作对象的start方法时才会将操作对象的执行状态改为操作对象正在执行中的状态，当然在操作对象执行完毕，就是礼物界面的消失动画执行完毕后开始回调的Block代码块里面修改这个操作对象的执行状态，但是貌似不修改操作对象的执行状态属性也是可行的，毕竟在Block里面会执行一个将操作对象从操作缓存删除的操作，现在的问题就是判断这个操作是否正在执行还是正在排队？刚才已经分析如果判断这个操作对象已经是在开始执行，现在就是需要特别考虑如果这个操作对象正在排队，那应该怎么去搞？很明显，一旦判断到操作对象正处于排队状态，那么我就不能再通过操作对象的礼物界面属性去调用数字动画了。这个时候我需哟啊考虑一个问题，既然我不能直接通过操作对象的礼物界面属性去调用数字动画，其实仔细一想，貌似也是可以通过操作对象的礼物界面属性去调用这个方法呀，只不过这个时候我想要的结果是累加一下数字动画的执行次数的变量，可是这个时候又因为数字动画的操作并未处于正在执行的状态，势必造成我只能进入到开始执行数字动画的代码里，可是这样做毫无意义。因为礼物界面视图都必须是在操作对象开始执行start方法时才添加到父视图呢？那么这个时候我需要想了，有没有一个两全其美的方法，不需要考虑操作对象的执行状态的方法，那么这个判断是什么玩意儿呢？果然天无绝人之路，那个操作对象里面就有这个一个属性用来记录操作对象是否处于正在执行的状态。那么，我需要做的事情就是在取出操作对象之后调用数字动画的时候，只要是数字动画正在执行的状态或是操作对象处于未执行的状态，，就将这条消息模型转化成一个数字动画执行次数的变量然后累加。搞了半天居然就只是一个问题，就是多添加一个Bool值判断就可以了，居然都是原生的，可是背后的逻辑课就不简单了。现在问题又来了，就是一个是操作对象的属性，一个是礼物界面的属性，这两个属性综合判断决定是开始执行数字动画还是执行数字动画执行次数累加。是否考虑将这个判断换一个地方。可是换什么地方呢？上算了吧，给礼物界面多增加一个属性，通过正向属性传值的方式将这个消息传递过去，这样就可以实现在礼物界面里面判断操是作对象是否是处于正操作状态了。现在我还发现一个问题，就是为什么不依照套路出牌，我创建了一个操作对象之后，调用这个操作对象的是否正在执行属性，居然没有反应，简直就是日了狗了，不和逻辑呀，这可是子类呢！这个原生属性的问题简直就是一个大坑，就是NSOperation的子类即自定义操作对象居然无法访问到父类的属性，这就是好奇怪的问题呀，简直不能忍。

main方法：但是因为动画任务必须是在主线程执行，首先想到的就是在main方法创建一个主队列，然后将要写的任务写到这个将会在主线程执行的Block代码块里，那么现在问题来了，当任务操作对象开始被调用的时候，如果有start方法，就根本不会再调用main方法呀，这可咋整，根本不合逻辑，调用start可以理解为操作对象添加到了操作队列里，只要上一个被执行完毕，这一个自然就会被执行，可是我就纳闷了，为什么不会调用main方法呢。而且刚才还发现一个问题，就是在操作对象的.m文件不写main方法，只写start方法直接就导致了这个任务操作对象永远停不下来，这就意味着操作队列永远不会取出下一个操作对象里面的任务来执行，这样问题就很大了呀，执行start方法的操作对象永远停止不了，新添加的任务操作对象永远是等待状态，这就坑爹呀，不过这还正好可以测一下如果操作对象是等待状态，新来的礼物消息模型怎么去处理的问题，完全没有问题。这就是成长。当然还是有必要在执行操作对象的start方法里的任务之前先判断这个操作对象是否已经被取消，因为完全可能有这么一种情形，就是本来将任务操作对象添加到了操作对列之中，同时也存入了操作缓存之中，这时候我就在想,我对加入的某一个操作，我不想再执行了呀，我又不能直接把这个任务操作对象从操作队列里删除，能做的也只是先找到这个操作对象，然后调用cancel方法，改变操作对象的canceled属性，这样就可以在这个操作对象快要执行的时候首先判断操作对象的cenceled属性,然后就可以决定既不继续执行了。典型的如果直播间有人正在疯狂的送礼物，观众却要退出直播间就必须考虑这一点。问题是，如果不继续执行，是否会继续执行操作队列里的下一个任务操作对象，至少得有一个逻辑，一个改变操作执行结果的逻辑，这很重要，所以必须通过KVO去手动改变操作对象的finished属性。

到底是使用两条最大允许并发数都为1的操作队列较好，还是使用一条最大允许并发数为2的操作队列较好？

现在有两个操作队列，默认允许最大的并发数是1.现在如果只设置一条队列并设置并发数为2，然后根据奇数偶数来判断我应该选哪一个rect,这样更好呀，确实更好。

观众连击礼物单机化的处理逻辑？

直接就是一个网络请求，我只需在观众发送网络请求之后创建一条与leanClound相类似的消息添加到本地的聊天界面，然后处理这条本地消息，所谓的处理，也就是判断消息模型的消息类型，然后把它展示出来，同时分析这个消息模型里面的礼物ID，决定到底本地展示哪一个礼物，那么问题来了。

到底这个本地化的礼物单击是在服务器判断观众波劵数网络请求成功之后，还是本地观众直接计算允许发送多少个选中的礼物然后直接就展示礼物。

方案一:

首先考虑通过服务器来判断观众的波劵数在网络请求成功后直接不等待LennClound的消息，直接发一条本地消息来展示礼物的单击，那么问题来了，构建这个本地的礼物消息都需要哪些参数，当然通过单例一句话就调出来了，需要的参数也就仅仅是礼物ID和设置消息类型罢了。这很容易，直接展示礼物然后再把这条消消息显示到聊天界面之上，这毫无问题。问题的关键是，如何屏蔽服务器群发推送过来的礼物消息，避免礼物展示两次呀，礼物消息模型里面肯定首先是消息类型为2，这样就可以判断是礼物消息，进而判断礼物消息的用户ID是否与当前登录用户的ID号相同，如果相同，直接就return。对于服务统一推送的消息，有一个特别需要注意的东西，就是必须搞明白消息模型的用户ID到底是从哪里来的，其实服务器推送消息就那么几种，进出房间，礼物和直播间关闭，直播间关闭、系统通知，这些从服务器推送过来的消息，就礼物消息和进出房间的消息会带有用户ID,这个时候如果判断，消息里面的ID与登录用户的ID相同，就不处理的话，会导致进出房间的消息也被屏蔽掉，而这并不是我想看到的结果，所以我必须要做的是，再来一个字段区分礼物消息和进出房间的消息，唯一想到的就是礼物ID和礼物数量都不为0来区分。当然这一切的前提是服务器发送的进出房间的消息和系统房间通知的消息的礼物数量和礼物ID都是0。现在自己本地发礼物已经做到了单击化操作，可是我想全局根据礼物ID知道礼物的名称，这个怎么来，建一个plist表格.。现在已经建好了plist表，在侧面弹出礼物的时候会显示，然后在创建礼物消息的时候会根据用礼物ID来获取当前礼物的名字。这就是礼物的消息要拼接的内容。将plist转化成的字典很明显会多次用到，为了避免多次创建消耗内存，干脆把它创建一次全局保存在userDefault里面。

方案二:

本来考虑在服务器请求成功事件里写单机版的连击动画，但是，我发现动画演示最要命的问题并不在于leanClund，而是在于秀波服务器的请求响应时间太长了，远远超过3秒呀。所以还是考虑客户端来判断观众的波豆数量决定是否展示单机动画以及计算最多能发送多少礼物吧。实现这一点的两个关键之处就是实时获取观众的波豆总数和礼物单价，每次连击发送礼物之前先判断用户最多可以发送多少个连击礼物，换句话说，只要，观众点击发送按钮，就做一个除法，用观众的波豆总数除以礼物单价计算用户最多可以发送多少个礼物，如果获得的值count介于0和1，则提示波豆不足，跳转到充值界面，如果是大于1的数量，则取整舍零，每连击一次就count数量减1。如果等于0，直接就按钮置灰恢复初始。当然特效礼物不用管，毕竟当我选择了特效礼物并判断最大允许发送数大于1的时候，就直接关闭了礼物界面，至于能不能继续发送特效礼物，需要我重新打开礼物界面，只要我一打开礼物界面，就会自动请求最新的波豆数量，再来计算新的最大允许发送次数。这多好，简直不要不要的。对于礼物接收端来说，唯一需要逻辑判断的就是判断礼物消息模型的连击布尔值。 问题关键点，根据礼物ID获取礼物的单价，这个数据有必要在转化成模型的时候把这个字典存入到Appdata里面。当然这不能是一个固定的plist表，因为这个单价会随着服务器礼物单价的变化而变化。首先想到的办法就是是否能够直接通过这个本地的字典将礼物的单价取出来，推理一下，我有一个礼物ID号，然后还有一个字典，当然我可以将这个字典装换成模型数组，然后遍历数组的每一个模型，如果礼物ID与模型里面的礼物ID等价，那么这就是那个礼物的单价，这会带来一个大问题，严重有很多无效操作，知道一个键，想要去取特定值，最好的方法还是通过字典来实现。那么问题的关键就是构建一个礼物ID为键，礼物单价为值的字典，这很重要。其实简单，就是建立一个可变字典，遍历礼物模型数组里面的每一个模型，以模型的礼物ID为键，模型的礼物单价为值，这样就不断给可变字典添加了新的元素，然后把这个字典暂时保存为一个全局的变量，当然不用保留全局的变量也想，但是这样考虑到后期可能会用到，还是存储为全局的吧。

如果判断观众是发送连击礼物，设定数字Shake动画的初始值？

在自定义操作对象里面创建一个公开属性，然后取出该用户的历史礼物个数赋值给操作对象的属性，在操作对象调用start方法时把操作对象的count属性值赋值给礼物界面的count属性。

如果C前面有A和B两个观众发礼物？A和B各占一个位置，如何实现谁结束就把位置传给C?

错误的思路：考虑到同一个用户发送不同的礼物，展示的位置要相同，还是觉得干脆通过用户ID来区分吧，如果是奇数的用户ID在上面的位置展示，反之亦然。这样问题就解决啦，有木有！这个时候就可以执行用户的礼物动画了，只要用户不同或是礼物不同都会从0开始，然后创建一个新的操作。当然最后问题多多呀！

正确的思路：如果把问题变成在C的动画任务开始执行时去判断屏幕的哪一个位置为空，可就真的调入死胡同了，永远都没解呀，可见问一个正确的问题有多么重要！！！毕竟在操作对象调用start方法的时候是可以通过判断点什么来决定礼物界面的初始位置的，可是我要找到的这个判断条件是什么呢？是操作对象的奇数偶数么，当然可以判断出来，试想一下，加入前面已经结束的操作对象是第二个也就是偶数，现在执行第三个操作对象，但是第三个操作对象的序号是奇数，也就是会放到正在执行第一个操作对象的地方去执行这个本来该顶替第二个操作对象的地方去执行，那么这个时候我需要做一个纠正，纠正到底这个结束的这个操作对象是的序号是偶数还是奇数，可是这样就好像入坑了哟，思维进入了一个死循环，我需要做点什么，就重新分析一下我的最终诉求，我最终想要实现的结果是当两个操作对象同时执行，这时候必然有一个先执行完，有一个后执行完，我想的是将先执行完的那个操作对象的位置原始值当成参数传递给下一个被开启的操作对象的start方法。换句话说，那个操作对象执行结束了，就获取这个已经结束的操作对象的原始frame，然后就在下一个start方法里将这个frame赋值给准备执行的操作对象的礼物界面的frame，说起来容易，首先在操作对象结束的时候将这个操作的礼物界面的原始尺寸获取下来就是问题，问题的关键在于，这个操作对象没有一个属性来记录礼物界面的原始尺寸，我需要做的就是写一个属性来记录这个原始尺寸，然后怎么记录呢，这个原始尺寸来自哪里，来自于start方法里，start方法就得这么写了，如果这个操作的原始尺寸属性的值不为空，那么就直接将这里面的值赋值礼物界面的frame,那么这个frame什么时候才会有值呢，很明显，是在创建的时候，如果是第一个就把上面的位置给操作对象，如果是第二个就把下面的位置给操作对象，如果是第三个，则要看前面正在执行中的操作对象，哪一个先执行完毕，谁先执行完毕，就把这个执行完毕的操作对象的原始尺寸赋值给第三个待执行的操作对象的位置，所以我需要做的事情就是不断研究把尺寸传递下去，问题的表象就是去分析研究每一次调用操作对象的start方法时给礼物礼物界面赋值位置尺寸的来源。第一次调用dtart方法的Frame来自于父视图上面的位置，第二次调用start方法来自于父视图下面的位置，第三次调用start方法来自于判断前面执行完毕的哪一个操作的frame，就假设第二个操作对象比第一个操作对象先执行完毕，意味着第三个操作对象的操作对象的frame与 第二个操作对象的frame相同，问题关键第二个操作对象如何把这个frame传递出去，当然我们都知道操作对象在执行完毕的时候会手动改变finished属性，然后就会在回调一个Block，这是一个很好的机会，前提是，通过这个操作对象就可以获取到这个礼物界面的初始值，当然前提是第二个操作对象有那么一个属性能够记录操作里面的礼物界面的初始位置，这很简单，直接一个属性即可，一点问题也没有，唯一的问题可能就是这个赋值的时候，在创建操作对象的时候进行赋值，默认就是用户ID奇数在上偶数在下，但是操作对象最终的起始位置originRect还是看前面的那一个任务操作对象先执行完毕。还有一个问题，就是现在我一旦不将开辟内存的方法写在初始化操作对象的方法的时候，就会造成线程卡顿，但是难不倒我，我需要做的事情，试试才知道，否则将开辟礼物界面内存空间方法在上面的方法里，反正设置礼物界面的frame必须放在下面的方法里，但是一旦分开礼物界面的内存初始化和设置初始尺寸的代码，就意味着我需要重写layoutSubview方法，这实在很坑爹的。所以就暂且都是在start方法里面开辟礼物界面的内存空间和设置尺寸。但是这里有一个特别需要注意的地方就是我在通过操作对象调用礼物界面属性时必须要有一个判断，判断这个操作对象是否正在执行，如果没有执行，那么就是简单的将数字礼物执行次数的变量累加，如果是正在执行状态,则直接开始数字Shake动画。问题就在于此，如果任务操作对象还没有执行即没有调用start方法，用操作对象的礼物界面属性去调用数字Shake动画的方法是根本没有任何意义的，因为那个礼物界面属性还为空没被初始化呢，我能做的就是从操作缓存里面取出操作对象的时候，只有判断这个任务操作对象是处于执行状态才直接通过礼物界面属性去调用数字Shake动画，如果不是则只能先用一个数字动画执行次数的变量累加存储起来，对了，记得初始值为1，然后在操作对象调用start方法实例化礼物界面的时候立马将操作对象的数字动画执行次数的属性值和礼物数量的初始值的属性值赋值给礼物界面的属性，如此等待礼物界面进行下一步的处理，如此便完美解决了这个问题。所有还需要增加一个属性，让我来记录我一开始就至少应该执行多少次数字动画。现在还有一个关键问题就是前面的任务操作对象结束之后获取到礼物界面的原始尺寸不知道改传给哪一个任务操作对象，说白了，就是不知道直接从操作队列里面或是操作缓存里面直接把下一个就要执行的任务操作对象给揪出来。既然任务操作对象执行完毕后会将这个任务操作对象从操作缓存里面删除，果然是天无绝人之路，也就是说下一个即将执行的任务操作对象总会是操作缓存中的第2个任务操作对象，哈哈，真是厉害，简直不要不要的。可是这里有一个问题，就是操作缓存NSCache里面是没有严格顺序的，就是我必须通过一个可变数组将所有的操作对象存储起来，每执行完一个操作，就将这个操作的礼物界面的原始尺寸值获取出来，然后再将这个操作对象从可变数组中删除，自然再从这个可变数组中取出第二个操作对象，然后把刚刚获取到的那个操作对象的礼物界面的原始位置赋值给新取出来的操作对象的原始位置属性。这样在界面上表现出来的就是屏幕上有两个操作对象正在执行，无论哪一个操作对象执行完毕，下一个操作对象立马拿到结束的那个操作对象的初始位置，填补位置，开始执行动画，简直神奇到不要不要的。当然这里面有一个异常尤其需要注意，就是当那个可变数组里面只是存储了一个任务操作对象，然后这个任务操作对象执行完毕的时候，自然会去移除可变数组里的任务操作对象，然后还要取第二个元素，前提，一定得注意前提，就是可变数组在移除操作对象之后必须至少有两个元素。

主播端判断观众连击礼物的新思路？

服务器暂时搁置添加礼物消息模型里面的是否连击字段，自然想到一个新方法就是观众发送连击礼物，点击一次按钮累加一次礼物数量，在延时3秒的倒计时按钮执行消失的方法里在捆绑打包请求发送礼物的接口。当然，发送礼物的观众是每点击一次就执行一次连击动画的。完全单机操作。

在用户点击退出按钮时立即结束当前正在执行和准备执行的礼物动画？

因为操作队列里面的操作是严格按照顺序来执行，这意味着必须在点击退出按钮的时候，优先响应退出按钮里面的封装的任务，而不是继续执行动画操作，换句话说，一旦点击了退出按钮，就必须马上停止操作队列里面的所有任务操作，这样就可以避免控制器器都准备销毁了，而单例里面的任务操作对象还在继续执行的问题，在显示礼物的时候退出直播间需要严格注意操作队列的取消所有操作对象。可是执行取消所有操作对象的这段代码应该放在那里呢，放在点击退出的响应时间里，换句话说，只要你点击了退出，你就取消了操作队列里的所有的操作对象，取消操作对象还不算，干脆直接把操作队列置空，里面所有的任务操作对象都消失得无影无踪，这真的是干的漂亮呀。