Core Data

原文出处： informit   译文出处：cocoachina

Core Data是苹果针对Mac和iOS平台开发的一个框架，主要用来储存数据。对不少开发者来讲，Core Data比较容易入手，但很难精通，若是没有正确的学习方法，你将很难真正理解它，更不用说精通了。不少开发者经常在这方面犯一些错误，而这篇文章列出了开发者在iOS开发过程当中使用Core Data常见的一些错误，并对如何避免这些错误进行了分析。

 
1.不了解关键术语

对于iOS开发者来讲，会使用Core Data是一项必备技能。 没有它，不少app都不会存在。当在互联网上四处搜索Core Data学习教程，你很容易被各类各样的术语吓倒。事实上大部分学习教程都首先假定你已经知道了这些术语，而若是你不了解这些术语，那将会陷入困惑中。因此首先要知道关键的术语。这里有一个备忘单，能够用在学习Core Data的过程当中，这份备忘单展现了关键的词组：

在之后的学习过程当中，你会遇到更多的术语，但这些是初学者须要了解的最基本的部分。

2.彻底忽视Core Data

当一项技术以难学“闻名”时，你可能会忽略它，特别是当你时间不够，急着把app作出来的时候。

Core Data储存app数据的一个常见替代选择是使用XML属性列表，虽然属性列表可让你今天的工做变得轻松，但它们也会随后回过头来咬你一口。不管什么时候你编辑属性列表，发生的变化都是原子性的。这意味着即使是很小的更改要求，整个文件都会被加载到内存中，而后在保存的时候，整个文件都会被写回到硬盘。

随着数据量的增加，app也会变得愈来愈慢。可是若是你基于SQLite数据库使用Core Data时，这些性能问题就不会困扰你 。这样能够保持低内存占用，以保证app快速响应，并防止app因内存压力过大而崩溃。本质上说，Core Data之因此比属性类表更有扩展性的缘由是它支持使用数据库进行持久性储存。可扩展性并非Core Data的惟一优点，使用关系把数据组织进实体结构才是其强大之处。好比，考虑使用如下实体来表明一个任务 ：

该任务实体包含一个名称和subtask_name属性。当从任务实体中建立管理对象时，它将会有一个名称和subtask_name属性。

不依赖关系，这个数据模型仅支持一个subtask，如今考虑如下实体：

带有双箭头的线代表Task entity能够对应多个Subtask entity关系，这意味着一个任务能够有多个子任务，更没必要说涉及到的父任务也能经过逆关系被包含进来。这个灵活性不只方便，更节省了数据库的空间，由于父任务名称仅仅只需储存一次。若是你想要更进一步，让任务有子任务的子任务，下一步该怎么办？思考下从新构建如下任务实体：

模型如今支持无线深度的子任务，由于任务实体关联的是其自己！Core Data的可扩展性和灵活性还只是其优点中不多的一部分。Core Data并不只仅利用关系数据库的优点，并且你没必要写任何SQL语句来使用它。Core Data替你承担了责任，而且为你自动优化了生成的SQL语句。

我尚未深刻研究Core Data的其余价值方面，好比模型版本控制、迁移、验证以及变动管理和iCloud同步等等。若是有任何值得你投入时间的iOS框架，那就是Core Data。


3. 不使用模型版本控制和迁移

若是你已经编辑了一个管理对象模型，你可能已经犯了如下错误：

“此前用来打开store的模型不兼容之前用来建立store的模型”

当你建立数据持久化存储，它是基于一个特定的管理对象模型的。若是模型的结构发生了变化，那么持久化存储就必须更新以匹配。若是不这么作，store将会是不兼容的，而且不能打开。若是用户正使用的存储是基于你的没有使用版本控制的模型，那么app注定会崩溃。

为了确保模型迁移过程正常进行，你须要确保你在编辑模型前很是当心地添加了模型版本。

附注：一些变化，好比属性默认、有效性规则以及获取请求模板均可以被简化。

4.过多使用版本控制和迁移

一旦开发者了解到维持管理对象模型版本的简易，一些开发者难免会过度使用。这会产生一个过度复杂化的版本历史记录，若是每次更改都添加版本，这只会减缓模型的迁移。

在你发布Core Data app到App Store以前，你能够忽略版本控制，并按你喜欢的那样编辑模型。为避免“the store is incompatible”错误，能够简单地从开发设备上删除app，并再次在Xcode中运行。使用更新的模型部署一个新的持久化储存，就能够解决崩溃问题。一旦你把model version 1发布到App Store，你全部的用户将会有version 1的持久化存储。从这一点上来讲，若是更新模型则必须添加一个新版本。咱们假定你的用户正使用model version 1。当开发一个更新版的app，你已经添加了model versions 2, 3和4。使用如下小技巧能够减小版本历史，而不用发布model versions 2, 3，4…
删除model 2的内容
复制model 4内容至model 2
设置model 2为当前model
删除model 4

固然，你须要考虑model 1中的实体如何映射到更重要的model 2中，尤为在你没有使用轻量级迁移时。更加详细的关于model版本控制和迁移，可查看“Learning Core Data for iOS”这一个完整章节。

5.把一切留在内存中

你主要关注功能和特性，因此你很容易忘记那些不那么迷人的主题，好比保持低内存占用。有些开发者会在进行性能测试前急匆匆地发布应用，尤为是截止期限所迫的状况下。不过还好咱们仍有一些措施帮你保持低内存占用。

当你管理对象时，在内存方面可以使用管理对象context。一旦你完成了管理对象，你应该经过调用如下NSManagedObjectContext实例方法之一来移除它们。
经过重置来从context中移除全部管理对象。
使用refreshObject:mergeChanges并传入参数NO 从context中移除特定的对象。

使用以上任意一个方法能够确保未使用的对象没有浪费空间。为了在context中提升对象数目的可见性，可记录[[context registeredObjects] count]结果以方便在控制台中调试。

6.设计一个低质量的Managed Object Model

若是你储存照片、音频或者视频，你在模型设计上要十分当心。记住关键的一点是当你把managed object带入context时，你正把全部数据一并带入内存中。例如，若是一个managed object带有一个图像属性，该属性存储了一张很大的图片，同时一个表格视图使用它来建立众多实体对象并填充单元格， 那么app性能就会受到影响。即时你使用一个得到结果的控制器，你仍须要一次加载不少高分率的图片，这个操做不会马上执行。为了解决这一问题，持有大量对象的属性应该被分裂进一个关联实体。按照这个方法，大量对象能够被持久化存储。若是你须要在table view中展现照片，你应该使用自动生成缩略图代替。

7.不提早加载数据 

当你把模型加载进一个更新的app时，要注意不要意外地加载一个基于旧模型的默认数据存储。若是你这么作了，那么对一些用户来讲，可能会在运行应用的时候致使崩溃。这个威胁能够从根本上阻止开发者加载一个默认的数据存储。

若是有默认数据包含在app中，那app就更容易学习和使用了。一个程序越容易使用，那么用户就越有可能继续使用它。用户使用一款应用的时间越长，那么用户传播它的机会就越大，最后也会提高应用潜在的销售状况。为了不在提供默认数据的状况下出现的更新时崩溃现象，你须要一个好的测试策略。

另外，你也须要深入、准确地理解你想把什么样的模型版本和存储发布到App Store。你应该部署一个未改变的App Store应用版本到你的设备上，添加数据，而后完全测试升级进程。

8.只使用单一的Contexts 

Core Data的实现至少须要一个context 在主线程上操做。用户接口也需运行在主线程，所以任何减缓主线程的行为都会下降程序的响应能力。虽然使用一个context很是容易，可是性能问题会悄然出现，除非你的数据设置很是小。好比，若是你想要生成数据缩略图，或者导入一些数据，app就会这些过程当中出现阻塞现象。

自从iOS 5之后，管理多个context已经变得很是容易了。如今你能够配置一个context 层级，并在前台和后台运行一些contexts。经过配置后台context做为前台 context的父类，你就能够实现后台保存。经过配置后台context做为前台context的子类，你就能够像导入对象同样导入context来自动更新用户接口.

9.不理解iCloud Integration的局限性

iOS 7发布之后 ，Core Data集成iCloud的实现变得更加简单。iCloud一个关键性的限制是它的数据被约束在一个iCloud帐户中。因为iCloud帐户是与用户设备的方方面面交错在一块儿，因此分享iCloud帐户是不切实际的，不推荐的。这意味着iCloud 不能被用来共享。好比，假定一位丈夫和妻子想要在同一个购物列表上列出物品，这一点当前对iCloud来讲也是不可能的。

除了帐号限制，iCloud也不支持ordered relationships，也限制你的轻量级的model迁移。跳出这个圈子思考，若是你对app使用的收集分析统计比较感兴趣，你能够考虑使用Backend-as-a-Service (BaaS)。

10.不考虑现有的客户数据集成iCloud

在iOS 7中，iCloud集成Core Data已经容易了不少，不少开发者有信心在应用中支持它，此前用它来托管珍贵的用户数据并不稳定。这致使了不少现有的app仅有本地储存，好比我本身的‘Teamwork’ app。

iOS 7中iCloud重要的简化之一是fallback store的引入，它容许在iCloud accounts和iCloud Documents和Data之间无缝过渡。用户可使用支持iCloud的app，即使他们没有任何网络链接，并在有可用网络时把数据集成到iCloud中。

虽然这有点难以想象，基于iOS 7以前版本开发的 应用中，用于储存用户数据的本地存储方案都应该被遗忘。

若是你仅打开iCloud，那你将使用一个不一样的储存，而且你将须要把用户的本地数据合并到iCloud。在你尝试把用户数据集成到iCloud以前，你须要检查如下几点：
用户注册了iCloud吗？
用户想要在app中使用iCloud吗？
用户但愿把本地数据合并到iCloud吗？

若是以上的答案中有一个“no”，那么这个app应该能在将来处理不一样的答案。若是你的答案是“yes”，那么你须要管理用户本地数据迁移到iCloud的进程。当用户的多个设备上存有本地数据时，事情就变得有趣了。若是是这样，那你将须要考虑重复数据删除策略了。

总结

若是说有一个iOS框架值得你投入时间，那就是Core Data。若是你对它感兴趣，能够考虑个人新书–Learning Core Data for iOS。这是本基于iOS 7的书，带你领略整个Core Data的教程。可在此查看本书概要。

 

---

---

 

03.08更新----华丽丽的分割线

　　SQLite------>FMDB

　　　　1. 使用字符串进行DB操做

　　　　2. 不能无缝升级,要升级数据库只能本身手动建立新的数据库,迁移数据

　　　　3. 多表操做须要手写多表关联的Sql语句

　　CoreData------->MagicalRecord

　　　　1. 使用属性setter和getter进行DB操做

　　　　2. 能够无缝迁移数据

　　　　3. relationship多表操做,操做简单

　　　　4. CoreData+多线程 可能会发生死锁, 推荐使用 MagicalRecord