作者：蕭宸宇

本文具有強烈的個人感情色彩,如有觀看不適,請盡快關閉。本文僅作為個人學習記錄使用，也歡迎在許可協議范圍內轉載或使用，請尊重版權並且保留原文鏈接，謝謝您的理解合作。如果您覺得本站對您能有幫助，您可以使用RSS方式訂閱本站，這樣您將能在第一時間獲取本站信息。

碎碎念

OhMyStar 2 也進行了一段時日，我把持久化的方式從CoreData 換到了 Realm。有些感悟，順手就記錄一下吧。以下評論都是自己很主觀的感受，無實際測試數據支持。

論 iOS 的持久化

iOS 持久化其實也沒多少選擇， 高端一點CoreData、Realm、FMDB、KV類(LevelDB等)。低端一些直接一個 NSArray 就寫成 Plist 也能持久化下來。

在網絡環境越來越快的當下和大部分應用數據都可能是網絡應用，如果業務邏輯並不復雜，其實極端一點就只用寫到 JSON 轉 Object 就好了。而且一堆這樣好用的封裝，遠有Mantle 近有YYModel。

所以需要持久化的時候，我覺的可以慎重的評估一下需求。想明白了，後面可以節省很多事情。

本文章主要對比 Realm 和 CoreData，其他的就不涉及了。

Realm

優點

入門門檻低

Realm文檔就算一個字一個字扣著讀完，一個下午就足夠了。而且還有中文版本，不要太友好哦，有點不習慣诶。

文檔覆蓋了80%的使用情況，甚至有些太簡陋的嫌疑。但不管怎麼樣，這種入門條件比起 CoreData 寫了三個月都沒搞清楚 Context 要好的多。

在庫的工具鏈上，安裝一個 Realm Browser 以後就不需要其他輔助了。還是簡單。

幾乎做到了上手即用的程度。五星好評。

PS：我用了一個通宵把 OhMyStar 2 的持久化從 CoreData 換到了 Realm ，優化調整了大概5天左右達到勉強可以用的情況 。在這之前並沒有任何 Realm 的經驗。

據說性能好一些

Realm官方介紹Fast一段中

Counts

Queries

Inserts

在寫這裡的時候我順手Google了一下 發現一篇Core Data, FMDB, Realm 性能測試。我就多說幾句

總覺得大家對 CoreData 誤會蠻深，代碼 Fork 看了一下， 總覺得不應該這樣寫來比性能的，但是一時半會也不知道怎麼改。我只能說我在優化 CoreData 的時候根據 WWDC 上教的還是提升很高，另外一個事情是 CoreData 一般都用 Sqlite 做後端。所以如果你的查詢是經過優化的，確認打出來的SQL語句科學以後，Sqlite(CoreData) 跟 Sqlite(FMDB)我覺得性能就算有差距，這差距沒有能大到選擇方案的決定性因素。如果使用 CoreData 遇到性能瓶頸，你應該仔細的研究 WWDC 和幾篇很好的文章。確保你的 CoreData 使用方式是正確科學的。

沒有需要架構Context那種煩人的東西

應該也算Realm簡單的一個方面，Realm 只要保持自己線程裡面，自己的 Realm Store 操作是正確的即可。如果是 CoreData，怎麼架構一個科學的 Context Stack 就足夠讓我頭疼一整，iOS 還好，界面是一個接著一個(VC跟VC之間的層級關系很清晰)。而 OhMyStar 2 這種 OS X 桌面應用場景VC之間很復雜，線程之間Context的關系讓出現很多問題。

支持 NSPredicate

從 CoreData 轉過來並沒有太多的不適應

很簡單的使用多個存儲文件

舉個例子，多用戶登陸情況下。用戶是單獨的存儲文件，和全部用戶使用同一個存儲文件。後者需要每條用戶數據都要關聯一次當前用戶，所有查詢用戶數據的時候，你都必須加上當前用戶的查詢項。而使用每個用戶單獨一個數據文件的時候，整個存儲結構會清爽很多。

技術支持

至少實在沒法的時候還可以去微博上吐槽他們，他們其實也有極大的熱情來解決你遇到的問題。CoreData 這種遇到問題就只能自己默默的吞下。

缺點

關聯關系弱的一逼

簡單說來就是對象跟對象之間的一對多關系和多對多關系。並不能映射，需要在雙方裡面都寫上屬性，此外還需要在設置的時候兩邊同時設置。查詢時候也是 NSPredicate 也僅僅只支持一些一層的查詢，沒法做出帶SUBQUERY的復雜查詢出來。

強制內省容錯機制導致存儲文件不斷變大

Realm本身感覺有一個數據容錯機制。但是這個機制在數據庫文件有錯誤的情況自己修復的時候，會無限增大。具體我這裡表現為，打開看只有3000條數據，但是文件大小已經有3GB。重現Bug也很容易，只要你在寫數據庫的時候,用Realm Browser查看一下，crash之後在打開就很容易出現。

官方文檔裡面有說到會造成這種情形的原因，我在盡我所能的避免問題以後。存儲文件還是會有可能不那麼誇張的變大一些。但是用Realm Browser查看數據是正常的。所以我覺得官方應該提供一個函數，可以刪除掉那些容易的東西。保持存儲文件的干淨。

沒有細粒化通知

也就是說，當我在某個地方做出修改。 我其他地方只知道Realm有修改，但是沒法知道我是增加、修改還是刪除了數據。不知道我更新的是那一條數據。據文檔說，將來會解決這個問題，就只有拭目以待。

增加包體積

據官方說會增加1MB左右的包大小，如果你是一個小體積應用，或者是一個幾千萬用戶的主流應用。對包大小敏感的話慎用。

核心代碼目前閉源

對於在我們這樣一個作惡滿天飛的天朝長大的孩子來說，有些孩子對閉源這個事情還是挺在意的。不過官方說將來會開源，我還是傾向於相信 Realm 他們的人品。

CoreData

CoreData 相關資料相對多一些我就簡單說

優點

官方支持 && 親兒子

系統自帶，Apple支持

帶圖形化的Model編輯

對於視覺化動物來說比較友好，也可以清楚的知道自己設計的 Model 之間的關系

強大的關聯關系

以前不覺得，用了 Realm 才發現 CoreData 的關聯關系如此好用，一對多，多對多。想怎麼查詢就怎麼查詢，可以寫出很復雜的查詢邏輯來。

強大的查詢

雖然可能在設置NSFetchRequest的時候感覺很多東西要弄，但是復雜也帶來了強大的功能，NSFetchRequest 可以設置很多，比如限制查詢數量， 限制只返回某些屬性值等等。就不展開說了。

精細化的通知

可以知道具體插入了什麼、更新了什麼、刪除了什麼。這樣在刷UI，比如一個tableview的時候，你就可以控制的很准確。

缺點

入門門檻高

CoreData 是一個博大精深的技術，不要妄想幾天之內可以用的很溜。
CoreData 是一個博大精深的技術，不要妄想幾天之內可以用的很溜。
CoreData 是一個博大精深的技術，不要妄想幾天之內可以用的很溜。

如果沒有足夠的時間和精力去接入 CoreData。 那選型的時候應當慎重考慮。

需要一些工具才感覺好使

不管是老手還是新手，使用一些第三方的封裝庫和工具都會大大的提高使用 CoreData 的幸福指數。

mogenerator 是必須必須要的。

MagicalRecord 無愧 CoreData 第一庫，據小道消息 主要貢獻者 Saul Mora 可能去了微信了。

Context

其實還是 CoreData 門檻高的問題，對我來說。Context之間的關系和線程之間的處理讓我感到很頭痛，特別是 OS X  是一大堆VC鋪到屏幕上，我水平又菜，出的問題很多。

多個持久化文件很麻煩

不是說不可以，但是真的好麻煩。

有個第三方庫有解決CoreData這個問題 CoreStore 但是我用著不是很順手最後棄用.

總結

其實吧用啥持久化都行，具體還是需要看你的需求和方案上來說哪一個方案更加適合。

如果簡單說來，就是 Realm 更加適合一些業務邏輯不怎麼復雜的場景，團隊配置要求不高，有經驗的人稍微看一下午就能上手。

CoreData 更加適合業務邏輯復雜的情況，團隊配置要求比較高，有經驗的老手也需要幾周甚至更長的時間才能科學的使用CoreData。