使用Core Data应避免的十个错误

原文：Avoiding Ten Big Mistakes iOS Developers Make with Core Data 

 http://www.cocoachina.com/applenews/devnews/2014/0219/7851.html

 

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的教程。可在此查看本书概要。