iOS 开发如果涉及数据和表的持久化，Core Data 比 SQLite 更好吗

这两个东西我都用过，两者都能实现对数据库的 *** 作，功能上需求都能满足。

先前在公司实习的时候，原先项目中用的是SQLite，感觉 *** 作很直接。如果先前有一点数据库和SQL基础的话，写起来会感觉很亲切，都是一些数据库 *** 作的语句。但是当 *** 作变多之后，语句越来越多，就很烦，代码比较多，看起来也会混乱一些。

后来新项目中尝试了CoreData，因为苹果一直在推这个东西。CoreData用起来比直接sql语句方便许多，而且很适合进行代码封装、重构。其实后来在用CoreData的时候，参照RestKit的ObjectMapping和CoreData部分对其进行了少量封装，使得CoreData用起来非常方便。例如：添加一条User数据

User user = [User object];

username = @"example";

[objectStore save];

后来做开发一直都在用CoreData，主要是我觉得用起来太方便了，代码能够精简许多。另外，

App升级之后数据库字段或者表有更改会导致crash，CoreData的版本管理和数据迁移变得非常有用，手动写sql语句 *** 作还是麻烦一些。

CoreData不光能 *** 纵SQLite，CoreData和iCloud的结合也很好，如果有这方面需求的话优先考虑CoreData。

CoreData并不是直接 *** 纵数据库，比如：使用CoreData时不能设置数据库的主键，目前仍需要手动 *** 作。

效率上其实跑程序时感觉不出来，毕竟手机上的数据不能跟网站的数据和访问量相提并论。

总的来说，个人比较喜欢用CoreData，因为自己比较熟悉，使用起来也非常方便。

PS：既然你一直在CoreData，就应该坚持用下去，除非是真的碰到很致命的无法解决问题。中途换掉既有的自己熟悉的东西，费时费力，实际用起来没区别，得不偿失。

转载

iOS开发，plist文件读写那些事 - (jianshucom)

NSUserDefaults存储轻量级 的本地数据 ，比如要保存一个登陆界面的数据，用户名、密码之类的。

支持的数据类型有 NSString、 NSNumber、NSInteger、NSFloat、BOOL、NSArray、NSDictionary、NSDate、 等系统定义的数据类型。

用NSUserDefaults存储的数据下次程序运行的时候依然存在 它的数据存储在应用程序内置的一个plist文件里, 在/Library/Prefereces沙盒路径下

NSUserDefaults是定时把缓存中的数据写入磁盘的，而不是即时写入，为了防止在写完NSUserDefaults后程序退出导致的数据丢失，可以在写入数据后使用synchronize强制立即将数据写入磁盘：

使用NSKeyedArchiver 对数据进行 归档 反归档（将自定义类型转换为NSData类型:）

NSuserDefaults 的坑

iOS 最终，我还是决定放弃使用NSUserDefaults了 - (jianshuio)

归档： ，就是将数据写到一个文件里面去。一般我们的应用的变量常量之类的数据都是在内存里面的，只要APP关闭，这些数据都会丢失。但是把数据存储到文件里面去，就能将数据保存到本地磁盘里面（目前iOS基本就是在沙盒里面 *** 作了），不管是APP关闭还是重启设备，下次启动APP的时候都能够读出来。

解档： (别人也叫反归档)，就是将数据从文件里面读取出来。在程序里面使用。

iOS数据持久化：使用NSKeyedArchiver进行数据归档 - (jianshucom)

iOS 开发Core Data使用方法 – 技术狗 (jishudogcom)

IOS 开发文件 *** 作——NSFileManager - 星语海蓝 - 博客园 (cnblogscom)

(15条消息) iOS文件 *** 作_你有故事，我囿酒-CSDN博客

参考：

iOS开发 - 关于 NSUserDefaults 的使用 - (jianshucom)

Realm是一个开源的面向对象移动数据库。上个月，Realm的Android版本发布了，比iOS版本晚了三个月。

我们之前已经报道过，Realm没有使用SQLite作为它的引擎，而是用C++写了自己的引擎，他们的目标是提供一个聚焦移动领域的SQLite的替代者。现在它的Android版本已经发布了。

当前Android上的Realm的API和iOS版本有点不同，这也反映了Objective C和Java的差别。Java版本的API有更高的强类型（strong-typed）要求，也更连贯（fluent）。

比如，在iOS上，查询是通过静态方法如"objectWhere"来进行的，这将返回一个RLMArray。这里的谓词都是基于字符串的。以下就是基于Object C的查询方法：

RLMArray tanDogs = [Dog objectsWhere:@"color = 'tan' AND name BEGINSWITH 'B'"];

另一方面，在Android下进行相同的查询却是这样的：

RealmResults<Dog> tanDogs = realmwhere(Dogclass)

equalTo("color", "tan")

beginsWith("name", "B")

findAll();

当然，这有可能会被一种跨iOS、Android和其他平台的文本查询语言所替代。Tim Anglade是Realm的产品主管，他在一封邮件中指出，未来API的发展方向很大程度取决于社区的反馈。

虽然Realm是一个面向对象的数据库，但它和其他同类产品还是有一些明显的不同。Tim解释道，当它用原生对象格式（native object format）来存储数据时，这些对象不会带着其语言特有的格式原封不动地存在磁盘上，而是通过C++引擎存储在一个全局的表中。这使得Realm可以通过各种语言来访问数据，还包括各种即时查询（adhoc query）。

相比关系数据库，这种混合了对象和表的方式的优势在于它使图查询（graph query）更高效——甚至在相对老旧的智能手机上，查询深度嵌套的对象图也不会影响系统反应速度。Realm发布的基准测试（benchmark）结果称，在普通 *** 作上，Realm的速度最快要达到原始的SQLite的10倍。

如果你现在有一个应用程序使用CoreData（iOS上）或SQLite（Android上），并且想迁移到Realm，肯定有一些事要做。这不是随便拿来就能用的——Tim解释说，CoreData和SQLite倾向于使用一种非常标准化的形式，这种做法在Realm上行不通。你最好从对象的角度重新思考你的模式（schema）和模型（model）。

一旦你修改了你的模式，使之适用于Realm，接下来把现有数据从CoreData/SQLite迁移过来就简单了。只要配置一次迁移 *** 作（从Realm数据库版本0到版本1），在迁移过程中，把你的SQLite数据加载到Realm对象中并保存它们。

或者，如果你的数据保存在远程服务器上，你可以从头新建Realm数据库。

在采用Realm之前，必须要考虑到它是一个最前沿的软件，这意味着将来它的API有可能做出和以前不兼容的修改。

你可以通过Android版本的Realm来了解更多，或者查看Github上的代码。

以上就是关于iOS 开发如果涉及数据和表的持久化，Core Data 比 SQLite 更好吗全部的内容，包括:iOS 开发如果涉及数据和表的持久化，Core Data 比 SQLite 更好吗、IOS 存储方式（PList、NSUserDefaults、归档、CoreData、数据库、文件）、android上有PropertyUtils的替代品吗等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！