大家都知道CoreData是ios數(shù)據(jù)儲(chǔ)存的一種方法，關(guān)于CoreData的持久化到底怎么樣，這里有一點(diǎn)我自己的見(jiàn)解。

 

碎碎念

OhMyStar 2 也進(jìn)行了一段時(shí)日，我把持久化的方式從CoreData 換到了 Realm。有些感悟，順手就記錄一下吧。以下評(píng)論都是自己很主觀的感受，無(wú)實(shí)際測(cè)試數(shù)據(jù)支持。

 

論 iOS 的持久化

iOS 持久化其實(shí)也沒(méi)多少選擇， 高端一點(diǎn)CoreData、Realm、FMDB、KV類(LevelDB等)。低端一些直接一個(gè) NSArray 就寫成 Plist也能持久化下來(lái)。

在網(wǎng)絡(luò)環(huán)境越來(lái)越快的當(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í)候，我覺(jué)的可以慎重的評(píng)估一下需求。想明白了，后面可以節(jié)省很多事情。

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

 

Realm

優(yōu)點(diǎn)

入門門檻低

Realm文檔就算一個(gè)字一個(gè)字扣著讀完，一個(gè)下午就足夠了。而且還有中文版本，不要太友好哦，有點(diǎn)不習(xí)慣誒。

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

在庫(kù)的工具鏈上，安裝一個(gè) Realm Browser 以后就不需要其他輔助了。還是簡(jiǎn)單。

幾乎做到了上手即用的程度。五星好評(píng)。

PS：我用了一個(gè)通宵把 OhMyStar 2 的持久化從 CoreData 換到了 Realm ，優(yōu)化調(diào)整了大概5天左右達(dá)到勉強(qiáng)可以用的情況 。在這之前并沒(méi)有任何 Realm 的經(jīng)驗(yàn)。

據(jù)說(shuō)性能好一些

Realm官方介紹Fast一段中

Counts

 

在寫這里的時(shí)候我順手Google了一下 發(fā)現(xiàn)一篇Core Data, FMDB, Realm 性能測(cè)試。我就多說(shuō)幾句

總覺(jué)得大家對(duì) CoreData 誤會(huì)蠻深，代碼 Fork 看了一下， 總覺(jué)得不應(yīng)該這樣寫來(lái)比性能的，但是一時(shí)半會(huì)也不知道怎么改。我只能說(shuō)我在優(yōu)化 CoreData 的時(shí)候根據(jù) WWDC 上教的還是提升很高，另外一個(gè)事情是 CoreData 一般都用 Sqlite 做后端。所以如果你的查詢是經(jīng)過(guò)優(yōu)化的，確認(rèn)打出來(lái)的SQL語(yǔ)句科學(xué)以后，Sqlite(CoreData) 跟 Sqlite(FMDB)我覺(jué)得性能就算有差距，這差距沒(méi)有能大到選擇方案的決定性因素。如果使用 CoreData 遇到性能瓶頸，你應(yīng)該仔細(xì)的研究 WWDC 和幾篇很好的文章。確保你的CoreData 使用方式是正確科學(xué)的。

沒(méi)有需要架構(gòu)Context那種煩人的東西

應(yīng)該也算Realm簡(jiǎn)單的一個(gè)方面，Realm 只要保持自己線程里面，自己的 Realm Store 操作是正確的即可。如果是 CoreData，怎么架構(gòu)一個(gè)科學(xué)的 Context Stack 就足夠讓我頭疼一整，iOS 還好，界面是一個(gè)接著一個(gè)(VC跟VC之間的層級(jí)關(guān)系很清晰)。而OhMyStar 2 這種 OS X 桌面應(yīng)用場(chǎng)景VC之間很復(fù)雜，線程之間Context的關(guān)系讓出現(xiàn)很多問(wèn)題。

支持 NSPredicate

從 CoreData 轉(zhuǎn)過(guò)來(lái)并沒(méi)有太多的不適應(yīng)

很簡(jiǎn)單的使用多個(gè)存儲(chǔ)文件

舉個(gè)例子，多用戶登陸情況下。用戶是單獨(dú)的存儲(chǔ)文件，和全部用戶使用同一個(gè)存儲(chǔ)文件。后者需要每條用戶數(shù)據(jù)都要關(guān)聯(lián)一次當(dāng)前用戶，所有查詢用戶數(shù)據(jù)的時(shí)候，你都必須加上當(dāng)前用戶的查詢項(xiàng)。而使用每個(gè)用戶單獨(dú)一個(gè)數(shù)據(jù)文件的時(shí)候，整個(gè)存儲(chǔ)結(jié)構(gòu)會(huì)清爽很多。

技術(shù)支持

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

缺點(diǎn)

關(guān)聯(lián)關(guān)系弱的一逼

簡(jiǎn)單說(shuō)來(lái)就是對(duì)象跟對(duì)象之間的一對(duì)多關(guān)系和多對(duì)多關(guān)系。并不能映射，需要在雙方里面都寫上屬性，此外還需要在設(shè)置的時(shí)候兩邊同時(shí)設(shè)置。查詢時(shí)候也是 NSPredicate 也僅僅只支持一些一層的查詢，沒(méi)法做出帶SUBQUERY的復(fù)雜查詢出來(lái)。

強(qiáng)制內(nèi)省容錯(cuò)機(jī)制導(dǎo)致存儲(chǔ)文件不斷變大

Realm本身感覺(jué)有一個(gè)數(shù)據(jù)容錯(cuò)機(jī)制。但是這個(gè)機(jī)制在數(shù)據(jù)庫(kù)文件有錯(cuò)誤的情況自己修復(fù)的時(shí)候，會(huì)無(wú)限增大。具體我這里表現(xiàn)為，打開(kāi)看只有3000條數(shù)據(jù)，但是文件大小已經(jīng)有3GB。重現(xiàn)Bug也很容易，只要你在寫數(shù)據(jù)庫(kù)的時(shí)候,用Realm Browser查看一下，crash之后在打開(kāi)就很容易出現(xiàn)。

官方文檔里面有說(shuō)到會(huì)造成這種情形的原因，我在盡我所能的避免問(wèn)題以后。存儲(chǔ)文件還是會(huì)有可能不那么夸張的變大一些。但是用Realm Browser查看數(shù)據(jù)是正常的。所以我覺(jué)得官方應(yīng)該提供一個(gè)函數(shù)，可以刪除掉那些容易的東西。保持存儲(chǔ)文件的干凈。

沒(méi)有細(xì)?；ㄖ?

也就是說(shuō)，當(dāng)我在某個(gè)地方做出修改。 我其他地方只知道Realm有修改，但是沒(méi)法知道我是增加、修改還是刪除了數(shù)據(jù)。不知道我更新的是那一條數(shù)據(jù)。據(jù)文檔說(shuō)，將來(lái)會(huì)解決這個(gè)問(wèn)題，就只有拭目以待。

增加包體積

據(jù)官方說(shuō)會(huì)增加1MB左右的包大小，如果你是一個(gè)小體積應(yīng)用，或者是一個(gè)幾千萬(wàn)用戶的主流應(yīng)用。對(duì)包大小敏感的話慎用。

核心代碼目前閉源

對(duì)于在我們這樣一個(gè)作惡滿天飛的天朝長(zhǎng)大的孩子來(lái)說(shuō)，有些孩子對(duì)閉源這個(gè)事情還是挺在意的。不過(guò)官方說(shuō)將來(lái)會(huì)開(kāi)源，我還是傾向于相信 Realm 他們的人品。

 

CoreData

CoreData 相關(guān)資料相對(duì)多一些我就簡(jiǎn)單說(shuō)

優(yōu)點(diǎn)

官方支持 && 親兒子

系統(tǒng)自帶，Apple支持

帶圖形化的Model編輯

對(duì)于視覺(jué)化動(dòng)物來(lái)說(shuō)比較友好，也可以清楚的知道自己設(shè)計(jì)的 Model 之間的關(guān)系

強(qiáng)大的關(guān)聯(lián)關(guān)系

以前不覺(jué)得，用了 Realm 才發(fā)現(xiàn) CoreData 的關(guān)聯(lián)關(guān)系如此好用，一對(duì)多，多對(duì)多。想怎么查詢就怎么查詢，可以寫出很復(fù)雜的查詢邏輯來(lái)。

強(qiáng)大的查詢

雖然可能在設(shè)置NSFetchRequest的時(shí)候感覺(jué)很多東西要弄，但是復(fù)雜也帶來(lái)了強(qiáng)大的功能，NSFetchRequest 可以設(shè)置很多，比如限制查詢數(shù)量， 限制只返回某些屬性值等等。就不展開(kāi)說(shuō)了。

精細(xì)化的通知

可以知道具體插入了什么、更新了什么、刪除了什么。這樣在刷UI，比如一個(gè)tableview的時(shí)候，你就可以控制的很準(zhǔn)確。

缺點(diǎn)

入門門檻高

CoreData 是一個(gè)博大精深的技術(shù)，不要妄想幾天之內(nèi)可以用的很溜。
CoreData 是一個(gè)博大精深的技術(shù)，不要妄想幾天之內(nèi)可以用的很溜。
CoreData 是一個(gè)博大精深的技術(shù)，不要妄想幾天之內(nèi)可以用的很溜。

如果沒(méi)有足夠的時(shí)間和精力去接入 CoreData。 那選型的時(shí)候應(yīng)當(dāng)慎重考慮。

需要一些工具才感覺(jué)好使

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

mogenerator 是必須必須要的。

MagicalRecord 無(wú)愧 CoreData 第一庫(kù)，據(jù)小道消息 主要貢獻(xiàn)者 Saul Mora 可能去了微信了。

Context

其實(shí)還是 CoreData 門檻高的問(wèn)題，對(duì)我來(lái)說(shuō)。Context之間的關(guān)系和線程之間的處理讓我感到很頭痛，特別是 OS X  是一大堆VC鋪到屏幕上，我水平又菜，出的問(wèn)題很多。

多個(gè)持久化文件很麻煩

不是說(shuō)不可以，但是真的好麻煩。

有個(gè)第三方庫(kù)有解決CoreData這個(gè)問(wèn)題 CoreStore 但是我用著不是很順手最后棄用.

總結(jié)

其實(shí)吧用啥持久化都行，具體還是需要看你的需求和方案上來(lái)說(shuō)哪一個(gè)方案更加適合。

如果簡(jiǎn)單說(shuō)來(lái)，就是 Realm 更加適合一些業(yè)務(wù)邏輯不怎么復(fù)雜的場(chǎng)景，團(tuán)隊(duì)配置要求不高，有經(jīng)驗(yàn)的人稍微看一下午就能上手。

CoreData 更加適合業(yè)務(wù)邏輯復(fù)雜的情況，團(tuán)隊(duì)配置要求比較高，有經(jīng)驗(yàn)的老手也需要幾周甚至更長(zhǎng)的時(shí)間才能科學(xué)的使用CoreData。

 

 

原文來(lái)自：蕭宸宇的博客