原文鏈接
http://iiiyu.com/2016/01/19/CoreData-VS-Realm/?utm_source=tuicool&utm_medium=referral
本文具有強(qiáng)烈的個(gè)人感情色彩,如有觀看不適,請盡快關(guān)閉。本文僅作為個(gè)人學(xué)習(xí)記錄使用，也歡迎在許可協(xié)議范圍內(nèi)轉(zhuǎn)載或使用，請尊重版權(quán)并且保留原文鏈接，謝謝您的理解合作。如果您覺得本站對您能有幫助，您可以使用RSS方式訂閱本站，這樣您將能在第一時(shí)間獲取本站信息。
碎碎念
OhMyStar 2 也進(jìn)行了一段時(shí)日，我把持久化的方式從CoreData 換到了 Realm。有些感悟，順手就記錄一下吧。以下評論都是自己很主觀的感受，無實(shí)際測試數(shù)據(jù)支持。
論 iOS 的持久化
iOS 持久化其實(shí)也沒多少選擇， 高端一點(diǎn)CoreData、Realm、FMDB、KV類(LevelDB等)。低端一些直接一個(gè) NSArray 就寫成 Plist 也能持久化下來。
在網(wǎng)絡(luò)環(huán)境越來越快的當(dāng)下和大部分應(yīng)用數(shù)據(jù)都可能是網(wǎng)絡(luò)應(yīng)用，如果業(yè)務(wù)邏輯并不復(fù)雜，其實(shí)極端一點(diǎn)就只用寫到 JSON 轉(zhuǎn) Object 就好了。而且一堆這樣好用的封裝，遠(yuǎn)有Mantle 近有YYModel。
所以需要持久化的時(shí)候，我覺的可以慎重的評估一下需求。想明白了，后面可以節(jié)省很多事情。
本文章主要對比 Realm 和 CoreData，其他的就不涉及了。
Realm
優(yōu)點(diǎn)
入門門檻低
Realm文檔就算一個(gè)字一個(gè)字扣著讀完，一個(gè)下午就足夠了。而且還有中文版本，不要太友好哦，有點(diǎn)不習(xí)慣誒。
文檔覆蓋了80%的使用情況，甚至有些太簡陋的嫌疑。但不管怎么樣，這種入門條件比起 CoreData 寫了三個(gè)月都沒搞清楚 Context 要好的多。
在庫的工具鏈上，安裝一個(gè) Realm Browser 以后就不需要其他輔助了。還是簡單。
幾乎做到了上手即用的程度。五星好評。
PS：我用了一個(gè)通宵把 OhMyStar 2 的持久化從 CoreData 換到了 Realm ，優(yōu)化調(diào)整了大概5天左右達(dá)到勉強(qiáng)可以用的情況 。在這之前并沒有任何 Realm 的經(jīng)驗(yàn)。
據(jù)說性能好一些
Realm官方介紹Fast一段中
Counts
Queries
Inserts
在寫這里的時(shí)候我順手Google了一下 發(fā)現(xiàn)一篇Core Data, FMDB, Realm 性能測試。我就多說幾句
總覺得大家對 CoreData 誤會蠻深，代碼 Fork 看了一下， 總覺得不應(yīng)該這樣寫來比性能的，但是一時(shí)半會也不知道怎么改。我只能說我在優(yōu)化 CoreData 的時(shí)候根據(jù) WWDC 上教的還是提升很高，另外一個(gè)事情是 CoreData 一般都用 Sqlite 做后端。所以如果你的查詢是經(jīng)過優(yōu)化的，確認(rèn)打出來的SQL語句科學(xué)以后，Sqlite(CoreData) 跟 Sqlite(FMDB)我覺得性能就算有差距，這差距沒有能大到選擇方案的決定性因素。如果使用 CoreData 遇到性能瓶頸，你應(yīng)該仔細(xì)的研究 WWDC 和幾篇很好的文章。確保你的 CoreData 使用方式是正確科學(xué)的。
沒有需要架構(gòu)Context那種煩人的東西
應(yīng)該也算Realm簡單的一個(gè)方面，Realm 只要保持自己線程里面，自己的 Realm Store 操作是正確的即可。如果是 CoreData，怎么架構(gòu)一個(gè)科學(xué)的 Context Stack 就足夠讓我頭疼一整，iOS 還好，界面是一個(gè)接著一個(gè)(VC跟VC之間的層級關(guān)系很清晰)。而 OhMyStar 2 這種 OS X 桌面應(yīng)用場景VC之間很復(fù)雜，線程之間Context的關(guān)系讓出現(xiàn)很多問題。
支持 NSPredicate
從 CoreData 轉(zhuǎn)過來并沒有太多的不適應(yīng)
很簡單的使用多個(gè)存儲文件
舉個(gè)例子，多用戶登陸情況下。用戶是單獨(dú)的存儲文件，和全部用戶使用同一個(gè)存儲文件。后者需要每條用戶數(shù)據(jù)都要關(guān)聯(lián)一次當(dāng)前用戶，所有查詢用戶數(shù)據(jù)的時(shí)候，你都必須加上當(dāng)前用戶的查詢項(xiàng)。而使用每個(gè)用戶單獨(dú)一個(gè)數(shù)據(jù)文件的時(shí)候，整個(gè)存儲結(jié)構(gòu)會清爽很多。
技術(shù)支持
至少實(shí)在沒法的時(shí)候還可以去微博上吐槽他們，他們其實(shí)也有極大的熱情來解決你遇到的問題。CoreData 這種遇到問題就只能自己默默的吞下。
細(xì)?；ㄖ?(2016-02-23更新 0.98.x 版本以后可以獲得精細(xì)化通知)
看最新的文檔已經(jīng)更新：
Notifications
看例子還可以進(jìn)行filter。不要太友好哦。。。我很不習(xí)慣的。
有了這個(gè)通知在我思考的程序結(jié)構(gòu)里，寫入數(shù)據(jù)的所有線程都可以在后臺了，而且更新UI的時(shí)候只用在需要的地方監(jiān)聽需要的類。這個(gè)進(jìn)步讓之前的缺點(diǎn)瞬間變成了優(yōu)點(diǎn)，太棒了
缺點(diǎn)
關(guān)聯(lián)關(guān)系弱的一逼
簡單說來就是對象跟對象之間的一對多關(guān)系和多對多關(guān)系。并不能映射，需要在雙方里面都寫上屬性，此外還需要在設(shè)置的時(shí)候兩邊同時(shí)設(shè)置。查詢時(shí)候也是 NSPredicate 也僅僅只支持一些一層的查詢，沒法做出帶SUBQUERY的復(fù)雜查詢出來。
強(qiáng)制內(nèi)省容錯機(jī)制導(dǎo)致存儲文件不斷變大
Realm本身感覺有一個(gè)數(shù)據(jù)容錯機(jī)制。但是這個(gè)機(jī)制在數(shù)據(jù)庫文件有錯誤的情況自己修復(fù)的時(shí)候，會無限增大。具體我這里表現(xiàn)為，打開看只有3000條數(shù)據(jù)，但是文件大小已經(jīng)有3GB。重現(xiàn)Bug也很容易，只要你在寫數(shù)據(jù)庫的時(shí)候,用Realm Browser查看一下，crash之后在打開就很容易出現(xiàn)。
官方文檔里面有說到會造成這種情形的原因，我在盡我所能的避免問題以后。存儲文件還是會有可能不那么夸張的變大一些。但是用Realm Browser查看數(shù)據(jù)是正常的。所以我覺得官方應(yīng)該提供一個(gè)函數(shù)，可以刪除掉那些容易的東西。保持存儲文件的干凈。
2016-02-23更新： 樓下Realm的同學(xué)留言說了其中一種解決方法?？梢允褂肦ealm.writeCopyToPath()
來手動釋放舊版本使用的空間。當(dāng)然這些空間在沒有 Realm 實(shí)例引用的情況下是會被自動重用的。我理解的意思是在開啟或者關(guān)閉App的時(shí)刻，把Realm實(shí)際的數(shù)據(jù)庫寫到tmp里再把當(dāng)前的realm關(guān)閉然后拷貝回來。會變大的原因肯定還是線程的問題。 我的被我寫的有些亂，期望我能把他優(yōu)化好吧。
增加包體積
據(jù)官方說會增加1MB左右的包大小，如果你是一個(gè)小體積應(yīng)用，或者是一個(gè)幾千萬用戶的主流應(yīng)用。對包大小敏感的話慎用。
2016-02-23更新：實(shí)際測試我在Mac上的adhoc包有3MB多。
核心代碼目前閉源
對于在我們這樣一個(gè)作惡滿天飛的天朝長大的孩子來說，有些孩子對閉源這個(gè)事情還是挺在意的。不過官方說將來會開源，我還是傾向于相信 Realm 他們的人品。
CoreData
CoreData 相關(guān)資料相對多一些我就簡單說
優(yōu)點(diǎn)
官方支持 && 親兒子
系統(tǒng)自帶，Apple支持
帶圖形化的Model編輯
對于視覺化動物來說比較友好，也可以清楚的知道自己設(shè)計(jì)的 Model 之間的關(guān)系
強(qiáng)大的關(guān)聯(lián)關(guān)系
以前不覺得，用了 Realm 才發(fā)現(xiàn) CoreData 的關(guān)聯(lián)關(guān)系如此好用，一對多，多對多。想怎么查詢就怎么查詢，可以寫出很復(fù)雜的查詢邏輯來。
強(qiáng)大的查詢
雖然可能在設(shè)置NSFetchRequest的時(shí)候感覺很多東西要弄，但是復(fù)雜也帶來了強(qiáng)大的功能，NSFetchRequest 可以設(shè)置很多，比如限制查詢數(shù)量， 限制只返回某些屬性值等等。就不展開說了。
精細(xì)化的通知
可以知道具體插入了什么、更新了什么、刪除了什么。這樣在刷UI，比如一個(gè)tableview的時(shí)候，你就可以控制的很準(zhǔn)確。
缺點(diǎn)
入門門檻高
CoreData 是一個(gè)博大精深的技術(shù)，不要妄想幾天之內(nèi)可以用的很溜。CoreData 是一個(gè)博大精深的技術(shù)，不要妄想幾天之內(nèi)可以用的很溜。CoreData 是一個(gè)博大精深的技術(shù)，不要妄想幾天之內(nèi)可以用的很溜。
如果沒有足夠的時(shí)間和精力去接入 CoreData。 那選型的時(shí)候應(yīng)當(dāng)慎重考慮。
需要一些工具才感覺好使
不管是老手還是新手，使用一些第三方的封裝庫和工具都會大大的提高使用 CoreData 的幸福指數(shù)。
mogenerator 是必須必須要的。
MagicalRecord 無愧 CoreData 第一庫，據(jù)小道消息 主要貢獻(xiàn)者 Saul Mora 可能去了微信了。
Context
其實(shí)還是 CoreData 門檻高的問題，對我來說。Context之間的關(guān)系和線程之間的處理讓我感到很頭痛，特別是 OS X 是一大堆VC鋪到屏幕上，我水平又菜，出的問題很多。
多個(gè)持久化文件很麻煩
不是說不可以，但是真的好麻煩。
有個(gè)第三方庫有解決CoreData這個(gè)問題 CoreStore 但是我用著不是很順手最后棄用.
總結(jié)
其實(shí)吧用啥持久化都行，具體還是需要看你的需求和方案上來說哪一個(gè)方案更加適合。
如果簡單說來，就是 Realm 更加適合一些業(yè)務(wù)邏輯不怎么復(fù)雜的場景，團(tuán)隊(duì)配置要求不高，有經(jīng)驗(yàn)的人稍微看一下午就能上手。
CoreData 更加適合業(yè)務(wù)邏輯復(fù)雜的情況，團(tuán)隊(duì)配置要求比較高，有經(jīng)驗(yàn)的老手也需要幾周甚至更長的時(shí)間才能科學(xué)的使用CoreData。
