(转） iCloud Storage 详细的官方文档
(转） iCloud Storage 详细的官方文档
官方地址：iOSAppProgramming Guide -> iCloud Storage
iCloud支持两种应用存储：
- document storage：存储用户文档和应用数据到用户的iCloud账户
- key-value datastorage：分享小量的非关键配置数据到应用的多个实例
iCloudApp的设计考虑
首先需要确认的是采用document storage还是key-value datastorage。documentstorage用于存储应用数据，要么是应用创建并私有管理的数据，要么是用户创建的数据。所有用户面对的数据都应该是documentstorage，例如用户创建的文档。key-value datastorage主要用于非关键的配置数据，你希望在多个app实例中共享，例如应用使用的参数和配置信息（典型的例子如Newsstand应用中用户上一次阅读的刊物和阅读位置）。
document storage和 key-value data storage的区别：
| 属性 | Document Storage | Key-Value storage |
| 管理的数据类型？ | 文件和目录 | 只能是Property-list数据 |
| 什么时候应该使用？ | 使用Document Storage来管理应用的关键数据。与应用main datamodel直接相关的文件和数据，总是应该使用DocumentStorage。如用户文档、私有的app数据文件、以及应用或用户生成的数据文件 | 参数或其它配置数据，如果需要在多个app实例之间共享，并且不是关键数据，就可以使用key-vlauestorage。只能存储property list数据，并且容量有限。 |
| 是否需要file presenter和file coordinator | 是 | 否 |
| 怎样定位数据？ | 使用 NSMetadataQuery 对象来查找文件 | 使用默认的 NSUbiquitousKeyValueStore对象来获取已知key对应的值 |
| 如何管理数据？ | 使用NSFileManager类来管理文件和目录。使用标准文件系统函数来打开、关闭、读取和写入文件 | 使用默认的NSUbiquitousKeyValueStore 对象来获取和设置key和value |
| 能存储多少数据？ | 只受用户iCloud账户的空间限制 | 限制为64KB（单个key也限制为64KB） |
| 怎样处理冲突？ | 应用的 file presenters 必须手工解决冲突 | 最后设置的值总是当前值。设备提供的时间戳用于确定最新的值 |
| 要求设置哪个entitlement？ | com.apple.developer.ubiquity-container-identifiers | com.apple.developer.ubiquity-kvstore-identifier |
| 数据什么时候同步？ | 设备端发生变化时，iCloud总是会拉取文件元数据和数据；设备总是会拉取文件元数据，但是直到应用试图使用文件时才会拉取文件数据 | 定期在设备和iCloud之间传输key-value数据 |
| 怎样在运行时检查iCloud可用？ | 对某个你已经注册的容器目录调用 URLForUbiquityContainerIdentifier:方法，如果方法返回nil，表示document storage不可用 | 调用 NSUbiquitousKeyValueStore 的 synchronize方法，如果返回YES，iCloud可用，并且有修改同步到本地用户默认数据库；如果返回NO，iCloud要么不可用，要么没有变化需要同步。无论如何，都可以直接使用本地的用户默认数据库。 |
| 系统提供了什么用户界面支持？ | 没有，应用负责提供支持iCloud的信息和界面。 | 没有，多数情况下，你不应该让用户知道key-value数据存储在本地还是iCloud中。 |
另一个设计考虑是应用的用户界面如何整合iCloud支持。特别是文档，有时候你需要提醒用户文档的状态，比如是否已经下载、版本冲突需要解决等。一般都需要在界面上增加一些不引人注目的元素，以在适当的时候提示用户。
配置应用的iCloudEntitlements
使用iCloud的应用必须以iCloud特定的Entitlements签名。这些entitlements为应用提供一层安全性，确保只有你的应用才能访问自己创建的文档。系统也依赖于你提供的Entitlement值来区分用户iCloud账户中你的应用与其它应用的文档。
Xcode中启用iCloudEntitlements：
- 选择应用的target
- 选择Summary
- 在Entitlements中，勾选"EnableEntitlements"
当你启用Apptarget的Entitlements时，Xcode自动为你的应用配置了document storage和key-value datastorage。每个Entitlement包含一个key，是一个或多个容器标识字符串。容器标识字符串标识了iCloud中的一个容器目录，你用来存储应用的文件。
Xcode按以下方式来配置Entitlements：
- iCloud容器域标识了应用在用户iCloud存储中能够访问的容器目录（这个域对应于com.apple.developer.ubiquity-container-identifiers）。你添加到这个列表的字符串必须匹配你的团队创建的应用bundleID。Xcode使用当前app的bundleID来指定第一个字符串，如果你希望多个app共享一个main容器目录，你可以修改为不同的bundleID。你还可以为团队的其它应用添加额外的bundleID（第一个字符串必须不包含任何通配符，随后的字符串则可以包含通配符）
- iCloud的key-value存储域包含应用存储到iCloud的key-value datastorage的单个容器标识字符串（对应于 com.apple.developer.ubiquity-kvstore-identifier）
你在Xcode中设置的bundleID并不是完整限定的容器标识字符串。完整限定的容器标识的格式是： <TEAM_ID>.<BUNDLE_IDENTIFIER>，其中<TEAM_ID>是10个字符的团队标识；<BUNDLE_IDENTIFIER>则是iCloud容器域中的某个bundle ID。当在代码中获取某个容器目录的URL时，你需要传递完整限定的字符串给 URLForUbiquityContainerIdentifier:方法。不过你也可以传递nil，来获取列表中的第一个容器目录的URL
通过在Entitlements中指定多个容器标识，使用iCloud documentstorage的应用可以读取和写入内容到多个容器目录。iCloud容器域允许你指定多个字符串。第一个字符串是应用的main容器标识，任何额外的字符串则代表你其它应用的容器标识。查找时会返回所有可用容器目录中的所有文件。
使用iCloud DocumentStorage
iCloud DocumentStorage让你将文件和目录移动到用户的iCloud账户，并在那里管理这些文件。在某个设备上修改文件或目录，会先存储在本地，然后再通过本地daemon进程push到iCloud。文件传输对应用是透明的，因此应用只需直接操作文件。
设计应用使用iCloud DocumentStorage，需要一些重大的应用修改，主要包括：
- 应用执行的早期，调用 URLForUbiquityContainerIdentifier:方法检查iCloud是否启用。扩展应用Sandbox来包含应用请求的每个容器目录，也需要调用这个方法。
- 显式地整合 filepresenters（如UIDocument类）到应用的数据层
- 显式地移动文件到iCloud
- 准备好处理版本冲突
- 使用查找来定位iCloud中的文件
- 处理文件在iCloud中，但是没有完全下载到本地设备的情况；可能需要向用户提供及时的反馈
- 如果要在iCloud中存储live database，使用CoreData，不要使用SQLite
- 如果应用还有Mac OSX版本，为所有应用使用通用文档格式
App支持iCloud的大部分工作都在数据层。与iCloud的交互也主要是应用要存储使用的文件和目录。不过底层数据变化时，用户界面也需要一定的修改，以通知用户相关的状态。当然，应用应该尽可能地让用户无需关心本地还是iCloud存储。
检查iCloud DocumentStorage是否可用
每个AppleID用户都有一个免费的iCloud账户，但是用户可能禁用某个设备的iCloud。因此使用iCloud接口之前，必须先调用 URLForUbiquityContainerIdentifier:方法检确定iCloud是否可用。返回nil表示不可用，返回URL表示可用
第一次对指定的容器目录调用 URLForUbiquityContainerIdentifier:方法，iOS会扩展应用Sandbox来包含该容器目录。因此需要至少成功调用一次该方法，以确保iCloud可用，main容器目录也可以访问。
整合 File Presenters到应用
iCloud中存储的所有文件和目录都由filepresenter对象管理；你对这些文件和目录的修改都必须通过一个filecoordinator对象。
filepresenter实现了 NSFilePresenter协议，主要的职责是作为特定文件或目录的响应代理。在外部源能够修改一个文件之前，注册的filepresenter会得到通知，并有机会执行任何必要的簿记（bookkeeping）工作。
当应用想要修改一个文件时，它必须通过一个 NSFileCoordinator对象来执行修改，本质上会锁住文件。file coordinator 阻止外部源修改文件，并且递送相关的通知给其它 filepresenters。
整合 filepresenter 到应用最简单的方法是使用 UIDocument 类。这个类实现了 NSFilePresenter协议，并为你处理了所有文件相关的管理。应用唯一需要做的事情，就是在得到通知时，读取和写入文档数据。不管是用户生成内容的文件（因此直接显示给用户），还是应用替用户创建的文件（无需用户交互），都可以使用UIDocument。
操作iCloud中的文件和目录
iCloud文件和目录和本地文件目录一样，应用使用相同的技术来管理文件和目录。你可以打开、创建、移动、复制、读取、写入、删除、以及其它操作。本地文件目录和iCloud文件目录的唯一区别是访问的URL不同。本地文件目录的URL相对于应用Sandbox，而iCloud文件目录的URL则相对于相应的iCloud容器目录。
要移动一个文件或目录到iCloud：
- 在应用Sandbox中创建本地文件或目录。使用的时候，必须由filepresenter来管理文件或目录。如UIDocument
- 使用 URLForUbiquityContainerIdentifier:方法获取iCloud容器目录的URL
- 使用容器目录URL来构建一个新的URL，指定文件或目录在iCloud中的存储位置
- 调用 NSFileManager的 setUbiquitous:itemAtURL:destinationURL:error:方法移动文件或目录到iCloud。绝对不要在应用的主线程中调用这个方法，否则可能会长时间阻塞主线程，或者与应用所拥有的filepresenter产生死锁。
移动一个文件或目录到iCloud时，系统从应用Sandbox中复制该item到private本地存储，这样才能被iClouddaemon监测到。尽管文件此时已经不在应用Sandbox中，应用仍然对其拥有完全访问。虽然文件仍然有一份拷贝保留在当前设备的本地，文件同时还发送到了iCloud，这样就能分布到其它设备去。iClouddaemon处理了所有工作，确保本地拷贝与iCloud是相同的。因此从应用的角度来说，文件就是在iCloud中。
你对iCloud中的文件和目录的所有修改都需要使用一个 filecoordinator 对象。包括移动、删除、复制、重命名等操作。file coordinator确保iClouddaemon不会同时修改文件或目录，并确保你修改时能够及时地通知其它人。
命名文件和目录时，尽量使用字母数字，避免使用特殊标点和其它特殊字符。同时你还应该假设文件名是大小写不敏感的（因为iCloud支持Windows）。最后尽量保持文件名简单，以确保这些文件能够在不同文件系统中正确地处理。
选择一种响应版本冲突的策略
iCloud文件的版本冲突不可避免，因此应用必须对冲突采取一种解决策略。当应用的两个实例同时修改一个文件并传输给iCloud时就会发生冲突。iCloud会保存所有冲突的版本，并通知应用的filepresenter发生了冲突需要解决。
App应该尽快地尝试解决版本冲突，当冲突发生时，其中一个文件被指定为currentfile，其它所有版本都是冲突版本。当前文件和冲突版本文件都由 NSFileVersion对象来管理，可以通过类方法来获取。
解决冲突：
- 使用类方法 currentVersionOfItemAtURL:获取当前文件版本
- 使用类方法 unresolvedConflictVersionsOfItemAtURL:获取所有冲突版本的数组
- 对每个fileversion对象，执行以下任何动作来解决冲突：[list=1]
- 如果实际可行的话，合并冲突文件修改的数据
- 如果能够安全地执行而不丢失数据的话，忽略某个冲突版本
- 提示用户选择保留哪个版本的文件（当前文件或冲突文件），这是最后的选择。
更新当前文件：
- 如果当前文件胜利（winner），不需要更新当前文件
- 如果某个冲突版本胜利（winner），使用 coordinated write操作，以冲突版本的文件内容覆盖当前文件
- 如果用户选择保存冲突版本为另一个名字，以该冲突版本的内容创建一个新文件
设置所有冲突版本对象的 resolved属性为YES。设置这个属性会导致冲突版本对象（及相应的文件）从用户的iCloudstorage中删除。如果使用UIDocument类，你通过 observing文档状态变化通知，并检查 documentState属性来判断是否发生冲突
如果使用自定义 filepresenter，每当报告有一个新版本时，你都应该检查它是否冲突版本。
整合查找（Search）到应用基础架构
和应用Sandbox不同，iCloud中的文件添加和删除，你的应用可能都不会直接知道。在这台设备上创建的文件，最终会出现在另一台设备中。如果应用不主动查找文件，那就不能及时地出现在用户界面中。因此应用需要使用NSMetadataQuery 对象来查找iCloud容器目录中的文件或目录。
当应用在前台时，你可以保留一个 metadata query一直运行，来接收文件添加或删除的通知；应用进入后台时，就停止这个 metadata query查询。
只有 iCloud启用，并且相应的容器目录已经创建时，metadata查询才会有返回结果。在运行时，确保使用 URLForUbiquityContainerIdentifier:方法来检测iCloud已经启用，而且应用支持的容器目录也可用。这个方法在容器目录不存在时，会自动创建出来。
Metadata查找应用entitlement中设置的所有容器目录，并返回合并后的所有结果。如果你希望只查找一个容器目录，可以使用 URLForUbiquityContainerIdentifier:方法来获得该容器目录的URL，然后使用 NSFileManager类来获取目录内容的静态列表。
确定文件或目录的传输状态
你写到iCloud容器目录的item会尽可能快地自动传输到iCloud服务器。但是由于网络和设备类型的原因，文件或目录可能不会立即下载到设备或上传到服务器。如果你需要确定文件的状态，可以使用NSURL 的 getResourceValue:forKey:error: 方法，来获取以下属性的值：
- NSURLIsUbiquitousItemKey：表示item是否存储在iCloud
- NSURLUbiquitousItemIsDownloadedKey：表示当前版本是否已经下载并且可访问
- NSURLUbiquitousItemIsDownloadingKey：表示当前版本是否正在下载并且暂时不可用
- NSURLUbiquitousItemPercentDownloadedKey：对于正在下载的item，表示已经下载的修改的百分比。可以使用这个值来更新进度条。
- NSURLUbiquitousItemIsUploadedKey：表示本地的修改是否成功上传到iCloud服务器
- NSURLUbiquitousItemIsUploadingKey：表示本地的修改是否正在上传到服务器
- NSURLUbiquitousItemPercentUploadedKey：对于正在上传的item，表示当前已经上传的修改的百分比
虽然iCloud服务器会非常努力地拉取应用在本地做的修改，但是iOS设备通常却不会主动从服务器拉取修改，除非你试图访问该文件。如果你试图打开一个正在下载的文件，iOS会阻塞发起打开请求的线程，直到文件被完全下载并且可用。因此如果你担心潜在的延迟，就根据需要检查文件的当前状态，同时更新用户界面，提示用户当前文件正在下载，暂时不可用。
使用尚未下载完成的文件
iCloud中的文件发生改变时，iOS设备不会自动下载这些修改数据。相反iOS设备会下载文件的元数据，因此知道此时文件已经有修改。实际修改的数据只有以下情况发生时，才会被下载：
- 应用试图打开或访问文件
- 应用调用 startDownloadingUbiquitousItemAtURL:error:方法，显式地下载文件修改
如果应用打开尚未下载完成的文件，用于打开文件的 file coordinator会阻塞你的应用，直到文件或修改被完全下载。如果文件或修改比较大，可能会导致很差的用户体验，因此试图打开一个文件之前，应该首先检查文件的下载状态。NSURL类定义了iCloud item相关的属性，可以检查iCloud文件的状态
检查文件是否已经下载完成：
- (BOOL)downloadFileIfNotAvailable:(NSURL*)file {
NSNumber* isIniCloud = nil;
if ([filegetResourceValue:&isIniCloudforKey:NSURLIsUbiquitousItemKey error:nil]) {
// If theitem is in iCloud, see if it is downloaded.
if([isIniCloud boolValue]) {
NSNumber* isDownloaded = nil;
if ([filegetResourceValue:&isDownloadedforKey:NSURLUbiquitousItemIsDownloadedKey error:nil]) {
if([isDownloaded boolValue])
return YES;
//Download the file.
NSFileManager* fm = [NSFileManagerdefaultManager];
[fmstartDownloadingUbiquitousItemAtURL:file error:nil];
returnNO;
}
}
}
// Return YES as long as anexplicit download was not started.
return YES;
}
为iCloud调整用户界面
所有为了iCloud所做的用户界面调整，都应该尽量不引人注意。当iCloud不可用时，你存储在iCloud中的文档和你存储在本地是完全一样的。唯一的区别是文件系统中的位置。因此大部分用户界面都应该保持一致。
以下情况可能需要针对iCloud修改用户界面：
- 当用户生成的文档在使用之前必须被下载。只有你提供了文档浏览器，才需要让用户来控制是否下载文档。应用使用的私有文件，应该在不可用时自动去服务器下载。你用来提示用户的信息应该尽量友好，并提供用户“开始文档下载”的选项。如果下载时间可能超过几秒钟，你需要显示一个当前下载进度。
- 当出现必须由用户解决的版本冲突。如果应用需要用户协助，才能解决冲突，就应该友好地提示冲突信息，但千万不要显示警告，或其它任何破坏性的界面。
- 当你希望提供用户选项，为应用启用或禁用iCloud时。如果应用包含一个SettingsBundle或者内部的参数设置，你可以提供一个参数，让用户选择是否使用iCloud。
iCloud结合Database使用
只有应用使用CoreData来管理数据库时，才能将SQLite数据库整合到iCloud。不支持使用SQLite接口访问iCloud中的live数据库，这样做很可能会毁坏你的数据库。
但是只要你遵守一些额外的步骤，来设置Core Data结构，你就可以创建基于SQLite的CoreData，从而启用iCloud支持。当然，其它类型的Core DataStore（不基于SQLite），则无需修改可以直接支持iCloud。
使用Core Data和SQLite store时，实际的数据库文件不会传输到iCloud服务器。相反，每个设备都维护自己的SQLitestore拷贝，并通过将修改写入到日志文件来同步它的内容。设备与iCloud之间真正传输的是log file，在每个设备中，CoreData拿到logfile的内容，然后使用这些内容来更新本地数据库。当然最终的效果就是每个本地数据库都拥有完全相同的修改。
设置Core Data store来处理iCloud，只需要你执行很少的额外工作。但是具体的步骤取决于你使用CoreData store作为中央库（Central Library），还是为单个文档分别创建独立的Core DataStore。
使用Core Data管理文档
应 用管理Core Data store为单独的文档时，可使用 UIManagedDocument对象来管理单个文档。UIManagedDocument 类自动在应用bundle中查找所有managed objectmodel，并使用它们作为文档数据的基础（你也可以覆盖 managedObjectModel 属性自定义指定子类的objectmodels）。由于大部分数据由managed object context处理，意味着你通常可以直接使用UIManagedDocument类而不需要继承子类。UIDocumemnt的自动保存行为，能够自动处理所有文档的保存工作。
创建新文档时，执行以下步骤：
- 创建 UIManagedDocument 对象
- 文档的 persistentStoreOptions属性是一个Dictionary，添加一个 NSPersistentStoreUbiquitousContentNameKey键，值为你标识该文档的唯一名字。
- 添加一些初始化数据到文档
- 使用 saveToURL:forSaveOperation:completionHandler:方法将文档保存到磁盘。保存文档时，你也可以直接将它保存到iCloud；或者先保存在本地目录，然后再移动到iCloud。保存到iCloud需使用 URLForUbiquityContainerIdentifier:方法获得相对iCloud的URL；如果已经保存到本地，则可以使用 setUbiquitous:itemAtURL:destinationURL:error:方法将其移到iCloud
当 你创建一个新文档时，Core Data创建一个filepackage，包含文档的内容。这些内容有一个 DocumentMetadata.plist文件，以及一个包含SQLite data store的目录。除了SQLite data store（保留在本地），filepackage中的任何东西都会被传输到iCloud服务器。
打开iCloud中的现有文档时，执行以下步骤：
- 使用 NSMetadataQuery 查找iCloud中的文档，Metadata查找会标识你iCloud中的所有Core Data文档。如果文档是其它设备创建，文档filepackage最初只有 DocumentMetadata.plist 一个文件。
- 打开 DocumentMetadata.plist文件，并获取 NSPersistentStoreUbiquitousContentNameKey键的值
- 创建 UIManagedDocument 对象
- 添加 NSPersistentStoreUbiquitousContentNameKey键到文档的 persistentStoreOptions属性。这个键的值就是你在第2步中获取的值
- 调用文档对象的 openWithCompletionHandler:方法来打开文档
应 用第一次打开其它设备创建的Core Data文档时，Core Data会自动检测到SQLitestore不存在，并在本地创建一个。然后使用 NSPersistentStoreUbiquitousContentNameKey键的值（你添加到属性的那个）来获取适当的transactionlogs，并重新构建数据库的内容。从这时候开始，你就可以修改该文档并保存到iCloud。你所做的修改会保存到新的logfile，这样其它设备就能将其整合到它们的SQLite store。
当应用从iCloud中 接收到文档修改时，CoreData会自动将这些修改合并到文档的SQLitestore，并给应用发送 NSPersistentStoreDidImportUbiquitousContentChangesNotification通知。应用必须注册这个通知，并使用它来刷新任何修改的记录。如果应用不刷新本地的数据拷贝，就会将老的修改重新写到iCloud，并产生一个冲突版本。通过及时地整合其它设备的修改，应用就能避免类似的冲突。
删 除一个文档时，你必须同时删除文档的file package，以及包含文档transactionlogs的目录。同时删除所有这些东西，要求你使用 NSFileCoordinator对象来执行coordinated写入操作。文档的DocumentMetadata.plist文件包含一个 NSPersistentStoreUbiquitousContentURLKey键，它的值就是文档transaction logs目录的URL。
使用Core Data管理中央库（Central Library）
如果应用使 用Central Core Data store来管理数据，就应该将datastore直接存放在应用Sandbox目录。使用一个Central data store的应用，通常只有一个persistentstore coordinator对象和一个persistent store对象。因此，最简单的解决办法是将Core Datastore保留在应用Sandbox，仅使用iCloud来同步修改。
在本地创建SQLite store时，执行以下步骤：
- 创 建datastore时，调用 addPersistentStoreWithType:configuration:URL:options:error:方法，并在传递的optionsDictionary中包含 NSPersistentStoreUbiquitousContentNameKey和 NSPersistentStoreUbiquitousContentURLKey 键。
- 注册 NSPersistentStoreDidImportUbiquitousContentChangesNotification通知，并使用它来更新所有的记录更新。
因为你只有一个datastore，你可以为 NSPersistentStoreUbiquitousContentNameKey键指定任何名字。对于 NSPersistentStoreUbiquitousContentURLKey键，应该指定为应用某个iCloud容 器目录中的某个目录URL。换句话说，这个URL应该基于URLForUbiquityContainerIdentifier: 方法返回的URL构造而成。CoreData将修改写入到你指定的这个目录，其它设备则在这个目录中查找修改。当检测到修改时，CoreData会自动整合修改到本地的SQLite store，并通知你的应用。
同样，你也必须及时地响应iCloud相关的修改通知。这些通知使应用能确保使用最新的数据，如果你使用老版本的数据，就可能覆盖其它设备的新数据，并产生冲突版本。
为Core Data Transaction Logs指定自定义位置
应用Core Data Store的修改使用transaction logs来保存，这些logs存储在用户iCloud账户的一个特殊目录中。应用的所有Core DataStores全部使用同一个目录来保存transaction logs。默认情况下，这个目录的名字和应用bundleID相同，并保存在应用默认iCloud容器目录中。如果你已经使用这个目录作为其它用途，你可以通过修改CoreData stores的选项来修改目录的名字。
在 基于文档的应用中，要自定义transaction logs目录，必须修改每个 UIManagedDocument对象的 persistentStoreOptions属性Dictionary。在字典中增加 NSPersistentStoreUbiquitousContentURLKey键，并设置值为你希望使用的自定义目录URL。这个URL需要首先使用 URLForUbiquityContainerIdentifier:方法，并通过添加额外的路径来扩展URL。
如果应用使用单一的Core Data store管理所有数据，在创建 persistentstore时，调用 addPersistentStoreWithType:configuration:URL:options:error:方法，并在options参数中增加 NSPersistentStoreUbiquitousContentURLKey键，值也是你希望设置的目录URL。
使用iCloudKey-Value Data Storage
应用使用iCloud Key-Value datastorage来存储参数、或小量的非关键配置数据。key-value data storage概念上类似于本地userdefaults数据库，应用通常用来存储配置。区别在于iCloud数据在用户所有设备中你的所有应用实例间共享。
使 用 NSUbiquitousKeyValueStore类需要设置"com.apple.developer.ubiquity-kvstore-identifier"Entitlement，如果多个不同的应用配置相同的entitlement值，则这些应用都可以共享相同的key-value数据。
使用 NSUbiquitousKeyValueStore 类写入数据到iCloud key-value store，这个类概念上也类似于NSUserDefaults，用于保存和获取简单的数据类型：数字、字符串、日期、数组等等。
应 用的key-value store的容量限制为64KB（而每个键的限制当前也是64KB）。因此应用只能使用key-valuestorage记录很少的数据，不能用于存储用户文档或其它大型数据archive。典型的例子是杂志应用，可以保存用户当前阅读的刊物和页数。这样用户在其它设备打开相同应用时，就能回到之前阅读的位置。
NSUbiquitousKeyValueStore 类绝对无法代替 NSUserDefaults类，应用总是应该通过 NSUserDefaults 将所有配置数据保存在本地磁盘。然后再使用NSUbiquitousKeyValueStore 将需要共享的数据上传到key-valuestore。这样确保iCloud不可用时，你仍然能够访问应用的配置数据。
负责任的iCloudApp
用户的iCloud空间有限，并且由所有应用共享。用户可以查看指定应用消耗的iCloud空间，可以选择删除应用相关联的文档和数据。因此，应用必须对自己存储在iCloud中的文件负责，下面是一些管理iCloud文档的建议：
- 对存储iCloud文档采取一种好的策略。允许用户启用或禁用iCloud。
- 从用户iCloud账户中删除一个文档，将从用户所有计算机和设备中删除该文档。确保用户明白这一点，并确认删除操作。如果你只是想刷新文档的本地拷贝，使用NSFileManager 的 evictUbiquitousItemAtURL:error:方法，而不是删除文件。
- 存储文档到iCloud时，尽量将文档存储在"Documents"子目录中。用户可以单个删除Documents目录中的文档以释放空间，但是Documents目录之外的所有东西，都被当做数据，只能一次全部删除！
- 永远不要存储缓存或其它应用的私有文件到用户的iCloud storage。用户的iCloud账户只应该用于存储用户相关的数据，以及应用无法重新生成的内容。
- 对iCloud文件和应用Sandbox文件相同对待。保存文件应该由应用需求和保留用户数据的需求来驱动。你不应该修改应用更频繁或更慢地保存iCloud文件。iCloud会自动优化自己向服务器的传输，以确保最佳的性能。
- http://www.cocoachina.com/bbs/read.php?tid=86249&keyword=icloud