我正在構建一個基於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