我正在构建一个基于healthKit的应用程序，并且想知道如何持久保存healthKit数据。iOS最佳性能持久数据解决方案？
我目前的方法是获取数据并将其保存为自定义类对象的属性，然后将其作为NSData保存在核心数据中。
在性能方面Realm比CoreData快吗？
根据http://qiita.com/moriyaman/items/1a2916f4c2b79e934370 CoreData显然比FMDB慢于Realm。即使在考虑到故障和索引后，有人可以确认这是否属实？
声明：我在境界
的这持续的产品将执行你所提到的解决方案中最好是高度依赖于数据的类型/数量/频率的问题的工作。由于核心数据和FMDB是SQLite上的层，它们的设计速度不能比SQLite快，但它们为许多用户提供了足够的便利性，因此值得。另一方面，Realm不是基于SQLite，而是基于专为现代智能手机设计的自定义数据库引擎。它旨在在强大的功能和简单的API之间达到更好的平衡，而不会增加大的性能影响。
你可以看到在领域的推出博客文章比较境界/ SQLite的/核心数据/ FMDB这里公开基准测试：http://realm.io/news/introducing-realm#fast
最后，您使用类似NSCoding序列化HealthKit信息进入的NSData的方法将是非常低效。无论您选择何种持久性解决方案，您都可以更好地使用内置于这些产品的序列化服务，而不是存储已经序列化的数据blob。
正如我对@jpsim所说的，很难简单地将核心数据的性能与FMDB等较低级别的框架或像Realm这样的不同抽象的框架进行比较。您选择哪种方法会对您的程序构建产生巨大影响，这会影响到不同地方的性能问题。
核心数据和SQLite解决了非常不同的问题。 SQLite是一个关系数据库。核心数据是一个对象持久性引擎。我并不是Realm的专家，但它似乎试图在这两种方法之间取得平衡，并采用比Core Data更低级别的控制，但与SQLite更接近对象模型。 Realm（至少在我的印象中）给你更低级别的控制这一事实为你优化事情或者弄乱IMO提供了机会。这既不好也不坏，它使苹果与苹果比较它们变得困难，特别是使通用的“性能基准”成为问题。问题不在于某人是否可以使用引擎A和引擎B编写更快的代码。问题是您是否可能在每个引擎中编写可接受的高性能代码，同时避免错误并尽量减少开发时间。
一般而言，我相信HealthKit数据应该存储在HealthKit中以保护隐私。无论如何，您应该小心将这些数据存储在自己的存储空间中。尤其要小心的the guidelines about iCloud：使用
应用存储用户的iCloud中的健康信息将被拒绝
的HealthKit框架，我不知道这将如何影响您存储和随后的文件备份到iCloud。只需将数据留在HealthKit中是不必担心这些问题的最佳方式。
无论如何，性能只是考虑的一个方面。您没有指出任何事情表明您有非常特殊的性能问题（例如，您正在处理数以万计的记录或实时数据等）。因此，我会首先关注哪种工具最适合您的一般需求，然后进行一些基本实验以确保性能合理，然后在发现问题时进行优化。
“由于核心数据和FMDB是通过SQLite进行分层的，所以它们不能比通过设计的SQLite更快。”这与“C建立在程序集之上”完全相同，因此您编写的任何程序集都会比您编写的任何C程序更快。“这根本不是事实。天真写入的程序集可能会比天真写入的C慢得多，而天真写入的SQLite可能比天真写入的Core Data慢得多。 SQLite和Core Data解决方案的问题截然不同，并且很难直接比较性能，因为每个方法都会显着影响您应该如何编写程序。 – 2015-03-19 18:43:49
我绝对同意将ORM与关系数据库与非关系数据库进行比较绝对不是苹果与苹果之间的比较，编写程序的方式也会产生重大影响。天真书写的代码总是会影响性能。程序员对他们正在使用的工具的理解和经验水平也会产生重大影响。 – jpsim 2015-03-19 20:12:29
@jpsim Realm后端基于LMDB？它是否像forntends一样开源？ – Maniero 2017-11-03 17:29:27