建站
咨詢
售后
建站咨詢
新聞中心
憑良心講，我不能告訴你不去使用Core Data。它不錯，而且也在變好，并且它被很多其他Cocoa開發(fā)者所理解，當有新人加入你的組或者需要別人接手你的項目的時候，這點很重要。
創(chuàng)新互聯(lián)于2013年創(chuàng)立，先為尚志等服務建站，尚志等地企業(yè)，進行企業(yè)商務咨詢服務。為尚志企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務解決您的所有建站問題。
更重要的是，不值得花時間和精力去寫自己的系統(tǒng)去代替它。真的，使用Core Data吧。
為什么我不使用Core Data
Mike Ash寫到：就我自己而言，我不是個狂熱粉絲。我發(fā)現(xiàn)API是笨拙的，并且框架本身對于大量的數(shù)據(jù)是極其緩慢的。
一個實際的例子：10,000條目
想象一個RSS閱讀器，一個用戶可以在一個feed上點擊右鍵，并且選擇標記所有為已讀。
引擎下，有一個帶有read屬性的Article實體。把所有條目標記為已讀，程序需要加載這個feed的所有文章(可能通過一對多的關(guān)系)，然后設置read屬性為YES。
大部分情況下這樣沒關(guān)系。但是設想那個feed里有200個文章，為了避免阻塞主線程，你可能考慮在后臺線程里做這個工作(特別當你的程序是一個iPhone應用)。當你一開始使用Core Data多線程，事情就開始變的不好處理了。
這可能還湊合，至少不值得切換走Core Data。
但是接下來加同步。
我用過兩種不同的獲取已讀文章ID列表的RSS同步接口。其中一個返回近10,000個ID。
你不會打算在主線程中加載10,000個文章，然后設置read為NO。你甚至不想在后臺線程里加載10,000個文章，即使很小心的管理內(nèi)存，這有太多的工作（如果你頻繁的這么做，想一下對電池壽命的影響）。
你真正想要做的是，讓數(shù)據(jù)庫給在ID列表里的每一個文章設置read為YES。
SQLite可以做到這個，只用一次調(diào)用。假設uniqueID上有索引，這會很快。而且你可以在后臺線程執(zhí)行像在主線程執(zhí)行一樣容易。
另一個例子：快速啟動
我想減少我的另一個程序的啟動時間，不只是開始的時間，而是在數(shù)據(jù)顯示之前的所有時間。
那是個類似Twitter的應用(雖然它不是)，它顯示消息的時間軸。顯示時間軸意味著獲取消息，加載相關(guān)用戶。它很快，但是在啟動的時候，會填充UI，然后填充數(shù)據(jù)。
關(guān)于iPhone的應用（或者所有應用）我的理論是，啟動時間很重要，比其他大部分開發(fā)者想的都要重要。應用的啟動很慢看起來不像是要啟動一樣，因 為人們潛意識里記得，并且會產(chǎn)生阻止啟動應用的想法。減少啟動時間就減少了摩擦，讓用戶更有可能繼續(xù)使用你的應用，并且推薦給其他人。這是你讓你的應用成 功的一部分。
因為我不使用Core Data，我手邊有一個簡單的，保守的解決方案。我把timeline（消息和人物對象）通過NSCoding保存到一個plist文件中。啟動的時候它讀這個文件，創(chuàng)建消息和人物對象，UI一出現(xiàn)就顯示時間軸。
這明顯的減少了延遲。
把消息和人物對象作為NSManagedObject的實例對象，這是不可能的。（假設我有編碼的并且存儲的IDs對象，但是那意味著讀plist然后觸及數(shù)據(jù)庫。這種方式我完全避免了數(shù)據(jù)庫）。
在更新更快的機器出來后, 我去掉了那些代碼?；仡欉^去，我希望我可以把它留下來。
我怎么考慮這個問題
當考慮是否使用Core Data時，我考慮下面這些事情：
會有難以置信數(shù)量的數(shù)據(jù)嗎？
對于一個RSS閱讀器或者Twitter應用，答案顯而易見：是的。有些人關(guān)注上百個人。一個人可能訂閱了上千個feeds。
即使你的應用不從網(wǎng)絡獲取數(shù)據(jù)，仍然有可能讓用戶自動添加數(shù)據(jù)。如果你用一個支持AppleScript的Mac，有些人會寫腳本去加載非常多的數(shù)據(jù)。如果通過web API去加數(shù)據(jù)也是一樣的。
會有一個Web API包含類似于數(shù)據(jù)庫的終端嗎（對比類對象終端）？
一個RSS同步API能夠返回一個已讀文章的uniquelIDs列表。一個記筆記的應用的一個同步API可能返回已存檔的和已刪除的筆記的uniquelIDs。
用戶可能通過操作處理大量對象嗎？
在底層，需要考慮和之前一樣的問題。當有人刪除所有下載的5，000個面食食譜，你的食譜應用可以多好的完成這個功能（在iPhone上？）？
當我決定使用Core Data（我已經(jīng)發(fā)布過使用Core Data的應用），我會小心留意我怎么使用它。為了得到好的性能，我發(fā)現(xiàn)我把它當做一個SQL數(shù)據(jù)庫的一個奇怪接口來使用，然后我知道我應該舍棄Core Data，直接使用SQLite。
我怎么使用SQLite
我通過FMDB Wrapper來使用SQLite，F(xiàn)MDB來自Flying Meat Software，由Gus Mueller提供。
基本操作
我在iPhone以前，Core Data以前就使用過SQLite。這是它怎么工作的的要點：
- 所有數(shù)據(jù)庫訪問-讀和寫-發(fā)生在連續(xù)的隊列里，在一個后臺線程。在主線程中觸及數(shù)據(jù)庫是從來不被允許的。使用一個連續(xù)隊列來保證每一件事是按順序發(fā)生的。
- 我大量使用blocks來讓異步程序容易點。
- 模型對象只存在在主線程（但有兩個重要的例外），改變會觸發(fā)一個后臺保存。
- 模型對象列出來他們在數(shù)據(jù)庫中存儲的屬性。可能在代碼里或者在plist文件里。
- 一些模型對象是唯一的，一些不是。取決于應用的需要（大部分情況是唯一的）。
- 對關(guān)系型數(shù)據(jù)，我盡可能避免連表查詢。
- 一些對象類型在啟動的時候就完全讀入內(nèi)存，另一些對象類型可能只需要創(chuàng)建并維護一個他們的uniqueIDs的。NSMutableSet，所以不需要去觸及數(shù)據(jù)庫，我就知道已經(jīng)有什么。
- Web API的調(diào)用發(fā)生在后臺線程，他們使用分開的模型對象。
我會通過我現(xiàn)在的應用的代碼來詳細描述。
數(shù)據(jù)庫更新
在我最近的應用中，有一個單一的數(shù)據(jù)庫控制器-VSDatabaseController，它通過FMDB來與SQLite對話。
FMDB區(qū)分更新和查詢。更新數(shù)據(jù)庫，app調(diào)用：
- -[VSDatabaseController runDatabaseBlockInTransaction:(VSDatabaseUpdateBlock)databaseBlock]
#p#
VSDatabaseUpdateBlock很簡單：
- typedef void (^VSDatabaseUpdateBlock)(FMDatabase *database);
runDatabaseBlockInTransaction也很簡單：
- - (void)runDatabaseBlockInTransaction:(VSDatabaseUpdateBlock)databaseBlock {
- dispatch_async(self.serialDispatchQueue, ^{
- @autoreleasepool {
- [self beginTransaction];
- databaseBlock(self.database);
- [self endTransaction];
- }
- });
- }
（注意我用自己的連續(xù)調(diào)度隊列。Gus建議看一下FMDatabaseQueue，也是一個連續(xù)調(diào)度隊列。我還沒能去看一下，因為它比FMDB的其他東西都要新。）
beginTransaction和endTransaction的調(diào)用是可嵌套的（在我的數(shù)據(jù)庫控制器里）。在合適的時候他們會調(diào)用-[FMDatabase beginTransaction] 和 -[FMDatabase commit]。（使用事務是讓SQLite變快的關(guān)鍵。）提示：我把當前事務存儲在-[NSThread threadDictionary]。它很好獲取每一個線程的數(shù)據(jù)，我?guī)缀鯊牟挥闷渌摹?/p>
這兒有個調(diào)用更新數(shù)據(jù)庫的簡單例子：
- - (void)emptyTagsLookupTableForNote:(VSNote *)note {
- NSString *uniqueID = note.uniqueID;
- [self runDatabaseBlockInTransaction:^(FMDatabase *database) {
- [database executeUpdate:
- @"delete from tagsNotesLookup where noteUniqueID = ?;", uniqueID];
- }];
- }
這說明一些事情。首先SQL不可怕。即使你從沒見過它，你也知道這行代碼做了什么。
像VSDatabaseController的所有其他公共接口，emptyTagsLookupTableForNote應該在主線程中被調(diào)用。模型對象只能在主線程中被引用，所以在block中用uniqueID，而不是VSNote對象。
注意在這種情況下，我更新了一個查找表。Notes和tags是多對多關(guān)系，一種表現(xiàn)方式是用一個數(shù)據(jù)庫表映射note uniqueIDs和tag uniqueIDs。這些表不會很難維護，但是如果可能，我確實嘗試避免他們的使用。
注意在更新字符串中的?。-[FMDatabase executeUpdate:] 是一個可變參數(shù)函數(shù)。SQLite支持使用占位符?，所以你不需要把正真的值放入字符串。這兒有一個安全問題：它幫助守護程序反對SQL插入。如果你需要避開某些值，它也為你省了麻煩。
***，在tagsNotesLookup表中，有一個noteUniquelID的索引（索引是SQLite性能的又一個關(guān)鍵）。這行代碼在每次啟動時都調(diào)用：
- [self.database executeUpdate:
- @"CREATE INDEX if not exists noteUniqueIDIndex on tagsNotesLookup (noteUniqueID);"];
數(shù)據(jù)庫獲取
要獲取對象，app調(diào)用：
- -[VSDatabaseController runFetchForClass:(Class)databaseObjectClass
- fetchBlock:(VSDatabaseFetchBlock)fetchBlock
- fetchResultsBlock:(VSDatabaseFetchResultsBlock)fetchResultsBlock];
這兩行代碼做了大部分工作：
- FMResultSet *resultSet = fetchBlock(self.database);
- NSArray *fetchedObjects = [self databaseObjectsWithResultSet:resultSet
- class:databaseObjectClass];
用FMDB查找數(shù)據(jù)庫返回一個FMResultSet. 通過resultSet你可以逐句循環(huán)，創(chuàng)建模型對象。
我建議寫通用的代碼去轉(zhuǎn)換數(shù)據(jù)庫行到對象。一種我使用的方法是用一個plist，映射column名字到對象屬性。它也包含類型，所以你知道是否需要調(diào)用 -[FMResultSet dateForColumn:]， -[FMResultSet stringForColumn:]或其他。
在我的***應用里我做了些簡單的事情。數(shù)據(jù)庫行剛好對應模型對象屬性的名字。所有屬性都是strings，除了那些名字以“Date”結(jié)尾的屬性。很簡單，但是你可以看到需要一個清晰的對應關(guān)系。
唯一對象
創(chuàng)建模型對象和從數(shù)據(jù)庫獲取數(shù)據(jù)在同一個后臺線程。一獲取到，程序會把他們轉(zhuǎn)到主線程。
通常我有uniqued對象。同一個數(shù)據(jù)庫行結(jié)果始終對應同一個對象。
為了做到唯一，我創(chuàng)建了一個對象緩存，一個NSMapTable，在init函數(shù)里：_objectCache = [NSMapTable weakToWeakObjectsMapTable]。我來解釋一下：
例如，當你做一個數(shù)據(jù)庫獲取并且把對象轉(zhuǎn)交給一個視圖控制器，你希望在視圖控制器使用完這些對象后，或者一個不一樣的視圖控制器顯示了，這些對象可以消失。
如果你的對象緩存是一個NSMutableDictionary，你將需要做一些額外的工作來清空緩存中的對象。確定它對應的對象在別的地方是否有引用就變的很痛苦。NSMapTable是弱引用，就會自動處理這個問題。
所以：我們在主線程中讓對象唯一。如果一個對象已經(jīng)在對象緩存中存在，我們就用那個存在的對象。（主線程勝出，因為它可能有新的改變。）如果對象緩存中沒有，它會被加上。
保持對象在內(nèi)存中
有很多次，把整個對象類型保留在內(nèi)存中是有道理的。我***的app有一個VSTag對象。雖然可能有成百上千個筆記，但tags的數(shù)量很小，基本少于10。一個tag只有6個屬性：3個BOOL，兩個很小的NSstring，還有一個NSDate。
啟動的時候，app獲取所有tags并且把他們保存在兩個字典里，一個主鍵是tag的uniqueID，另一個主鍵是tag名字的小寫。
這簡化了很多事，不只是tag自動補全系統(tǒng)，這個可以完全在內(nèi)存中操作，不需要數(shù)據(jù)庫獲取。
但是很多次，把所有數(shù)據(jù)保留在內(nèi)存中是不實際的。比如我們不會在內(nèi)存中保留所有筆記。
但是也有很多次，當不能在內(nèi)存中保留對象時，你希望在內(nèi)存中保留所有uniqueIDs。你會像這樣做一個獲?。?/p>
- FMResultSet *resultSet = [self.database executeQuery:@"select uniqueID from some_table"];
resultSet只包含了uniqueIDs， 你可以存儲到一個NSMutableSet里。
我發(fā)現(xiàn)有時這個對web APIs很有用。想象一個API調(diào)用返回從某個確定的時間以后的，已創(chuàng)建筆記的uniqueIDs列表。如果我本地已經(jīng)有了一個包含所有筆記uniqueIDs的NSMutableSet，我可以快速檢查(通過 -[NSMutableSet minusSet])是否有漏掉的筆記，然后去調(diào)用另一個API下載那些漏掉的筆記。這些完全不需要觸及數(shù)據(jù)庫。
但是，像這樣的事情應該小心處理。app可以提供足夠的內(nèi)存嗎？它真的簡化編程并且提高性能了嗎？
用SQLite和FMDB而不是Core Data，給你帶來大量的靈活性和聰明解決辦法的空間。記住有的時候聰明是好的，也有的時候聰明是一個大錯誤。
#p#
Web APIs
我的API調(diào)用在后臺進程（經(jīng)常用一個NSOperationQueue，所以我可以取消操作）。模型對象只在主線程，但是我還傳遞模型對象給我的API調(diào)用。
是這樣的：一個數(shù)據(jù)庫對象有一個detachedCopy方法，可以復制數(shù)據(jù)庫對象。這個復制對象不是引用自我用來唯一化的對象緩存。唯一引用那個對象的地方是API調(diào)用，當API調(diào)用結(jié)束，那個復制的對象就消失了。
這是一個好的系統(tǒng)，因為它意味著我可以在API調(diào)用里使用模型對象。方法看起來像這樣：
- - (void)uploadNote:(VSNote *)note {
- VSNoteAPICall *apiCall =[[VSNoteAPICall alloc] initWithNote:[note detachedCopy]];
- [self enqueueAPICall:apiCall];
- }
VSNoteAPICall從復制的VSNote獲取值，并且創(chuàng)建HTTP請求，而不是一個字典或其他筆記的表現(xiàn)形式。
處理Web API返回值
我對web返回值做了一些類似的事情。我會對返回的JSON或者XML創(chuàng)建一個模型對象，這個模型對象也是分離的。它不是存儲在為了唯一性的模型緩存里。
這兒有些事情是不確定的。有時有必要用那個模型對象在兩個地方做本地修改：在內(nèi)存緩存和數(shù)據(jù)庫。
數(shù)據(jù)庫通常是容易的部分。比如：我的應用已經(jīng)有一個方法來保存筆記對象。它用一個SQL insert或者replace字符串。我只需調(diào)用那個從web API返回值生成的筆記對象，數(shù)據(jù)庫就會更新。
但是可能那個對象有一個在內(nèi)存中的版本，幸運的是我們很容易找到：
- VSNote *cachedNote = [self.mapTable objectForKey:downloadedNote.uniqueID];
如果cachedNote存在，我會讓它從downloadedNote中獲取值，而不是替換它（這樣可能違反唯一性）。這可以共享detachedCopy方法的代碼。
一旦cachedNote更新了，觀察者會通過KVO通知筆記，或者我會發(fā)送一個NSNotification，或者兩者都做。
Web API調(diào)用也會返回一些其他值。我提到過RSS閱讀器可能獲得一個已讀條目的大列表。這種情況下，我用那個列表創(chuàng)建了一個NSSet，在內(nèi)存中更新每一個緩存文章的read屬性，然后調(diào)用-[FMDatabase executeUpdate:]。
讓它工作快速的關(guān)鍵是NSMapTable的查找是快速的。如果你找的對象在一個NSArray里，我們該重新考慮。
數(shù)據(jù)庫遷移
Core Data的數(shù)據(jù)庫遷移很酷，當它可行的時候。
但是不可避免的，它是代碼和數(shù)據(jù)庫中的一層。如果你越直接使用SQLite，你更新數(shù)據(jù)庫越直接。
你可以安全容易的做到這點。
比如加一個表：
- [self.database executeUpdate:@"CREATE TABLE if not exists tags "
- "(uniqueID TEXT UNIQUE, name TEXT, deleted INTEGER, deletedModificationDate DATE);"];
或者加一個索引：
- [self.database executeUpdate:@"CREATE INDEX if not exists "
- "archivedSortDateIndex on notes (archived, sortDate);"];
或者加一列：
- [self.database executeUpdate:@"ALTER TABLE tags ADD deletedDate DATE"];
應用應該在代碼的***個地方用上面這些代碼設置數(shù)據(jù)庫。以后的改變只需加executeUpdate的調(diào)用 — 我讓他們按順序執(zhí)行。因為我的數(shù)據(jù)庫是我設計的，不會有什么問題（我從沒碰到性能問題，它很快）。
當然大的改變需要更多代碼。如果你的數(shù)據(jù)通過web獲取，有時你可以從一個新數(shù)據(jù)庫模型開始，重新下載你需要的數(shù)據(jù)。
性能技巧
SQLite可以非常非?？欤部梢苑浅Ｂ?。完全取決于你怎么使用它。
事務
把更新包裝在事務里。在更新前調(diào)用 -[FMDatabase beginTransaction] ，更新后調(diào)用-[FMDatabase commit]。
如果你不得不反規(guī)范化（ Denormalize）
反規(guī)范化讓人很不爽。這個方法是，為了加速檢索而添加冗余數(shù)據(jù)，但是它意味著你需要維護冗余數(shù)據(jù)。
我總是瘋狂避免它，直到這樣能有嚴重的性能區(qū)別。然后我會盡可能少得這么做。
使用索引
我的應用中tags表的創(chuàng)建語句像這樣：
- CREATE TABLE if not exists tags
- (uniqueID TEXT UNIQUE, name TEXT, deleted INTEGER, deletedModificationDate DATE);
uniqueID列是自動索引的，因為它定義為unique。但是如果我想用name來查詢表，我可能會在name上創(chuàng)建一個索引，像這樣：
- CREATE INDEX if not exists tagNameIndex on tags (name);
你可以一次性在多列上創(chuàng)建索引，像這樣：
- CREATE INDEX if not exists archivedSortDateIndex on notes (archived, sortDate);
但是注意太多索引會降低你的插入速度。你只需要足夠數(shù)量并且是對的那些。
#p#
使用命令行應用
當我的app在模擬器里運行時，我會打印數(shù)據(jù)庫的路徑。我可以通過sqlite3的命令行來打開數(shù)據(jù)庫。（通過man sqlite3命令來了解這個應用的更多信息）。
打開數(shù)據(jù)庫的命令：sqlite3 “數(shù)據(jù)庫的路徑”。
打開以后，你可以看schema: type .schema。
你可以更新和查詢，這是在使用你的app之前檢查SQL是否正確的很好的方式。
這里面最酷的一部分是，SQLite Explain Query Plan命令，你會希望確保你的語句執(zhí)行的盡可能快。
真實的例子
我的應用顯示所有沒有歸檔筆記的標簽列表。每當筆記或者標簽有變化，這個查詢就會重新執(zhí)行一次，所以它需要很快。
我可以用SQL join來查詢，但是很慢（joins都很慢）。
所以我放棄sqlite3并開始嘗試別的方法。我又看了一次我的schema，意識到我可以反規(guī)范化。一個筆記的歸檔狀態(tài)可以存儲在notes表里，它也可以存儲在tagsNotesLookup表。
然后我可以執(zhí)行一個查詢：
- select distinct tagUniqueID from tagsNotesLookup where archived=0;
我已經(jīng)有了一個在tagUniqueID上的索引。所以我用explain query plan來告訴我當我執(zhí)行這個查詢的時候會發(fā)生什么。
- sqlite> explain query plan select distinct tagUniqueID from tagsNotesLookup where archived=0;
- 0|0|0|SCAN TABLE tagsNotesLookup USING INDEX tagUniqueIDIndex (~100000 rows)
它用了一個索引，但是SCAN TABLE聽起來不太好，***是一個SEARCH TABLE并且覆蓋一個索引。
我在tagUniqueID和archive上建了索引：
- CREATE INDEX archivedTagUniqueID on tagsNotesLookup(archived, tagUniqueID);
再次執(zhí)行explain query plan：
- sqlite> explain query plan select distinct tagUniqueID from tagsNotesLookup where archived=0;
- 0|0|0|SEARCH TABLE tagsNotesLookup USING COVERING INDEX archivedTagUniqueID (archived=?) (~10 rows)
好多了。
更多性能提示
FMDB的某處加了緩存statements的能力，所以當創(chuàng)建或打開一個數(shù)據(jù)庫的時候，我總是調(diào)用[self.database setShouldCacheStatements:YES] 。這意味著對每個調(diào)用你不需要再次編譯每個statement。
我從來沒有找到使用vacuum的好的指引，如果數(shù)據(jù)庫沒有定期壓縮，它會越來越慢。我的應用會跑一個vacuum，但只是每周一次（它在NSUserDefaults里存儲上次vacuum的時間，然后在開始的時候檢查是否過了一周）。
如果能auto_vacuum那更好，看pragma statements supported by SQLite列表。
其他酷的東西
Gus Mueller讓我涉及自定義SQLite方法的內(nèi)容。我并沒有真的使用這些東西，既然他指出了，我可以放心的說我能找到它的用處。因為它很酷。
在Gus的帖子里，有一個查詢是這樣的：
- select displayName, key from items where UTTypeConformsTo(uti, ?) order by 2;
SQLite完全不知道UITypes。但是你可以加核心方法，查看-[FMDatabase makeFunctionNamed:maximumArguments:withBlock:]。
你可以執(zhí)行一個大的查詢來替代，然后評估每個對象。但是那需要更多工作。***在SQL級就過濾，而不是在將表格行轉(zhuǎn)為對象以后。
***
你真的應該使用Core Data，我不是在開玩笑。
我用SQLite和FMDB一段時間了，我對多得的好處感到很興奮，也得到非同一般的性能。
但是記住機器在變快，其他看你代碼的人期望看到他已經(jīng)知道的Core Data, 另一些不打算看你的數(shù)據(jù)庫代碼。
所以請把這整篇文章看做一個瘋子的叫喊，關(guān)于他為自己建立的細節(jié)的瘋狂的世界，并把自己鎖在里面。
請享受了不起的Core Data的文章（有點難過的搖頭）。
接下來，在查完Gus指出的自定義SQLite方法特性后，我會研究SQLite的full-text search extension. 總有更多的內(nèi)容需要去學習。
原文鏈接：http://www.objc.io/issue-4/SQLite-instead-of-core-data.html
譯文鏈接：http://blog.jobbole.com/52880/
新聞名稱：談談用SQLite和FMDB而不用CoreData
標題URL：http://www.5511xx.com/article/dpopjpe.html
