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。

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

如果你已经编辑了一个管理对象模型你可能已经犯了以下错误

“此前用来打开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, 34…
删除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的教程。可在此查看本书概要。

原文出处 informit 译文出处 cocoachina

文章转载自 开源中国社区 [http://www.oschina.net]