最早接觸 iOS 開(kāi)發(fā)了解到的第一個(gè)緩存數(shù)據(jù)庫(kù)就是 SQLite，后面一直也以 SQLite 作為中堅(jiān)力量使用，以前沒(méi)有接觸到比較大量數(shù)據(jù)的讀寫(xiě)，所以在性能優(yōu)化方面關(guān)注不多，這次對(duì)一個(gè)特定場(chǎng)景的較多數(shù)據(jù)批量讀寫(xiě)做了一個(gè)性能優(yōu)化，使性能提高了十倍。

大致應(yīng)用場(chǎng)景是這樣：

每次程序啟動(dòng)會(huì)從服務(wù)器拉取一些數(shù)據(jù)，對(duì)本地?cái)?shù)據(jù)庫(kù)兩個(gè)表進(jìn)行同步更新，不存在就寫(xiě)入，存在就更新其字段。數(shù)據(jù)少的時(shí)候幾十條，多的上千條。

由于緩存的數(shù)據(jù)可能會(huì)存在異步同時(shí)讀寫(xiě)，所以做了一個(gè)后臺(tái)同步隊(duì)列，所有的緩存數(shù)據(jù)庫(kù)操作都在這個(gè)隊(duì)列里面，然后我監(jiān)控了一下寫(xiě)數(shù)據(jù)庫(kù)的關(guān)鍵代碼執(zhí)行耗時(shí)，一千條數(shù)據(jù)更新到數(shù)據(jù)庫(kù)就能耗時(shí) 30 秒之久，磁盤(pán)寫(xiě)入在 1.5M/s 浮動(dòng)， 雖然沒(méi)有卡主線(xiàn)程，這個(gè)消耗即使在后臺(tái)也是不可容忍的。

核心的數(shù)據(jù)庫(kù)操作大概是這樣的

for 1000 : {

Select -> Update Or Insert

Select -> Update Or Insert

}

由于牽涉到兩張表，所以會(huì)有兩次，經(jīng)過(guò)測(cè)試，Select 一次幾乎沒(méi)有多少消息，可是 Update 或者 Insert ( [FMDatabaseQueue executeUpdate:] ) 就消耗大了，因?yàn)闀?huì)寫(xiě)入磁盤(pán)，然后想到是不是可以把所有的 SQL 語(yǔ)句拼接起來(lái)，最后只想一次；再后來(lái)想到 SQLite 不是有事務(wù) ( Transaction ) 嘛，于是嘗試了一下利用 FMDB 的事務(wù)操作，在循環(huán)開(kāi)始前 [db beginTransaction] ，循環(huán)結(jié)束 [db commit]，包起來(lái)就行了。

增加事務(wù)之后的大概邏輯：

beginTransaction

for 1000 : {

Select -> Update Or Insert

Select -> Update Or Insert

}

commit

測(cè)試效果非常好，整個(gè)耗時(shí)從 30 秒下降到了2.8 秒左右，僅僅增加了兩行代碼。

總結(jié)：

踩過(guò)的坑，走過(guò)的坎，都是以后的經(jīng)驗(yàn)

雖然利用事務(wù)取巧來(lái)提高了性能，但是這樣做其實(shí)并不安全，好在所屬場(chǎng)景對(duì)這部分?jǐn)?shù)據(jù)絕對(duì)一致要求不是太高。
模擬器和真機(jī)有時(shí)候測(cè)試并不能重現(xiàn)同一個(gè)問(wèn)題，因?yàn)樗鶎偌軜?gòu)、CPU、硬盤(pán)都不一樣，所以性能測(cè)試最好還是以真機(jī)為準(zhǔn)。該問(wèn)題測(cè)試的時(shí)候在模擬器上很多問(wèn)題都沒(méi)有，因?yàn)橛脖P(pán)比真機(jī)讀寫(xiě)速度要高，所以避免了很多問(wèn)題，測(cè)試的時(shí)候也就沒(méi)有發(fā)現(xiàn)。
數(shù)據(jù)庫(kù)設(shè)計(jì)設(shè)計(jì)的時(shí)候得多考慮考慮，多想想以后怎么擴(kuò)展，怎么升級(jí)，讀寫(xiě)的時(shí)候性能怎么樣

最新評(píng)論