iOS應用架構談 本地持久化方案及動態部署

轉載: iOS應用架構談 本地持久化方案及動態部署

前言

嗯，大家要的大招。跟着這篇文章一塊兒也發佈了CTPersistance和CTJSBridge這兩個庫，但願你們在實際使用的時候若是遇到問題，就給我提issue或者PR或者評論區。每個issue和PR以及評論我都會回覆的。

持久化方案無論是服務端仍是客戶端，都是一個很是值得討論的話題。尤爲是在服務端，持久化方案的優劣每每都會在必定程度上影響到產品的性能。然而在客戶端，只有爲數很少的業務需求會涉及持久化方案，並且在大多數狀況下，持久化方案對性能的要求並非特別苛刻。因此我在移動端這邊作持久化方案設計的時候，考慮更多的是方案的可維護和可拓展，而後在此基礎上纔是性能調優。這篇文章中，性能調優不會單獨開一節來說，而會穿插在各個小節中，你們有心的話能夠重點看一下。

持久化方案對整個App架構的影響和網絡層方案對整個架構的影響相似，通常都是致使整個項目耦合度高的罪魁禍首。而我也是一如既往的去Model化的實踐者，在持久層去Model化的過程當中，我引入了Virtual Record的設計，這個在文中也會詳細描述。

這篇文章主要講如下幾點：

1. 根據需求決定持久化方案

2. 持久層與業務層之間的隔離

3. 持久層與業務層的交互方式

4. 數據遷移方案

5. 數據同步方案

另外，針對數據庫存儲這一塊，我寫了一個CTPersistance，這個庫目前可以完成大部分的持久層需求，同時也是個人Virtual Record這種設計思路的一個樣例。這個庫能夠直接被cocoapods引入，但願你們使用的時候，可以多給我提issue。這裏是CTPersistance Class Reference。

---

根據需求決定持久化方案

在有須要持久化需求的時候，咱們有很是多的方案可供選擇：NSUserDefault、KeyChain、File，以及基於數據庫的無數子方案。所以，當有須要持久化的需求的時候，咱們首先考慮的是應該採用什麼手段去進行持久化。

NSUserDefault

通常來講，小規模數據，弱業務相關數據，均可以放到NSUserDefault裏面，內容比較多的數據，強業務相關的數據就不太適合NSUserDefault了。另外我想吐槽的是，天貓這個App實際上是沒有一個通過設計的數據持久層的。而後天貓裏面的持久化方案就很混亂，我就見到過有些業務線會把大部分業務數據都塞到NSUserDefault裏面去，當時看代碼的時候我特麼就直接跪了。。。問起來爲何這麼作？結果說由於寫起來方便～你妹。。。

keychain

Keychain是蘋果提供的帶有可逆加密的存儲機制，廣泛用在各類存密碼的需求上。另外，因爲App卸載只要系統不重裝，Keychain中的數據依舊可以獲得保留，以及可被iCloud同步的特性，你們都會在這裏存儲用戶惟一標識串。因此有須要加密、須要存iCloud的敏感小數據，通常都會放在Keychain。

文件存儲

文件存儲包括了Plist、archive、Stream等方式，通常結構化的數據或者須要方便查詢的數據，都會以Plist的方式去持久化。Archive方式適合存儲平時不太常用但很大量的數據，或者讀取以後但願直接對象化的數據，由於Archive會將對象及其對象關係序列化，以致於讀取數據的時候須要Decode很花時間，Decode的過程能夠是解壓，也能夠是對象化，這個能夠根據具體 中的實現來決定。Stream就是通常的文件存儲了，通常用來存存圖片啊啥的，適用於比較常用，然而數據量又不算很是大的那種。

數據庫存儲

數據庫存儲的話，花樣就比較多了。蘋果自帶了一個Core Data，固然業界也有無數替代方案可選，不過真正用在iOS領域的除了Core Data外，就是FMDB比較多了。數據庫方案主要是爲了便於增刪改查，當數據有狀態和類別的時候最好仍是採用數據庫方案比較好，並且尤爲是當這些狀態和類別都是強業務相關的時候，就更加要採用數據庫方案了。由於你不可能經過文件系統遍歷文件去甄別你須要獲取的屬於某個狀態或類別的數據，這麼作成本就太大了。固然，特別大量的數據也不適合直接存儲數據庫，好比圖片或者文章這樣的數據，通常來講，都是數據庫存一個文件名，而後這個文件名指向的是某個圖片或者文章的文件。若是真的要作全文索引這種需求，建議最好仍是掛個API丟到服務端去作。

總的說一下

NSUserDefault、Keychain、File這些持久化方案都很是簡單基礎，分清楚何時用什麼就能夠了，不要像天貓那樣亂寫就好。並且在這之上並不會有更復雜的衍生需求，若是真的要針對它們寫文章，無非就是寫怎麼儲存怎麼讀取，這個你們隨便Google一下就有了，我就不浪費筆墨了。因爲大多數衍生複雜需求都是經過採用基於數據庫的持久化方案去知足，因此這篇文章的重點就數據庫相關的架構方案設計和實現。若是文章中有哪些問題我沒有寫到的，你們能夠在評論區提問，我會一一解答或者直接把遺漏的內容補充在文章中。

---

持久層實現時要注意的隔離

在設計持久層架構的時候，咱們要關注如下幾個方面的隔離：

1. 持久層與業務層的隔離

2. 數據庫讀寫隔離

3. 多線程控制致使的隔離

4. 數據表達和數據操做的隔離

1. 持久層與業務層的隔離

關於Model

在具體講持久層下數據的處理以前，我以爲須要針對這個問題作一個完整的分析。

在View層設計中我分別提到了胖Model和瘦Model的設計思路，並且告訴你們我更加傾向於胖Model的設計思路。在網絡層設計裏面我使用了去Model化的思路設計了APIMananger與業務層的數據交互。這兩個看似矛盾的關於font color=#c7254e>Model的設計思路在我接下來要提出的持久層方案中實際上是並不矛盾，並且是相互配合的。在網絡層設計這篇文章中，我對去Model化只給出了思路和作法，相關的解釋並很少，是由於要解釋這個問題涉及面會比較廣，寫的時候並不認爲在那篇文章裏作解釋是最好的時機。因爲持久層在這裏胖Model和去Model化都會涉及，因此我以爲在講持久層的時候解釋這個話題會比較好。

我在跟別的各類領域的架構師交流的時候，發現你們都會或多或少地混用Model和Model Layer的概念，而後每每致使你們討論的問題最後都不在一個點上，說Model的時候他跟你說Model Layer，那好吧，我就跟你說Model Layer，結果他又在說Model，因而問題就討論不下去了。我以爲做爲架構師，若是不分清楚這兩個概念，確定是會對你設計的架構的質量有很大影響的。

若是把Model說成Data Model，而後跟Model Layer放在一塊兒，這樣就可以很容易區分概念了。

Data Model

Data Model這個術語針對的問題領域是業務數據的建模，以及代碼中這一數據模型的表徵方式。二者相輔相承：由於業務數據的建模方案以及業務自己特色，而最終決定了數據的表徵方式。一樣操做一批數據，你的數據建模方案基本都是細化業務問題以後，抽象得出一個邏輯上的實體。在實現這個業務時，你能夠選擇不一樣的表徵方式來表徵這個邏輯上的實體，好比字節流(TCP包等)，字符串流(JSON、XML等)，對象流。對象流又分通用數據對象(NSDictionary等)，業務數據對象(HomeCellModel等)。

前面已經遍歷了全部的Data Model的形式。在習慣上，當咱們討論Model化時，都是單指對象流中的業務數據對象這一種。然而去Model化就是指：更多地使用通用數據對象去表徵數據，業務數據對象不會在設計時被優先考慮的一種設計傾向。這裏的通用數據對象能夠在某種程度上理解爲範型。

Model Layer

Model Layer描述的問題領域是如何對數據進行增刪改查(CURD, Create Update Read Delete)，和相關業務處理。通常來講若是在Model Layer中採用瘦Model的設計思路的話，就差很少到CURD爲止了。胖Model還會關心如何爲須要數據的上層提供除了增刪改查之外的服務，併爲他們提供相應的解決方案。例如緩存、數據同步、弱業務處理等。

個人傾向

我更加傾向於去Model化的設計，在網絡層我設計了reformer來實現去Model化。在持久層，我設計了Virtual Record來實現去Model化。

由於具體的Model是一種很容易引入耦合的作法，在儘量弱化Model概念的同時，就可以爲引入業務和對接業務提供充分的空間。同時，也能經過去Model的設計達到區分強弱業務的目的，這在未來的代碼遷移和維護中，是相當重要的。不少設計很差的架構，就在於架構師並無認識到區分強弱業務的重要性，因此就致使架構腐化的速度很快，愈來愈難維護。

因此說回來，持久層與業務層之間的隔離，是經過強弱業務的隔離達到的。而Virtual Record正是由於這種去Model化的設計，從而達到了強弱業務的隔離，進而作到持久層與業務層之間既隔離同時又能交互的平衡。具體Virtual Record是什麼樣的設計，我在後面會給你們分析。

---

2. 數據庫讀寫隔離

在網站的架構中，對數據庫進行讀寫分離主要是爲了提升響應速度。在iOS應用架構中，對持久層進行讀寫隔離的設計主要是爲了提升代碼的可維護性。這也是兩個領域要求架構師在設計架構時要求側重點不一樣的一個方面。

在這裏咱們所謂的讀寫隔離並非指將數據的讀操做和寫操做作隔離。而是以某一條界限爲準，在這個界限之外的全部數據模型，都是不可寫不可修改，或者修改屬性的行爲不影響數據庫中的數據。在這個界限之內的數據是可寫可修改的。通常來講咱們在設計時劃分的這個界限會和持久層與業務層之間的界限保持一致，也就是業務層從持久層拿到數據以後，都不可寫不可修改，或業務層針對這一數據模型的寫操做、修改操做都對數據庫文件中的內容不產生做用。只有持久層中的操做纔可以對數據庫文件中的內容產生做用。

在蘋果官方提供的持久層方案Core Data的架構設計中，並無針對讀寫做出隔離，數據的結果都是以NSManagedObject扔出。因此只要業務工程師稍微一不當心動一下某個屬性，NSManagedObjectContext在save的時候就會把這個修改給存進去了。另外，當咱們須要對全部的增刪改查操做作AOP的切片時，Core Data技術棧的實現就會很是複雜。

總體上看，我以爲Core Data相對大部分需求而言是過分設計了。我當時設計安居客聊天模塊的持久層時就採用了Core Data，而後爲了讀寫隔離，將全部扔出來的NSManagedObject都轉爲了普通的對象。另外，因爲聊天記錄的業務至關複雜，使用Core Data以後爲了完成需求不得不引入不少Hack的手段，這種作法在必定程度上下降了這個持久層的可維護性和提升了接手模塊的工程師的學習曲線，這是不太好的。在天貓客戶端，我去的時候天貓這個App就已經屬於基本毫無持久層可言了，比較混亂。只能依靠各個業務線各顯神通去解決數據持久化的需求，難以推進統一的持久層方案，這對於項目維護尤爲是跨業務項目合做來講，基本就和車禍現場沒啥區別。我如今已經從天貓離職，讀者中如果有阿里人想升職想刷存在感拿3.75的，能夠考慮給天貓搞個統一的持久層方案。

讀寫隔離還可以便於加入AOP切點，由於針對數據庫的寫操做被隔離到一個固定的地方，加AOP時就很容易在正確的地方放入切片。這個會在講到數據同步方案時看到應用。

---

3. 多線程致使的隔離

Core Data

Core Data要求在多線程場景下，爲異步操做再生成一個NSManagedObjectContext，而後設置它的ConcurrencyType爲NSPrivateQueueConcurrencyType，最後把這個Context的parentContext設爲Main線程下的Context。這相比於使用原始的SQLite去作多線程要輕鬆許多。只不過要注意的是，若是要傳遞NSManagedObject的時候，不能直接傳這個對象的指針，要傳NSManagedObjectID。這屬於多線程環境下對象傳遞的隔離，在進行架構設計的時候須要注意。

SQLite

純SQLite其實對於多線程卻是直接支持，SQLite庫提供了三種方式：Single Thread，Multi Thread，Serialized。

Single Thread模式不是線程安全的，不提供任何同步機制。Multi Thread模式要求database connection不能在多線程中共享，其餘的在使用上就沒什麼特殊限制了。Serialized模式顧名思義就是由一個串行隊列來執行全部的操做，對於使用者來講除了響應速度會慢一些，基本上就沒什麼限制了。大多數狀況下SQLite的默認模式是Serialized。

根據Core Data在多線程場景下的表現，我以爲Core Data在使用SQLite做爲數據載體時，使用的應該就是Multi Thread模式。SQLite在Multi Thread模式下使用的是讀寫鎖，並且是針對整個數據庫加鎖，不是表鎖也不是行鎖，這一點須要提醒各位架構師注意。若是對響應速度要求很高的話，建議開一個輔助數據庫，把一個大的寫入任務先寫入輔助數據庫，而後拆成幾個小的寫入任務見縫插針地隔一段時間往主數據庫中寫入一次，寫完以後再把輔助數據庫刪掉。

不過從實際經驗上看，本地App的持久化需求的讀寫操做通常都不會大，只要注意好幾個點以後通常都不會影響用戶體驗。所以相比於Multi Thread模式，Serialized模式我認爲是性價比比較高的一種選擇，代碼容易寫容易維護，性能損失不大。爲了提升幾十毫秒的性能而犧牲代碼的維護性，我是以爲划不來的。

Realm

關於Realm我還沒來得及仔細研究，因此說不出什麼來。

---

4. 數據表達和數據操做的隔離

這是最容易被忽視的一點，數據表達和數據操做的隔離是否可以作好，直接影響的是整個程序的可拓展性。

長久以來，咱們都很習慣Active Record類型的數據操做和表達方式，例如這樣：

Record *record = [[Record alloc] init];
record.data = @"data";
[record save];

或者這種：

Record *record = [[Record alloc] init];
NSArray *result = [record fetchList];

簡單說就是，讓一個對象映射了一個數據庫裏的表，而後針對這個對象作操做就等同於針對這個表以及這個對象所表達的數據作操做。這裏有一個很差的地方就在於，這個Record既是數據庫中數據表的映射，又是這個表中某一條數據的映射。我見過不少框架(不只限於iOS，包括Python, PHP等)都把這二者混在一塊兒去處理。若是按照這種不恰當的方式來組織數據操做和數據表達，在胖Model的實踐下會致使強弱業務難以區分從而形成很是大的困難。使用瘦Model這種實踐自己就是我認爲有缺點的，具體的我在開篇中已經講過，這裏就不細說了。

強弱業務不能區分帶來的最大困難在於代碼複用和遷移，由於持久層中的強業務對View層業務的高耦合是沒法避免的，然而弱業務相對而言只對下層有耦合關係對上層並不存在耦合關係，當咱們作代碼遷移或者複用時，每每但願複用的是弱業務而不是強業務，若此時強弱業務分不開，代碼複用就無從談起，遷移時就倍加困難。

另外，數據操做和數據表達混在一塊兒會致使的問題在於：客觀狀況下，數據在view層業務上的表達方式多種多樣，有多是個View，也有多是個別的什麼對象。若是採用映射數據庫表的數據對象去映射數據，那麼這種多樣性就會被限制，實際編碼時每到使用數據的地方，就不得很少一層轉換。

我認爲之因此會產生這樣很差的作法緣由在於，對象對數據表的映射和對象對數據表達的映射結果很是類似，尤爲是在表達Column時，他們幾乎就是如出一轍。在這裏要作好針對數據表或是針對數據的映射要作的區分的關鍵要點是：這個映射對象的操做着手點相對數據表而言，是對內仍是對外操做。若是是對內操做，那麼這個操做範圍就僅限於當前數據表，這些操做映射給數據表模型就比較合適。若是是對外操做，執行這些操做時有可能涉及其餘的數據表，那麼這些操做就不該該映射到數據表對象中。

所以實際操做中，我是以數據表爲單位去針對操做進行對象封裝，而後再針對數據記錄進行對象封裝。數據表中的操做都是針對記錄的普通增刪改查操做，都是弱業務邏輯。數據記錄僅僅是數據的表達方式，這些操做最好交付給數據層分管強業務的對象去執行。具體內容我在下文還會繼續說。

---

持久層與業務層的交互方式

說到這裏，就不得不說CTPersistance和Virtual Record了。我會經過它來說解持久層與業務層之間的交互方式。

-------------------------------------------
                 |                                         |
                 |  LogicA     LogicB            LogicC    |    ------------------------------->    View Layer
                 |     \         /                 |       |
                 -------\-------/------------------|--------
                         \     /                   |
                          \   / Virtual            | Virtual
                           \ /  Record             | Record
                            |                      |
                 -----------|----------------------|--------
                 |          |                      |       |
  Strong Logics  |     DataCenterA            DataCenterB  |
                 |        /   \                    |       |
-----------------|-------/-----\-------------------|-------|    Data Logic Layer   ---
                 |      /       \                  |       |                         |
   Weak Logics   | Table1       Table2           Table     |                         |
                 |      \       /                  |       |                         |
                 --------\-----/-------------------|--------                         |
                          \   /                    |                                 |--> Data Persistance Layer
                           \ / Query Command       | Query Command                   |
                            |                      |                                 |
                 -----------|----------------------|--------                         |
                 |          |                      |       |                         |
                 |          |                      |       |                         |
                 |      DatabaseA              DatabaseB   |  Data Operation Layer ---
                 |                                         |
                 |             Database Pool               |
                 -------------------------------------------

我先解釋一下這個圖：持久層有專門負責對接View層模塊或業務的DataCenter，它們之間經過Record來進行交互。DataCenter向上層提供業務友好的接口，這通常都是強業務：好比根據用戶篩選條件返回符合要求的數據等。

而後DataCenter在這個接口裏面調度各個Table，作一系列的業務邏輯，最終生成record對象，交付給View層業務。

DataCenter爲了要完成View層交付的任務，會涉及數據組裝和跨表的數據操做。數據組裝由於View層要求的不一樣而不一樣，所以是強業務。跨表數據操做本質上就是各單表數據操做的組合，DataCenter負責調度這些單表數據操做從而得到想要的基礎數據用於組裝。那麼，這時候單表的數據操做就屬於弱業務，這些弱業務就由Table映射對象來完成。

Table對象經過QueryCommand來生成相應的SQL語句，並交付給數據庫引擎去查詢得到數據，而後交付給DataCenter。

DataCenter 和 Virtual Record

提到Virtual Record以前必須先說一下DataCenter。

DataCenter實際上是一個業務對象，DataCenter是整個App中，持久層與業務層之間的膠水。它向業務層開放業務友好的接口，而後經過調度各個持久層弱業務邏輯和數據記錄來完成強業務邏輯，並將生成的結果交付給業務層。因爲DataCenter處在業務層和持久層之間，那麼它執行業務邏輯所須要的載體，就要既可以被業務層理解，也可以被持久層理解。

CTPersistanceTable就封裝了弱業務邏輯，由DataCenter調用，用於操做數據。而Virtual Record就是前面提到的一個既可以被業務層理解，也可以被持久層理解的數據載體。

Virtual Record事實上並非一個對象，它只是一個protocol，這就是它Virtual的緣由。一個對象只要實現了Virtual Record，它就能夠直接被持久層看成Record進行操做，因此它也是一個Record。連起來就是Virtual Record了。因此，Virtual Record的實現者能夠是任何對象，這個對象通常都是業務層對象。在業務層內，常見的數據表達方式通常都是View，因此通常來講Virutal Record的實現者也都會是一個View對象。

咱們回顧一下傳統的數據操做過程：通常都是先從數據庫中取出數據，而後Model化成一個對象，而後再把這個模型丟到外面，讓Controller轉化成View，而後再執行後面的操做。

Virtual Record也是同樣遵循相似的步驟。惟一不一樣的是，整個過程當中，它並不須要一箇中間對象去作數據表達，對於數據的不一樣表達方式，由各自Virtual Record的實現者本身完成，而不須要把這些代碼放到Controller，因此這就是一個去Model化的設計。若是將來針對這個數據轉化邏輯有複用的需求，直接複用Virtual Record就能夠了，十分方便。

用好Virtual Record的關鍵在於DataCenter提供的接口對業務足夠友好，有充足的業務上下文環境。

因此DataCenter通常都是被Controller所持有，因此若是整個App就只有一個DataCenter，這其實並非一個好事。我見過有不少App的持久層就是一個全局單例，全部持久化業務都走這個單例，這是一種很蛋疼的作法。DataCenter也是須要針對業務作高度分化的，每一個大業務都要提供一個DataCenter，而後掛在相關Controller下交給Controller去調度。好比分化成SettingsDataCenter，ChatRoomDataCenter，ProfileDataCenter等，另外要要注意的是，幾個DataCenter之間最好不要有業務重疊。若是一個DataCenter的業務實在是大，那就再拆分紅幾個小業務。若是單個小業務都很大了，那就拆成各個Category，具體的作法能夠參考個人框架中CTPersistanceTable和CTPersistanceQueryCommand的實踐。

這麼一來，若是要遷移涉及持久層的強業務，那就只須要遷移DataCenter便可。若是要遷移弱業務，就只須要遷移CTPersistanceTable。

---

實際場景

假設業務層此時收集到了用戶的篩選條件：

NSDictionary *filter = @{
    @"key1":@{
        @"minValue1":@(1),
        @"maxValue1":@(9),
    },
    @"key2":@{
        @"minValue2":@(1),
        @"maxValue2":@(9),
    },
    @"key3":@{
        @"minValue3":@(1),
        @"maxValue3":@(9),
    },
};

而後ViewController調用DataCenter向業務層提供的接口，得到數據直接展現：

/* in view controller */

    NSArry *fetchedRecordList = [self.dataCenter fetchItemListWithFilter:filter]
    [self.dataList appendWithArray:fetchedRecordList];
    [self.tableView reloadData];

在View層要作的事情其實到這裏就已經結束了，此時咱們回過頭再來看DataCenter如何實現這個業務：

/* in DataCenter */

- (NSArray *)fetchItemListWithFilter:(NSDictionary *)filter
{
    ...
    ...
    ...

    /*
    解析filter得到查詢所須要的數據
    whereCondition
    whereConditionParams
    假設上面這兩個變量就是解析獲得的變量
    */

    ...
    ...
    ...

    /* 告知Table對象查詢數據後須要轉化成的對象(可選，統一返回對象能夠便於歸併來自不一樣表的數據) */
    self.itemATable.recordClass = [Item class];
    self.itemBTable.recordClass = [Item class];
    self.itemCTable.recordClass = [Item class];

    /* 經過Table對象獲取數據，此時Table對象內執行的就是弱業務了 */
    NSArray *itemAList = [self.itemATable findAllWithWhereCondition:whereCondition conditionParams:whereConditionParams isDistinct:NO error:NULL];
    NSArray *itemBList = [self.itemBTable findAllWithWhereCondition:whereCondition conditionParams:whereConditionParams isDistinct:NO error:NULL];
    NSArray *itemCList = [self.itemCTable findAllWithWhereCondition:whereCondition conditionParams:whereConditionParams isDistinct:NO error:NULL];

    /* 組裝數據 */
    NSMutableArray *resultList = [[NSMutableArray alloc] init];
    [resultList addObjectsFromArray:itemAList];
    [resultList addObjectsFromArray:itemBList];
    [resultList addObjectsFromArray:itemCList];

    return resultList;
}

基本上差很少就是上面這樣的流程。

通常來講，架構師設計得差的持久層，都沒有經過設計DataCenter和Table，去將強業務和弱業務分開。經過設計DataCenter和Table對象，主要是便於代碼遷移。若是遷移強業務，把DataCenter和Table一塊兒拿走就能夠，若是隻是遷移弱業務，拿走Table就能夠了。

另外，經過代碼我但願向你強調一下這個概念：將Table和Record區分開，這個在我以前畫的架構圖上已經有所表現，不過上文並無着重強調。其實不少別的架構師在設計持久層框架的時候，也沒有將Table和Record區分開，對的，這裏我說的框架包括Core Data和FMDB，這個也不只限於iOS領域，CodeIgniter、ThinkPHP、Yii、Flask這些也都沒有對這個作區分。(這裏吐槽一下，話說上文我還提到Core Data被過分設計了，事實上該設計的地方沒設計到，不應設計的地方各類設計往上堆...)

以上就是對Virtual Record這個設計的簡單介紹，接下來咱們就開始討論不一樣場景下如何進行交互了。

其中咱們最爲熟悉的一個場景是這樣的：通過各類邏輯組裝出一個數據對象，而後把這個數據對象交付給持久層去處理。這種場景我稱之爲一對一的交互場景，這個交互場景的實現很是傳統，就跟你們想得那樣，並且CTPersistance的test case裏面都是這樣的，因此這裏我就很少說了。因此，既然你已經知道有了一對一，那麼瓜熟蒂落地就也會有多對一，以及一對多的交互場景。

下面我會一一描述Virtual Record是如何發揮虛擬的優點去針對不一樣場景進行交互的。

多對一場景下，業務層如何與持久層交互？

多對一場景其實有兩種理解，一種是一個記錄的數據由多個View的數據組成。例如一張用戶表包含用戶的全部資料。而後有的View只包含用戶暱稱用戶頭像，有的對象只包含用戶ID用戶Token。然而這些數據都只存在一張用戶表中，因此這是一種多個對象的數據組成一個完整Record數據的場景，這是多對一場景的理解之一。

第二種理解是這樣的，例如一個ViewA對象包含了一個Record的全部信息，而後另外一個ViewB對象其實也包含了一個Record的全部信息，這就是一種多個不一樣對象表達了一個Record數據的場景，這也是一種多對一場景的理解。

同時，這裏所謂的交互還分兩個方向：存和取。

其實這兩種理解的解決方案都是同樣的，Virtual Record的實現者經過實現Merge操做來完成record數據的彙總，從而實現存操做。任意Virtual Record的實現者經過Merge操做，就能夠將本身的數據交付給其它不一樣的對象進行表達，從而實現取操做。具體的實如今下面有具體闡釋。

多對一場景下，如何進行存操做？

提供了- (NSObject )mergeRecord:(NSObject )record shouldOverride:(BOOL)shouldOverride; 這個方法。望文生義一下，就是一個record能夠與另一個record進行merge。在shouldOverride爲NO的狀況下，任何一邊的nil都會被另一邊不是nil的記錄覆蓋，若是merge過程當中兩個對象都不含有這些空數據，則根據shouldOverride來決定是否要讓參數中record的數據覆蓋本身自己的數據，若shouldOverride爲YES，則即使是nil，也會把已有的值覆蓋掉。這個方法會返回被Merge的這個對象，便於鏈式調用。

舉一個代碼樣例：

/*
這裏的RecordViewA, RecordViewB, RecordViewC都是符合<CTPersistanceRecordProtocol>且實現了- (NSObject <CTPersistanceRecordProtocol> *)mergeRecord:(NSObject <CTPersistanceRecordProtocol> *)record shouldOverride:(BOOL)shouldOverride方法。
*/

RecordViewA *a;
RecordViewB *b;
RecordViewC *c;

...
收集a, b, c的值的邏輯，我就不寫了～
...

[[a mergeRecord:b shouldOverride:YES] mergeRecord:c shouldOverride:YES];
[self.dataCenter saveRecord:a];

基本思路就是經過merge不一樣的record對象來達到獲取完整數據的目的，因爲是Virtual Record，具體的實現都是由各自的View去決定。View是最瞭解本身屬性的對象了，所以它是有充要條件來把本身與持久層相關的數據取出並Merge的，那麼這段湊數據的代碼，就相應分散到了各個View對象中，Controller裏面就可以作到很是乾淨，總體可維護性也就提升了。

若是採用傳統方式，ViewController或者DataCenter中就會散落不少用於湊數據的代碼，寫的時候就會出現一大段用於合併的代碼，很是難看，還不容易維護。

多對一場景下，如何進行取操做？

其實這樣的表述並不恰當，由於不管Virtual Record的實現如何，對象是誰，只要從數據庫裏面取出數據來，數據就都是可以保證完整的。這裏更準確的表述是，取出數據以後，如何交付給不一樣的對象。其實仍是用到上面提到的mergeRecord方法來處理。

/*
這裏的RecordViewA, RecordViewB, RecordViewC都是符合<CTPersistanceRecordProtocol>且實現了- (NSObject <CTPersistanceRecordProtocol> *)mergeRecord:(NSObject <CTPersistanceRecordProtocol> *)record shouldOverride:(BOOL)shouldOverride方法。
*/

RecordViewA *a;
RecordViewB *b = [[RecordViewB alloc] init];
RecordViewC *c = [[RecordViewC alloc] init];

a = [self.table findLatestRecordWithError:NULL];
[b mergeRecord:a];
[c mergeRecord:a];

return @[a, b, c]

這樣就能很容易把a記錄的數據交給b和c了，代碼觀感一樣很是棒，並且容易寫容易維護。

一對多場景下，業務層如何與持久層交互？

一對多場景也有兩種理解，其一是一個對象包含了多個表的數據，另一個是一個對象用於展現多種表的數據，這個代碼樣例其實文章前面已經有過，這一節會着重強調一下。乍看之下二者並無什麼區別，因此我須要指出的是，前者強調的是包含，也就是這個對象是個大熔爐，由多個表的數據組成。

仍是舉用戶列表的例子：

假設數據庫中用戶相關的表有多張。大多數狀況是由於單表Column太多，因此爲了提升維護性和查詢性能而進行的縱切。

多說一句，縱切在實際操做時，大多都是根據業務場景去切分紅多個不一樣的表，分別來表達用戶各業務相關的部分數據，因此縱切的結果就是把Column特別多的一張表拆成Column不那麼多的好幾個表。雖然數據庫通過了縱切，可是有的場景仍是要展現完整數據的，好比用戶詳情頁。所以，這個用戶詳情頁的View就有可能包含用戶基礎信息表(用戶名、用戶ID、用戶Token等)、以及用戶詳細信息表（用戶郵箱地址、用戶手機號等）。這就是一對多的一個對象包含了多個表的數據的意思。

後者強調的是展現。舉個例子，數據庫中有三個表分別是：

二手房、新房、租房，它們三者的數據分別存儲在三個表裏面，這實際上是一種橫切。

橫切也是一種數據庫的優化手段，橫切與縱切不一樣的地方在於，橫切是在保留了這套數據的完整性的前提下進行的切分，橫切的結果就是把一個本來數據量很大的表，分紅了好幾個數據量不那麼大的表。也就是原來三種房子都能用同一個表來存儲，可是這樣數據量就太大了，數據庫響應速度就會降低。因此根據房子的類型拆成這三張表。橫切也有根據ID切的，好比根據ID取餘的結果來決定分在哪些表裏，這種作法比較普遍，由於拓展起來方便，到時候數據表又大了，大不了除數也跟着再換一個更大的數罷了。其實根據類型去橫切也能夠，只是拓展的時候就不那麼方便。

剛纔扯遠瞭如今我再扯回來，這三張表在展現的時候，只是根據類型的不一樣，界面纔有稍許不一樣而已，因此仍是會用同一張View去展現這三種數據，這就是一對多的一個對象用於展現多種表的數據的意思。

一個對象包含了多個表的數據時，如何進行存取操做？

在進行取操做時，其實跟前面多對一的取操做是同樣的，用Merge操做就能夠了。

RecordViewA *a;

a = [self.CasaTable findLatestRecordWithError:NULL];
[a mergeRecord:[self.TaloyumTable findLatestRecordWithError:NULL] shouldOverride:YES];
[a mergeRecord:[self.CasatwyTable findLatestRecordWithError:NULL] shouldOverride:YES];

return a;

在進行存操做時，Virtual Record的 要求實現者實現- (NSDictionary )dictionaryRepresentationWithColumnInfo:(NSDictionary )columnInfo tableName:(NSString *)tableName;這個方法，實現者能夠根據傳入的columnInfo和tableName返回相應的數據，這樣就可以把這一次存數據時關心的內容提供給持久層了。代碼樣例就是這樣的：

RecordViewA *a = ...... ;

/*
因爲有- (NSDictionary *)dictionaryRepresentationWithColumnInfo:(NSDictionary *)columnInfo tableName:(NSString *)tableName;的實現，a對象本身會提供給不一樣的Table它們感興趣的內容而存儲。

因此直接存就行了。
*/

[self.CasaTable insertRecord:a error:NULL];
[self.TaloyumTable insertRecord:a error:NULL];
[self.CasatwyTable insertRecord:a error:NULL];

經過上面的存取案例，你會發現使用Virtual Record以後，代碼量一會兒少掉不少，本來那些亂七八糟用於拼湊條件的代碼所有被分散進了各個虛擬記錄的實現中去了，代碼維護所以就變得至關方便。如果採用傳統作法，再存取以前少不了要寫一大段邏輯，若是涉及代碼遷移，這大段邏輯就也得要跟着遷移過去，這就很蛋疼了。

一個對象用於展現多種表的數據，如何進行存取操做？

在這種狀況下的存操做其實跟上面同樣，直接存。Virtual Record的實現者本身會根據要存入的表的信息組裝好數據提供給持久層。樣例代碼與上一小節的存操做中給出的如出一轍，我就不復制粘貼了。

取操做就不太同樣了，不過因爲取出時的對象是惟一的(由於一對多嘛)，代碼也同樣十分簡單：

ViewRecord *a;
ViewRecord *b;
ViewRecord *c;

self.itemATable.recordClass = [ViewRecord class];
self.itemBTable.recordClass = [ViewRecord class];
self.itemCTable.recordClass = [ViewRecord class];

[a = self.itemATable findLatestRecordWithError:NULL];
[b = self.itemBTable findLatestRecordWithError:NULL];
[c = self.itemCTable findLatestRecordWithError:NULL];

這裏的a，b，c都是同一個View，而後itemATable，itemBTable，itemCTable分別是不一樣種類的表。這個例子表示了一個對象如何用於展現不一樣類型的數據。若是使用傳統方法，這裏少不了要寫不少適配代碼，可是使用Virtual Record以後，這些代碼都由各自實現者消化掉了，在執行數據邏輯時能夠無需關心適配邏輯。

多對多場景？

其實多對多場景就是上述這些一對多和多對一場景的排列組合，實現方式都是如出一轍的，我這裏就也很少囉嗦了。

---

交互方案的總結

在交互方案的設計中，架構師應當區分好強弱業務，把傳統的Data Model區分紅Table和Record，並由DataCenter去實現強業務，Table去實現弱業務。在這裏因爲DataCenter是強業務相關，因此在實際編碼中，業務工程師負責建立DataCenter，並向業務層提供業務友好的方法，而後再在DataCenter中操做Table來完成業務層交付的需求。區分強弱業務，將Table和Record拆分開的好處在於：

1. 經過業務細分下降耦合度，使得代碼遷移和維護很是方便

2. 經過拆解數據處理邏輯和數據表達形態，使得代碼具備很是良好的可拓展性

3. 作到讀寫隔離，避免業務層的誤操做引入Bug

4. 爲Virtual Record這一設計思路的實踐提供基礎，進而實現更靈活，對業務更加友好的架構

任何不區分強弱業務的架構都是架構師在耍流氓，嗯。

在具體與業務層交互時，採用Virtual Record的設計思路來設計Record，由具體的業務對象來實現Virtual Record，並以它做爲DataCenter和業務層之間的數據媒介進行交互。而不是使用傳統的數據模型來與業務層作交互。

使用Virtual Record的好處在於：

1. 將數據適配和數據轉化邏輯封裝到具體的Record實現中，能夠使得代碼更加抽象簡潔，代碼污染更少

2. 數據遷移時只須要遷移Virtual Record相關方法便可，很是容易拆分

3. 業務工程師實現業務邏輯時，能夠在不損失可維護性的前提下，極大提升業務實現的靈活性

這一部分還順便提了一下橫切和縱切的概念。原本是打算有一小節專門寫數據庫性能優化的，不過事實上移動App場景下數據庫的性能優化手段不像服務端那樣豐富多彩，不少牛逼技術和參數調優手段想用也用不了。差很少就只剩下數據切片的手段比較有效了，因此性能優化這塊感受沒什麼好寫的。其實你們瞭解了切片的方式和場景，就足以根據本身的業務場景去作優化了。再使用一下Instrument的Time Profile再配合SQLite提供的一些函數，就足以找到慢在哪兒，而後去作性能調優了。但若是我把這些也寫出來，就變成教你怎麼使用工具，感受這個太low寫着也不起勁，你們有興趣搜使用手冊下來看就行。

---

數據庫版本遷移方案

通常來講，具備持久層的App同時都會附帶着有版本遷移的需求。當一個用戶安裝了舊版本的App，此時更新App以後，若數據庫的表結構須要更新，或者數據自己須要批量地進行更新，此時就須要有版本遷移機制來進行這些操做。然而版本遷移機制又要兼顧跨版本的遷移需求，因此基本上大方案也就只有一種：創建數據庫版本節點，遷移的時候一個一個跑過去。

數據遷移事實上實現起來仍是比較簡單的，作好如下幾點問題就不大了：

1. 根據應用的版本記錄每一版數據庫的改變，並將這些改變封裝成對象

2. 記錄好當前數據庫的版本，便於跟遷移記錄作比對

3. 在啓動數據庫時執行遷移操做，若是遷移失敗，提供一些降級方案

CTPersistance在數據遷移方面，凡是對於數據庫本來沒有的數據表，若是要新增，在使用table的時候就會自動建立。所以對於業務工程師來講，根本不須要額外多作什麼事情，直接用就能夠了。把這部分工做放到這裏，也是爲數據庫版本遷移節省了一些步驟。

CTPersistance也提供了Migrator。業務工程師能夠本身針對某一個數據庫編寫一個Migrator。這個Migrator務必派生自CTPersistanceMigrator，且符合 ，只要提供一個migrationStep的字典，以及記錄版本順序的數組。而後把你本身派生的Migrator的類名和對應關心的數據庫名寫在CTPersistanceConfiguration.plist裏面就能夠。CTPersistance會在初始數據庫的時候，根據plist裏面的配置對應找到Migrator，並執行數據庫版本遷移的邏輯。

在版本遷移時要注意的一點是性能問題。咱們通常都不會在主線程作版本遷移的事情，這天然沒必要說。須要強調的是，SQLite自己是一個容錯性很是強的數據庫引擎，所以差很少在執行每個SQL的時候，內部都是走的一個Transaction。當某一版的SQL數量特別多的時候，建議在版本遷移的方法裏面本身創建一個Transaction，而後把相關的SQL都包起來，這樣SQLite執行這些SQL的時候速度就會快一點。

其餘的彷佛並無什麼要額外強調的了，若是有沒說到的地方，你們能夠在評論區提出來。

---

數據同步方案

數據同步方案大體分兩種類型，一種類型是單向數據同步，另外一種類型是雙向數據同步。下面我會分別說說這兩種類型的數據同步方案的設計。

單向數據同步

單向數據同步就是隻把本地較新數據的操做同步到服務器，不會從服務器主動拉取同步操做。

好比即時通信應用，一個設備在發出消息以後，須要等待服務器的返回去知道這個消息是否發送成功，是否取消成功，是否刪除成功。而後數據庫中記錄的數據就會隨着這些操做是否成功而改變狀態。可是若是換一臺設備繼續執行操做，在這個新設備上只會拉取舊的數據，好比聊天記錄這種。但對於舊的數據並無刪除或修改的需求，所以新設備也不會問服務器索取數據同步的操做，因此稱之爲單向數據同步。

單向數據同步通常來講也不須要有job去作定時更新的事情。若是一個操做遲遲沒有收到服務器的確認，那麼在應用這邊就能夠認爲這個操做失敗，而後通常都是在界面上把這些失敗的操做展現出來，而後讓用戶去勾選須要重試的操做，而後再從新發起請求。微信在消息發送失敗的時候，就是消息前面有個紅色的圈圈，裏面有個感嘆號，只有用戶點擊這個感嘆號的時候才從新發送消息，背後不會有個job一直一直跑。

因此細化需求以後，咱們發現單向數據同步只須要作到可以同步數據的狀態便可。

如何完成單向數據同步的需求

添加identifier

添加identifier的目的主要是爲了解決客戶端數據的主鍵和服務端數據的主鍵不一致的問題。因爲是單向數據同步，因此數據的生產者只會是當前設備，那麼identifier也理所應當由設備生成。當設備發起同步請求的時候，把identifier帶上，當服務器完成任務返回數據時，也把這些identifier帶上。而後客戶端再根據服務端給到的identifier再更新本地數據的狀態。identifier通常都會採用UUID字符串。

添加isDirty

isDirty主要是針對數據的插入和修改進行標識。當本地新生成數據或者更新數據以後，收到服務器的確認返回以前，isDirty置爲YES。當服務器的確認包返回以後，再根據包裏提供的identifier找到這條數據，而後置爲NO。這樣就完成了數據的同步。

然而這只是簡單的場景，有一種比較極端的狀況在於，當請求發起到收到請求回覆的這短短几秒間，用戶又修改了數據。若是按照當前的邏輯，在收到請求回覆以後，這個又修改了的數據的isDirty會被置爲NO，因而這個新的修改就永遠沒法同步到服務器了。這種極端狀況的簡單處理方案就是在發起請求到收到回覆期間，界面上不容許用戶進行修改。

若是但願作得比較細緻，在發送同步請求期間依舊容許用戶修改的話，就須要在數據庫額外增長一張DirtyList來記錄這些操做，這個表裏至少要有兩個字段：identifier，primaryKey。而後每一次操做都分配一次identifier，那麼新的修改操做就有了新的identifier。在進行同步時，根據primaryKey找到原數據表裏的那條記錄，而後把數據連同identifier交給服務器。而後在服務器的確認包回來以後，就只要拿出identifier再把這條操做記錄刪掉便可。這個表也能夠直接服務於多個表，只是還須要額外添加一個tablename字段，方便發起同步請求的時候可以找獲得數據。

添加isDeleted

當有數據同步的需求的時候，刪除操做就不能是簡單的物理刪除了，而只是邏輯刪除，所謂邏輯刪除就是在數據庫裏把這條記錄的isDeleted記爲YES，只有當服務器的確認包返回以後，纔會真正把這條記錄刪除。isDeleted和isDirty的區別在於：收到確認包後，返回的identifier指向的數據若是是isDeleted，那麼就要刪除這條數據，若是指向的數據只是新插入的數據和更新的數據，那麼就只要修改狀態就行。插入數據和更新數據在收到數據包以後作的操做是相同的，因此就用isDirty來區分就足夠了。總之，這是根據收到確認包以後的操做不一樣而作的區分。二者都要有，缺一不可。

在請求的數據包中，添加dependencyIdentifier

在我看到的不少其它數據同步方案中，並無提供dependencyIdentifier，這會致使一個這樣的問題：假設有兩次數據同步請求一塊兒發出，A先發，B後發。結果反而是B請求先到，A請求後到。若是A請求的一系列同步操做裏面包含了插入某個對象的操做，B請求的一系列同步操做裏面正好又刪除了這個對象，那麼因爲到達次序的前後問題錯亂，就致使這個數據沒辦法刪除。

這個在移動設備的使用場景下是很容易發生的，移動設備自己網絡環境就多變，先發的包反然後到，這種狀況出現的概率仍是比較大的。因此在請求的數據包中，咱們要帶上上一次請求時一系列identifier的其中一個，就能夠了。通常都是選擇上次請求裏面最後的那一個操做的identifier，這樣就能表徵上一次請求的操做了。

服務端這邊也要記錄最近的100個請求包裏面的最後一個identifier。之因此是100條純屬只是拍腦殼定的數字，我以爲100條差很少就夠了，客戶端發請求的時候denpendency應該不會涉及到前面100個包。服務端在收到同步請求包的時候，先看denpendencyIdentifier是否已被記錄，若是已經被記錄了，那麼就執行這個包裏面的操做。若是沒有被記錄，那就先放着再等等，等到條件知足了再執行，這樣就能解決這樣的問題。

之因此不用更新時間而是identifier來作標識，是由於若是要用時間作標識的話，就是隻能以客戶端發出數據包時候的時間爲準。但有時不一樣設備的時間不必定徹底對得上，多少會差個幾秒幾毫秒，另外若是同時有兩個設備發起同步請求，這兩個包的時間就都是同樣的了。假設A1, B1是1號設備發送的請求，A2, B2，是2號設備發送的請求，若是用時間去區分，A1到了以後，B2說不定就直接可以執行了，而A1還沒到服務器呢。

固然，這也是一種極端狀況，用時間的話，服務器就只要記錄一個時間了，凡是依賴時間大於這個時間的，就都要再等等，實現起來就比較方便。可是爲了保證bug儘量少，我認爲依賴仍是以identifier爲準，這要比以時間爲準更好，並且實現起來其實也並無增長太多複雜度。

單向數據同步方案總結

1. 改造的時候添加identifier，isDirty，isDeleted字段。若是在請求期間依舊容許對數據作操做，那麼就要把identifier和primaryKey再放到一個新的表中

2. 每次生成數據以後對應生成一個identifier，而後只要是針對數據的操做，就修改一次isDirty或isDeleted，而後發起請求帶上identifier和操做指令去告知服務器執行相關的操做。若是是複雜的同步方式，那麼每一次修改數據時就新生成一次identifier，而後再發起請求帶上相關數據告知服務器。

3. 服務器根據請求包的identifier等數據執行操做，操做完畢回覆給客戶端確認

4. 收到服務器的確認包以後，根據服務器給到的identifier（有的時候也會有tablename，取決於你的具體實現）找到對應的記錄，若是是刪除操做，直接把數據刪除就好。若是是插入和更新操做，就把isDirty置爲NO。若是有額外的表記錄了更新操做，直接把identifier對應的這個操做記錄刪掉就行。

要注意的點

在使用表去記錄更新操做的時候，短期以內頗有可能針對同一條數據進行屢次更新操做。所以在同步以前，最好可以合併這些相同數據的更新操做，能夠節約服務器的計算資源。固然若是你服務器強大到不行，那就無所謂了。

---

雙向數據同步

雙向數據同步多見於筆記類、日程類應用。對於一臺設備來講，不光本身會往上推數據同步的信息，本身也會問服務器主動索取數據同步的信息，因此稱之爲雙向數據同步。

舉個例子：當一臺設備生成了某時間段的數據以後，到了另一臺設備上，又修改了這些舊的歷史數據。此時再回到原來的設備上，這臺設備就須要主動問服務器索取是否舊的數據有修改，若是有，就要把這些操做下載下來同步到本地。

雙向數據同步實現上會比單向數據同步要複雜一些，並且有的時候還會存在實時同步的需求，好比協同編輯。因爲自己方案就比較複雜，另一定要兼顧業務工程師的上手難度（這主要看你這個架構師的良心），因此要實現雙向數據同步方案的話，仍是頗有意思比較有挑戰的。

如何完成雙向數據同步的需求

封裝操做對象

這個其實在單向數據同步時多少也涉及了一點，可是因爲單向數據同步的要求並不複雜，只要告訴服務器是什麼數據而後要作什麼事情就能夠了，卻是不必將這種操做封裝。在雙向數據同步時，你也得解析數據操做，因此互相之間要約定一個協議，經過封裝這個協議，就作到了針對操做對象的封裝。

這個協議應當包括：

1. 操做的惟一標識

2. 數據的惟一標識

3. 操做的類型

4. 具體的數據，主要是在Insert和Update的時候會用到

5. 操做的依賴標識

6. 用戶執行這項操做時的時間戳

分別解釋一下這6項的意義：

1. 操做的惟一標識

這個跟單向同步方案時的做用同樣，也是在收到服務器的確認包以後，可以使得本地應用找到對應的操做並執行確認處理。

2. 數據的惟一標識

在找到具體操做的時候執行確認邏輯的處理時，都會涉及到對象自己的處理，更新也好刪除也好，都要在本地數據庫有所體現。因此這個標識就是用於找到對應數據的。

3. 操做的類型

操做的類型就是Delete，Update，Insert，對應不一樣的操做類型，對本地數據庫執行的操做也會不同，因此用它來進行標識。

4. 具體的數據

當更新的時候有Update或者Insert操做的時候，就須要有具體的數據參與了。這裏的數據有的時候不見得是單條的數據內容，有的時候也會是批量的數據。好比把全部10月1日以前的任務都標記爲已完成狀態。所以這裏具體的數據如何表達，也須要定一個協議，何時做爲單條數據的內容去執行插入或更新操做，何時做爲批量的更新去操做，這個本身根據實際業務需求去定義就行。

5. 操做的依賴標識

跟前面提到的依賴標識同樣，是爲了防止先發的包後到後發的包先到這種極端狀況。

6. 用戶執行這項操做的時間戳

因爲跨設備，又由於舊數據也會被更新，所以在必定程度上就會出現衝突的可能。操做數據在從服務器同步下來以後，會存放在一個新的表中，這個表就是待操做數據表，在具體執行這些操做的同時會跟待同步的數據表中的操做數據作比對。若是是針對同一條數據的操做，且這兩個操做存在衝突，那麼就以時間戳來決定如何執行。還有一種作法就是直接提交到界面告知用戶，讓用戶作決定。

新增待操做數據表和待同步數據表

前面已經部分提到這一點了。從服務器拉下來的同步操做列表，咱們存在待執行數據表中，操做完畢以後若是有告知服務器的需求，那就等因而走單向同步方案告知服務器。在執行過程當中，這些操做也要跟待同步數據表進行匹配，看有沒有衝突，沒有衝突就繼續執行，有衝突的話要麼按照時間戳執行，要麼就告知用戶讓用戶作決定。在拉取待執行操做列表的時候，也要把最後一次操做的identifier丟給服務器，這樣服務器才能返回相應數據。

待同步數據表的做用其實也跟單向同步方案時候的做用相似，就是防止在發送請求的時候用戶有操做，同時也是爲解決衝突提供方便。在發起同步請求以前，咱們都應該先去查詢有沒有待執行的列表，當待執行的操做列表同步完成以後，就能夠刪除裏面的記錄了，而後再把本地待同步的數據交給服務器。同步完成以後就能夠把這些數據刪掉了。所以在正常狀況下，只有在待操做和待執行的操做間會存在衝突。有些從道理上講也算是衝突的事情，好比獲取待執行的數據比較晚，但其中又和待同步中的操做有衝突，像這種極端狀況咱們其實也無解，只能由他去，不過這種狀況也是屬於比較極端的狀況，發生概率不大。

什麼時候從服務器拉取待執行列表

1. 每次要把本地數據丟到服務器去同步以前，都要拉取一次待執行列表，執行完畢以後再上傳本地同步數據

2. 每次進入相關頁面的時候都更新一次，看有沒有新的操做

3. 對實時性要求比較高的，要麼客戶端本地起一個線程作輪詢，要麼服務器經過長連接將待執行操做推送過來

4. 其它我暫時也想不到了，具體仍是看需求吧

雙向數據同步方案總結

1. 設計好同步協議，用於和服務端進行交互，以及指導本地去執行同步下來的操做

2. 添加待執行，待同步數據表記錄要執行的操做和要同步的操做

要注意的點

我也見過有的方案是直接把SQL丟出去進行同步的，我不建議這麼作。最好仍是將操做和數據分開，而後細化，不然檢測衝突的時候你就得去分析SQL了。要是這種實現中有什麼bug，解這種bug的時候就要考慮先後兼容問題，機制重建成本等，由於貪圖一時偷懶，到最後其實得不償失。

---

總結

這篇文章主要是基於CTPersistance講了一下如何設計持久層的設計方案，以及數據遷移方案和數據同步方案。

着重強調了一下各類持久層方案在設計時要考慮的隔離，以及提出了Virtual Record這個設計思路，並對它作了一些解釋。而後在數據遷移方案設計時要考慮的一些點。在數據同步方案這一節，分開講了單向的數據同步方案和雙向的數據同步方案的設計，然而具體實現仍是要依照具體的業務需求來權衡。

但願你們以爲這些內容對各自工做中遇到的問題可以有所價值，若是有問題，歡迎在評論區討論。

另外，關於動態部署方案，其實直到今天在iOS領域也並無特別好的動態部署方案能夠拿出來，我以爲最靠譜的其實仍是H5和Native的Hybrid方案。React Native在我看來相比於Hybrid仍是有比較多的限制。關於Hybrid方案，我也提供了CTJSBridge這個庫去實現這方面的需求。在動態部署方案這邊其實成文已經好久，遲遲不發的緣由仍是由於以爲當時並無什麼銀彈能夠解決iOS App的動態部署，另外也有一些問題沒有考慮清楚。當初想到的那些問題如今我已經確認無解。當初寫的動態部署方案我一直認爲它沒法做爲一個單獨的文章發佈出來，因此我就把這篇文章也放在這裏，權當給各位參考。