热门推荐：
　　从此多了很多
　　国际友人呢！
　　?Paper Planes的规则其实非常简单，像是一个国际版本的漂流瓶。
　　相应的我们可以丢纸飞机的对象也从公司里暗恋的小果酱，扩大到了全世界的!
　　当然除了投飞机以外，我们还可以抓国际友人们的纸飞机。
　　??在掷出纸飞机之前差友们可以先在信纸上盖上一个属于你的邮戳，邮戳的形式也非常丰富。
　　有印着各种千奇百怪的动物的邮戳，还有显示日期和你所在的地理位置的邮戳。
　　盖好邮戳后就可以让你的小飞机去驰骋了。。。
　　??我们盖的邮戳是可以和国际友人们的邮戳叠加的。只要在飞机池里捕捉一只别人的纸飞机，然后盖上属于你的邮戳就可以了。
　　下面的这只野生的纸飞机就是世超随意捕获到了，已经被来自澳大利亚的罗伯特，以及来自二里屯的李狗蛋盖满了邮戳。。。
　　??一个简单易懂的邮戳，就这样跨越越过不同的肤色，各自的语言以及巨大的文化差异。将整个世界无限的缩小。
　　是的，这满屏幕乱窜的纸飞机每一只都来自世界各地的熊孩子们！！！
　　??然后用手机把差友们折叠好的纸飞机投掷到电脑里，你的纸飞机就可以在苍茫的飞机池里自由翱翔了。
　　只要等着被下一个国际友人捕获到就可以了。。。
　　同样捕捉纸飞机也非常简单，只要在手机屏幕出现捕捉网后，在空中挥舞一下，看到有飞机落入网中时。你就抓到它了。
　　??这款来自谷歌实验室十分简单的免费应用，甚至简单到根本不需要特地下载一个App。
　　只需要使用科学的上网方式登入一个网站就可以了放飞你的纸飞机了。
　　这个简单的小游戏让世超感觉离这个世界这么近过。
　　因为无论你来自哪里、拥有怎样的肤色、受过怎么的教育。在你掷出纸飞机的那一刻，我们都不过是童心未眠的孩子罢了。
　　这里聚集了稀有，好玩的App，喜欢就关注我们吧，微信公众号：Appiction
请先登录再操作
请先登录再操作
微信扫一扫分享至朋友圈
这些东西，大佬们肯定不想让你知道...
知名IT评论人，曾就职于多家知名IT企业，现是科幻星系创建人
未来在这里发声。
新媒体的实践者、研究者和批判者。
立足终端领域，静观科技变化。深入思考，简单陈述。
智能硬件领域第一自媒体。您的位置：& & &漂流瓶被投诉自动解除神器
漂流瓶被投诉自动解除神器
02-2402-2402-2402-2402-24
漂流瓶被投诉自动解除神器
1367人推荐
5.5分音乐视频
2120人推荐
5.5分音乐视频
5.5分音乐视频
5.5分音乐视频
5.5分音乐视频
5.5分音乐视频
5.5分音乐视频
5.5分音乐视频
8分音乐视频
1016人推荐
5.5分音乐视频
5.5分音乐视频
5.5分音乐视频
5.5分音乐视频
5.5分音乐视频
5.5分音乐视频
5.5分音乐视频
5.5分音乐视频
5.5分音乐视频
5.5分音乐视频
5.5分音乐视频QQ邮箱APP漂流瓶开发记录
QQ邮箱4.0增加了漂流瓶功能，记录一下做漂流瓶过程中碰到的问题。
漂流瓶有我的瓶子列表，需要跟后台保持同步，于是当然就需要个增量更新方案，在常见的--对比和日志中，选择了后面一种，因为按目前漂流瓶后台的情况，可以很容易地支持这种方式，不需要记录每一步操作，只需要按时间作为key查找这段时间内数据的增删改就行了。这种方案对前端来说这种方式更是方便，只需要记录一个sync-key，往上请求就行。
具体实现方式是：
1.请求列表，返回数据，以及后端当前服务器时间svrtime
2.下一次请求列表，客户端带上上次返回的svrtime，后端从数据库查出svrtime和当前时间这段时间内列表数据的增删改，返回给客户端
后端瓶子有updateTime字段，数据新增或更新时会记录当前时间，所以很容易找到一段时间内所有增改的数据。对于删除，后端删除瓶子时是不会删除瓶子记录的，只会把瓶子标记成已删除，有个标志日期，所以也可以找到时间段内删除的瓶子。
瓶子列表不会一次性全部加载，每次请求返回20个瓶子，所以需要个加载更多的功能把后面的瓶子拉回来。实现的方式是把客户端列表最后一个瓶子的id上法给服务端，服务端把所有瓶子按时间排序后找到这个瓶子id对应的位置，返回它后面的20条数据给客户端。
瓶子是按时间排序的，瓶子的时间会变化，例如回复一个很早的瓶子，这个瓶子时间就会更新，跑到列表的最上面来，这样的场景导致加载更多会有问题。
1.最后一条数据被更新
如上图，客户端列表当前状态是Bottle1-Bottle40排列，这时服务端Bottle40已经被更新，跑到最上面了，客户端还没有更新过来，这时点击客户端的加载更多，会把Bottle40作为游标上发给服务端，期望返回Bottle40以后的数据，结果服务端返回的是Bottle1-Bottle20。结果导致的效果是加载更多完成后列表上的数据完全没变化，再点多少次加载更多都一样。
2.最后一条数据被删除
再看看瓶子被删除的情况，上发Bottle40到服务端后，服务端已经无法找到Bottle40的位置，只能什么都不返回，表现跟上述瓶子被更新的情况一样。
加载更多的实现是以前后端数据一致为前提的，上述问题就是前后端数据不一致导致的，解决方法也挺简单，就是加载更多会对列表做一次增量更新，若有更新，直接返回增量更新的内容，若无更新才执行加载更多的流程，确保数据一致的前提下才进行加载更多。
客户端的愿望是跟服务端数据保持一致，但在请求发出-&返回的间隙中会出现一些数据不一致的问题，例如：
发送漂流瓶-&后台接收到请求，客户端尚未接收到返回
-&加载漂流瓶列表-&把发送成功的瓶子拉回来了-&本地还有一个发送中的瓶子（没有id）-&出现两个一样的瓶子
-&发送漂流瓶请求返回客户端
除了发送瓶子，发送聊天，回复海滩瓶也有同样的问题。为解决这个问题，为这些可能会关联依赖的请求做了个队列，让发送漂流瓶的请求完成后再发出请求，就不会出现上述问题了。
这个队列属于逻辑层，不能在网络层直接做，而请求是异步的，用原生的GDC队列无法让异步的请求排队，为此做了个简单的异步队列：
@implementation FMAsyncQueue {
NSMutableArray *_taskQ
- (id)init
self = [super init];
if (self) {
_taskQueue = [[NSMutableArray alloc] init];
- (void)addTask:(FMBlockTask)blockTask
[_taskQueue safeAddObject:[blockTask copy]];
if (_taskQueue.count == 1) {
blockTask(self);
- (void)next
[_taskQueue removeFirstObject];
if (_taskQueue.count) {
((FMBlockTask)[_taskQueue firstObject])(self);
使用大致是这样：
FMBlockTask blockTask = ^(FMAsyncQueue *queue) {
httpCompleteCallback oldOncomplete = [callback.oncomplete copy];
callback.oncomplete = ^(QMHttpResponse *response, QMHttpError *error) {
oldOncomplete(response, error);
[queue next];
[QMCGIManager post:url withCallback:callback];
[_asyncQueue addTask:blockTask];
把请求排起队来，可能会导致速度慢，但对漂流瓶来说足够了，影响不大。
另外还有个问题，如果发送过程中断网了，也回导致数据出现异常：
发送漂流瓶-&后台接收到请求-&返回过程中手机断网接收不到-&本地多了发送失败，后台实际已发送成功-&更新列表后，出现两个一样的瓶子
这种情况目前没有处理，考虑到处理这种情况的性价比低，还会让逻辑变得复杂，这种罕见的情况造成的后果也只是多出一个发送失败的瓶子，用户手动删除即可，不造成其他影响，所以暂不处理。
漂流瓶的删除是支持离线操作的，没有网络也可以删除瓶子，用的是QQ邮箱已有的离线操作库，原理是把类，调用的方法，调用的参数包装成一个Operation，序列化保存到本地，下次启动如果有网络，把这些Operation全部拿出来，用NSInvocation执行这个方法。函数方法和参数可以保存，但callback block是保存不了的，无法回调请求onSuccess等方法，不过也不需要，做这类型的操作都是执行后就当发送成功，进行相关处理，离线操作库会不断尝试把这条请求发送出去。
TableView不等高Cell
瓶子列表和聊天列表每一行字数不一样，行高也就不一样，行高是要根据文字渲染后占的高度决定的，但UITableView每次刷新都要知道每一行的高度，才能确定整个TableView的高度，如果每次TableView刷新都把每一行数据渲染一遍算出高度，显然数据多了会有性能问题。这个问题应该是很常见了，微博就是这样，解决方法也很简单，就是把渲染后的高度存入数据库，下次获取高度时就不需要渲染，直接返回保存的高度就行了。
漂流瓶整体还是比较简单的，碰到的问题应该是很多需要跟后端同步数据的APP共有的问题，在用户量还没有上去的情况下没再做更多的优化，先记录下来做个备忘。