揭开CloudKit的面纱

tags:开发随笔

面纱

CloudKit虽然已经不算是什么新技术，然而却一直蒙着神秘的面纱。以我自己为例，虽然CloudKit刚推出时就知道了它的特性，然而直到最近才在应用中得以应用，并对其机制有了更深的理解。

启用CloudKit

总的说来，CloudKit使用起来还是比较简单的。
在 XCode的Capability栏中iCloud项下选中CloudKit即可。
值得一提的是，CloudKit和iCloud Document是可以并存的。

1491308620.601751.png

除了定时轮询外，CloudKit可以使用通知的方式来让让应用获取云中的数据变化。所以也需要选中“Push Notification”选项。

一些比较有意思的机制

Private database和Public database

在CloudKit中， 每一个Container都有2个数据库(CKDatabase):private database和public database。

Private database和用户的iCloud账号关联，写入的数据只有当前用户可以访问，就连开发者都没法查看。它的使用也占用的是用户的存储空间配额。

Public database是和应用关联的，存储的数据对所有用户可见，甚至不需要用户登陆iCloud。同时，Public database的存储也是由开发者来承担的。好消息有两个：一，免费的配额对绝大多数应用足矣；二，用户越多，配额越大。

开发环境和生产环境

在CloudKit中，每个应用有2个环境：开发环境和生产环境。
应用在未被审核之前，使用的都是开发环境。最初我以为上传到Apple经过它签名就可以访问生产环境，所以试了试TestFlight。结果发现通过TestFlight分发的版本访问的也依然是开发环境。
后来在StackOverflow上才找到在测试生产环境的正确方式。需要在entitlement中加入一个新的key，名为com.apple.developer.icloud-container-environment，将它的值设为Production就可以测试生产环境了。如图：

1491312137.760346.png

在提交审核前，这个key需要删除，否则可能被拒。

Schema的更改

在开发环境中，schema的更改是比较方便的。需要新加一个字段，直接用代码在record中声明一个新的key就可以了。比如下面的代码在开发环境中执行时，如果allImages这个字段不存在，会自动创建它：

[record setValue:imageInfo forKey:@"allImages"];

而在生产环境就不一样了，所有的schema变更都需要从开发环境事前部署到生产环境。如果字段不存在会直接报错。而且，部署到生产环境的变动无法撤销。
CloudKit没有提供工具来删除字段。如果是在开发环境，想删除一个字段的方式是删除掉该record type然后重建。然而如果该字段已经部署到生产环境，就没有办法了。
像我，一不小心把一个不需要的字段部署到了生产环境，就只能忍着，见一次心塞一次 :(

CloudKit和iCloud Document的比较

提起比较，很多人都说，CloudKit更像数据库，iCloud Document更像文档。
除了这个之外，我认为二者的最大的区别在于开发者的掌控上。
iCloud Document最大的问题在于过分依赖于系统的daemon进程。你的文档被修改了，什么时候这个修改会被传到云中，不可预知；什么时候云中的变化被下载到本地也不可预知。如果它不同步，作为开发者你只能眼睁睁的看着没办法。

相比而言，在CloudKit中开发者有更大的自主权。什么时候同步，怎样同步，都由开发者说了算。虽然它也有限制，比如每秒的请求不能超过限额，但是开发者有足够的控制来实现友好的应对处理。

苹果官方的iCloud网站上有个CloudKit的费用计算器。貌似处理得当的话完全可以免费使用，省掉一大笔搭建服务器的银子。这对像我这样的穷开发者来说，无疑是个福音。