iOS 开发技术选型之数据库:SQLite vs. Core Data vs. Realm

持久化方案

在 iOS 开发中,数据持久化存储是一个很常见的需求。所谓持久化存储,就是将数据存到硬盘,使得应用重启时还能从硬盘重新读取数据。来看看一些常见的持久化方案。

NSUserDefault

NSUserDefault 用来存储用户偏好设置和应用配置信息,适合小规模的数据。常见的比如应用启动的时候是否需要展示引导页,就可以在这里设置一个是否已显示过的标志。它的背后实际上是一个特殊的 .plist 文件。

Keychain

Keychain 用来存储一些敏感的数据,比如密码,token 等。由于相关的 API 比较底层,我们可以使用对其做了封装的更友好的第三方库,比如 FXKeychain

文件

  • Plist.plist 文件用来存储小规模的结构化的数据,用到的时候可以很方便的读取。常见的比如“省-城市”数据。但存储对象类型只能是这些:NSDataNSStringNSNumberNSDateNSArrayNSDictionary
  • NSKeyedArchiver:由于 Plist 对存储对象类型的限制,如果想存更大量的,结构更复杂的对象,就可以用归档。只需要自定义的数据类型遵守 NSCoding 协议。

数据库

上面提到的几种方案都是很轻量级的,一旦数据量更大,数据结构及关联关系更复杂,需要更频繁和方便的增删改查,我们就需要用上数据库来满足这些需求了。我们目前有这三种选择:

数据库方案

这里不展开讲每个方案的细节,毕竟数据库是计算机科学的一大知识体系,需要很深厚的功力才能讲得明白。我只讲讲方案选择的思路。

SQLite vs. Core Data/Realm

SQLite 是一个轻量级的跨平台数据库,适合存储查询需求较多,查询条件更复杂的数据。我曾经做过的一个项目中不同的移动平台使用了由服务端导出的同一个数据库,因为数据较多条件较复杂还专门请教了别的组的数据库专家来帮我们优化 sql 语句。

虽然 SQLite API 是基于 C/C++ 的,对习惯了面向对象编程的我们不够友好,但是不用担心,有很多第三方库对它做了很好的封装。比如 FMDB,让数据库操作更简单易懂。也因为它更底层,所以在数据查询时可以更加灵活。

但是 SQLite 有个让人无法忽视的缺点,就是需要我们手动搭建模型层,完成数据库表到对象模型的映射。所以,如果项目的数据规模较小,查询复杂度较小,又注重对象之间的关联关系,可以优先选择 Core Data/Realm 来更方便地搭建模型层。

Core Data vs. Realm

Core Data 在严格意义上来说,并不是数据库,而是由 Apple 提供的一套完整的数据管理方案,它的底层是通过 SQLite,XML 或二进制文件存储数据的。在数据存储之上,又提供了数据模型的解决方案。可以说它搭起了下层数据和上层对象之间的桥梁,将关系型数据转成对象,并通过对象图组织起来,进行自动管理。同时使得开发者可以面向对象编程。可以参考我之前写的一篇文章

Realm 是近几年兴起的并保持良好发展势头的全新的数据库方案。它不像 Core Data 那样采用 SQLite 作为内部核心,而是从头构建了自己的数据库引擎,获得了更好的性能。它最核心的理念是对象驱动,从而避免 ORM 架构以及其带来的抽象方式。它还是跨平台的,支持 iOS/macOS,Android。

一个是官方支持,经过漫长时间和无数应用的检验的 Core Data,一个是由第三方团队开发的,年轻但长势喜人的 Realm,我们该如何选择呢。

虽然 Realm 并没有完全解决 Core Data 那些令人头痛的问题,比如多线程问题,但它也确实做出了一些改进提升了开发体验。所以我个人的观点是,优先选择 Realm。具体原因最主要有以下两点:

  1. 更容易上手。我猜每一个开发者应该都曾吐槽过 Core Data 那陡峭的学习曲线吧。而 Realm 让开发者很容易就能创建一个模型,只要继承 RLMObject 就好了!除了简洁的 API,Realm 还提供了清爽的文档Xcode PluginRealm Browser,让开发体验更上一层楼。
  2. 更年轻,更有活力。Core Data 老了,它已经有很长一段时间没有得到实质性的改进。可能是 Apple 的工程师都忙着研究新技术等下一次发布会时震惊世界吧。而 Realm 有它的雄心壮志,它采用了更先进的技术,正在一点点变得更强大。除了 Realm 这个产品,Realm 团队还致力于创建更好的 iOS 开发社区,源源不断地发布了很多高质量的文章,是我最近非常喜欢做深入阅读的地方。

有人可能会提到性能问题,实际上移动端对数据库性能的要求远没有服务器端来的苛刻。一般规模的应用更注重的是代码的可维护性,最后才是性能调优。所以不同的数据库方案在性能方面虽然有所差异但对实际项目的影响几乎可以忽略。

总结

如果应用数据复杂度高,有频繁的读写需求,复杂的查询条件,可以选择 SQLite。但一般情况下,选择更容易上手,API 更简洁,对开发者更友好的 Realm 吧。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,542评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,596评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 158,021评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,682评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,792评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,985评论 1 291
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,107评论 3 410
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,845评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,299评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,612评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,747评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,441评论 4 333
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,072评论 3 317
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,828评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,069评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,545评论 2 362
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,658评论 2 350

推荐阅读更多精彩内容