iOS中理解iCloud数据存储

要在应用中启用iCloud，首先要为iCloud使用配置App ID。配置好后，生成授权文件（provisioning profile）并在应用中申请权限（entitlement）。根据应用的数据存储需求，需要申请以下一种或两种权限。

iCloud权限键

12

com.apple.developer.ubiquity-container-identifierscom.apple.developer.ubiquity-kvstore-identifier

第一个是文档存储，第二个是键值存储。做好这些准备工作，就可以把应用程序沙盒里的文档转移到iCloud的存储中了。申请的权限可以确保应用生成的数据被沙盒化，并且不会被别的应用访问。

1. 在应用（或者应用套件）中共享数据

在iCloud中，需要通过唯一的ID来识别和申请数据存储容器。通常是应用的App ID，不过也不一定。两个应用可以使用同一个iCloud数据存储容器，从而共享数据。这个特性非常强大，尤其是在开发同一个应用的免费版和专业版时。这样开发者就可以用同一个容器的ID，它意味着一个用户用免费版创建的数据在他购买专业版之后直接可用，因此迁移过程变得更容易。开发者还可以用这种技术在其创建的应用套件中共享数据。

在被iOS设备上运行的iCloud守护进程转移到iCloud之前，iCloud数据存储一直位于用户的iPhone上。一旦开发者把文档转移到iCloud存储，就可以安全地删除原始副本了，因为接下来的编辑会自动发生在存储于iCloud中的文件上。开发者不需要操心怎么把文件上传到远程数据源，也不需要为断网劳神。iCloud守护进程会自动处理好这些同步问题。不过，开发者需要解决冲突问题。iCloud遵循的默认冲突解决策略是选择最后修改的文档。尽管大部分情况下没问题，但还是应该具体应用具体分析。

2. 在iCloud容器中存储数据

从iOS 5开始，每种设备上的Settings应用都有一个iCloud部分，可以让用户看到iClound中有多少数据用于备份，有多少数据用于应用的同步。当文件存储在iCloud容器中，用户看到的就是一大块数据；而当存储在Documents目录下，用户能看到独立的文件以及大小。Documents目录下的文件可以挨个儿删除，但没有存储在这个目录下的数据看起来就是一大块，只能同时删除。为避免混淆并方便操作，应该把所有用户生成的文件存储在Documents目录下，而把不想让用户看到的繁杂的元数据存储在这个目录之外。

3. 关于iCloud备份的一些信息

在iOS 5以前，当设备跟iTunes同步时，应用的Documents文件夹下的内容会自动备份。在iOS 5及后续版本的设备上，这些内容会备份到iCloud，但开发者手动保存在iCloud的Documents中的数据不会包括在备份中（因为它们已经在iCloud中了）。要注意这个自动备份和iCloud同步是不同的。备份文档被当做不透明的数据，只能用来完全恢复一个iOS设备。而无论是通过编程还是用户，都无法访问单个文件。

4. 缺陷

尽管iCloud为用户数据提供了无缝同步和方便的冲突管理，但没有REST API可以用来访问应用存储的数据。而如果开发者要为产品提供一个Web前端的话，REST API是很重要的。任何以服务形式提供跨设备同步的软件都在考虑有没有可能在不久的将来推出基于Web的应用，而iCloud缺失REST API就意味着这基本不可能。尽管苹果自家的应用（Mail、Contacts、Calendar、Reminders和Notes）有很棒的Web前端，但是直到iOS 6都没有提到iCloud的REST API。

缺乏可以用来查看数据的Web接口也使调试变得困难。对于iCloud来说，调试更难，开发者获知数据被备份到iCloud的唯一途径是看到另一台设备成功下载并显示了数据。调试周期长使产品的开发时间成倍增加。

原文地址：http://wiki.eoe.cn/page/iOS_pptl_artile_28162.html