为何 OnlyTalk 放弃了使用 Cloudkit 服务

这是一个注定是广义上”失败“的 App, IM 太多公司尝试了又失败。我本计划 OnlyTalk 的这样的小玩意，只要耗一个月时间做个 MVP 版本， 如果我上来就需要花掉我 3 个月时间，以我的鸡贼一定不会动手。生活充满了“死”字，就像砍“只狼”一样。

OnlyTalk 的开始架构设计

因为穷 ，OnlyTalk 在设计的时候使用 Cloudkit 来作为后端 Baas ，用户基本资料、好友消息、消息历史，音频文件都存在 Cloudkit 上。

理想化的小化的 IM 架构

由于 Pushkit 的推送相当实时，而且稳定，并且 Pushkit 推送可以后台运行，所以我并没有写一个聊天服务（OnlyTalk 的视频聊天服务是一个 WebRTC 服务，参考 https://github.com/kurzdigital/Whale），OnlyTalk 的 Web 服务相当简单，当用户的消息发到服务端，服务端只是把消息转发给 Pushkit apns server，进行推送。

如果按照这个架构，那么我只有很少的服务端开发工作量，我只要把精力花在客户端上，关键是存储都在 Cloudkit 上，我可以省去很多流量的费用。那么作为一个小团队项目，我们只要支付很便宜的 ECS Web 服务器的费用，而这一 Web 服务功能很简单，使用 Node 开发，也能扛住比较大的流量，所以这个项目失败了代价只是一个月的时间。

说干就干！

次”死“：使用 Cloudkit 存储音频文件问题

OnlyTalk 编码是 8K mono 的音频，这种文件已经很小了，一般几十KB到几百KB， Cloudkit 的慢的惊人，这么小的文件用户上传下载都可能要 5s 以上，就算没有CKAsset，普通查询你依然能感受到转圈，而无论你怎么调整CKQuery 执行的优先级。

fetchOperation.qualityOfService = .userInteractive
 fetchOperation.queuePriority = .veryHigh