昨天我們講解了程序性能優(yōu)化中的內(nèi)存優(yōu)化，今天繼續(xù)跟隨南昌網(wǎng)絡公司小編學習如何優(yōu)化程序性能。重點分析程序性能優(yōu)化之優(yōu)化資源文件，延遲加載和數(shù)據(jù)持久優(yōu)化這三種方法，讓你的程序“飛”起來。

從狹義上講，資源文件是放置在應用程序本地與應用程序一起編譯、打包和發(fā)布的非程序代碼文件，如應用中用到的聲音、視頻、圖片和文本文件等。從廣義上講，資源文件可以放置于任何地方，既可以放置于本地，也可以放在云服務器中。

在iOS中，本地資源文件編譯后，會放置于應用程序包文件中(即<應用名>.app文件)。如下代碼用于訪問如圖1所示team.plist本地資源文件：

圖1 資源文件

圖1所示的“球隊圖片”組也放置了一些資源文件。添加資源文件的方法是通過右鍵添加文件到工程中。資源文件在使用的過程中需要優(yōu)化，包括文件格式、文件類型、文件大小和文件結(jié)構(gòu)等方面，使得它更適合某個應用?！斑m合”這兩個字很重要。當然，優(yōu)化方向有很多，下面我們從圖片文件優(yōu)化和音頻文件優(yōu)化這兩個方面介紹一下。

1.圖片文件優(yōu)化

圖片文件優(yōu)化包括文件格式和文件大小的優(yōu)化。在移動設備中，支持的圖片格式主要是PNG、GIF和JPEG格式，蘋果推薦使用PNG格式。在Xcode中，集成了第三方PNG優(yōu)化工具pngcrush①，它可以在編譯的時候?qū)NG格式文件進行優(yōu)化和壓縮，而我們只需要設定如圖2所示的編譯參數(shù)Compress PNG Files為Yes就可以了。

圖2 設定編譯參數(shù)Compress PNG Files

打開“ ImageFile”工程中“測試圖片”目錄中background(未優(yōu)化).png文件，在Finder中查看該文件的屬性，它是一個320×480px、大小為317KB的PNG圖片，如圖3所示。

使用Xcode編譯工程，在編譯之后的目錄中找到ImageFile.app包文件。打開包文件，查看目錄中background(未優(yōu)化).png文件的屬性，可以發(fā)現(xiàn)該文件是205KB的PNG圖片了，如圖4所示。

圖3 未優(yōu)化的PNG文件屬性

圖4 優(yōu)化的PNG文件屬性

Xcode工具可以在編譯時優(yōu)化PNG圖片，但是即便經(jīng)過優(yōu)化和壓縮的PNG圖片文件，也比JPEG圖片文件大得多。開“ImageFile”工程中“測試圖片”目錄中的background-8(優(yōu)化壓縮).png文件和background-h.jpg文件，比較可以發(fā)現(xiàn)，前者是經(jīng)過優(yōu)化的質(zhì)量最低的PNG-8(8位PNG格式)文件，其大小是61KB;后者是經(jīng)過優(yōu)化的質(zhì)量最高的JPEG格式文件，其大小是22KB。在本例中，PNG比JPEG文件大3倍多。

如果是本地資源文件，這樣的差別不是很大，但如果是分布在網(wǎng)絡云服務器中的資源文件，應用在加載這些圖片時，會從網(wǎng)絡上下載到本地，這時候JPEG就很有優(yōu)勢了。

綜上所述，如果在本地資源的情況下，我們應該優(yōu)先使用PNG格式文件，如果資源來源于網(wǎng)絡，最好采用JPEG格式文件。

另外，圖片是一種很特殊的資源文件。創(chuàng)建UIImage對象時，可以使用靜態(tài)工廠方法+imageNamed:和實例構(gòu)造器-initWithContentsOfFile:。+imageNamed:方法會在內(nèi)存中建立緩存，這些緩存直到應用停止才清除。如果是貫穿整個應用的圖片(如圖標、logo等)，推薦使用+imageNamed:創(chuàng)建。如果是僅使用一次的圖片，推薦使用實例構(gòu)造器-initWithContentsOfFile:創(chuàng)建。

2.音頻文件優(yōu)化

在討論音頻文件優(yōu)化之前，我們先討論一下音頻文件格式。在iOS平臺中，主要的音頻文件格式有以下4種。

WAV文件。WAV是一種由微軟和IBM聯(lián)合開發(fā)的用于音頻數(shù)字存儲的文件格式。WAV文件的格式靈活，

可以存儲多種類型的音頻數(shù)據(jù)。由于文件較大，不太適合于移動設備這些存儲容量小的設備。

MP3(MPEG Audio Layer 3)文件。MP3利用MPEG Audio Layer 3技術，將數(shù)據(jù)以1∶10甚至1∶12的縮率壓縮成容量較小的文件。MP3是一種有損壓縮格式，它 盡可能地去掉人耳無法感覺的部分和不敏感的部分。這么高的壓縮比率非常適合于移動設備這些存儲容量小的設備，現(xiàn)在非常流行。

CAFF(Core Audio File Format)文件。CAFF是蘋果開發(fā)的專門用于Mac OS X和iOS系統(tǒng)的無壓縮音頻格式，它被設計用來替換老的WAV格式。

AIFF(Audio Interchange File Format)文件。AIFF是蘋果開發(fā)的專門用于Mac OS X系統(tǒng)的專業(yè)的音頻文件格式。AIFF的壓縮格式是AIFF-C(或AIFC)，將數(shù)據(jù)以4∶1壓縮率進行壓縮，應用于Mac OS X和iOS系統(tǒng)。

音頻文件優(yōu)化包括了文件格式和文件大小的優(yōu)化，但也要考慮到文件使用場景、采用的技術(OpenAL、AVAudioPlayer)等因素。在iOS應用中，使用本地音頻資源文件的主要應用場景是背景音樂和音樂特效，下面我們從這兩個方面介紹相關的優(yōu)化技術。

(1)背景音樂優(yōu)化

背景音樂會在應用中反復播放，它會一直駐留在內(nèi)存中并耗費CPU，所以更合適比較小的文件，而壓縮文件是不錯的選擇。壓縮文件主要有AIFC和MP3兩種格式，一般我們首選AIFC，因為這是蘋果推薦的格式。但是我們獲得的原始文件格式不一定是AIFC，這種情況下我們需要使用afconvert工具將其轉(zhuǎn)換為AIFC格式。在終端中執(zhí)行如下命令：

$ afconvert -f AIFC -d ima4 Fx08822_cast.wav

其中-f AIFC參數(shù)用于轉(zhuǎn)換為AIFC格式，-d ima4參數(shù)指定解碼方式，F(xiàn)x08822_cast.wav是要轉(zhuǎn)換的源文件。轉(zhuǎn)換成功后，會在相同目錄下生成Fx08822_cast.aifc文件。本例中的源文件Fx08822_cast.wav的大小是295KB，轉(zhuǎn)換之后的Fx08822_cast.aifc文件的大小是82KB。當然，afconvert工具也可以轉(zhuǎn)換MP3等其他壓縮格式文件。如果我們同時有WAV文件，就應該優(yōu)先采用WAV文件。MP3本身是有損壓縮，如果再經(jīng)過afconvert轉(zhuǎn)換，音頻的質(zhì)量會受到影響。

(2)音樂特效優(yōu)化

音樂特效用于很多游戲中，如發(fā)射子彈、敵人被打死或按鈕點擊等發(fā)出的聲音，這些聲音都是比較短的。如果追求震撼的3D效果，可以采用蘋果專用的無壓縮CAFF格式文件，其他格式的文件盡量不要考慮。一般不要使用壓縮音頻文件，這主要是因為音樂特效通常采用OpenAL技術，它只接受無壓縮的音頻文件。另外，壓縮音頻文件都會造成音質(zhì)的丟失。如果我們沒有CAFF格式的文件，也可以使用afconvert工具將其轉(zhuǎn)換為CAFF格式。在終端中執(zhí)行如下命令：

$ afconvert -f caff -d LEI16 Fx08822_cast.wav

其中-f caff參數(shù)用于轉(zhuǎn)換為CAFF格式，-d LEI16參數(shù)指定解碼方式，F(xiàn)x08822_cast.wav是要轉(zhuǎn)換的源文件。默認音頻的采樣頻率為22050Hz，如果想提高音頻采樣頻率，可以通過如下命令：

$ afconvert -f caff -d LEI16@44100 Fx08822_cast.wav

其中-d LEI16@44100參數(shù)中的44100表示音頻采用頻率44100Hz。

如果我們采用的資源文件不在本地，而是在分布在網(wǎng)絡云服務器中，那么情況就另當別論了。應用在加載這些音頻文件時，帶寬往往是要考慮的問題，減小文件大小勝過對音質(zhì)的要求，這種情況下MP3格式是非常適合的。

綜上所述，音頻文件在使用本地資源的情況下，應用于背景音樂時AIFC格式是首選，應用于音樂特效時CAFF格式是首選。如果是資源來源于網(wǎng)絡，最好采用MP3格式文件。

3.延遲加載

延遲加載(lazy load)指一些對象不是在應用和視圖等初始化時創(chuàng)建，而是在用到它的時候創(chuàng)建。當應用中有一些對象并不經(jīng)常使用時，延遲加載可以提高程序性能。

3.1 資源文件的延遲加載

首先，我們要考慮的就是對資源文件的延遲加載。由于資源文件的訪問涉及IO操作，這本身就會耗費一定的CPU時間，如果文件比較大而且加載時機又不合適，就會造成內(nèi)存浪費。前面我們了解到資源文件包括圖片、音頻和文本文件等，無論是什么類型的文件，有些情況下采用延遲加載是很有必要的。例如，我們有如圖5所示的需求，可以使用分屏件(UIPageControl)左右滑動屏幕來瀏覽這3張圖片。

5 圖片延遲加載實例

PageControlNavigation實例是沒有采用延遲加載的實現(xiàn)代碼，其中的ViewController代碼如下：

我們是在viewDidLoad方法中一次加載全部3張圖片，但是有的時候用戶不一定會瀏覽后面的圖片，他可能只看到第一張或第二張，后面的第三張沒有去看，此時后面的兩張圖片仍然加載內(nèi)存的話，會造成內(nèi)存浪費。采用延遲加載實現(xiàn)時(見實例LazyLoadPageControlNavigation)，ViewController的代碼如下：

我們重新修改了這個實例，在viewDidLoad方法中只加載第一張圖片，見第①行代碼。如果用戶滑動屏幕或點擊分屏控件進入第二個屏幕，則調(diào)用loadImage：方法加載第二張圖片，類似地，如果要進入第三個屏幕，則調(diào)用loadImage：方法加載第三張圖片。

在這兩種實現(xiàn)方式中，LazyLoadPageControlNavigation實現(xiàn)了延遲加載。很顯然，LazyLoadPageControlNavigation的延遲加載友好很多。那么，兩者究竟有多大的差別，這是可以量化的。通過Instruments工具的Allocations模板，可以分析ViewController視圖控制器加載時內(nèi)存占用方面的差別。圖6是無延遲加載實現(xiàn)案例的Allocations模板跟蹤，圖7是采用延遲加載實現(xiàn)案例的Allocations模板跟蹤。

如圖6所示，界面啟動用時，內(nèi)存占用馬上達到8.12MB。如圖7所示，界面啟動用時，內(nèi)存占用3.08MB，當我們滑動到第二和第三屏幕時，內(nèi)存占用達到8.06MB，內(nèi)存變化會有明顯的兩個階梯。

圖6 無延遲加載實現(xiàn)案例的Allocations模板跟蹤

圖7 使用延遲加載實現(xiàn)案例的Allocations模板跟蹤

在上面的案例中可以發(fā)現(xiàn)，延遲加載的優(yōu)勢很明顯。如果一定會訪問到資源文件，則延遲加載這些資源文件時，內(nèi)存占用方面就沒有優(yōu)勢了，但是在界面加載速度方面還是有優(yōu)勢的。

3.2 故事板文件的延遲加載

xib和故事板也都屬于資源文件，它是非常特殊的資源文件，應用不僅需要讀取它，而且要根據(jù)里面描述的信息創(chuàng)建視圖和子視圖，以及它們的視圖控制器等對象。創(chuàng)建這么多對象會耗費很多時間，占用很多內(nèi)存，因此，它們的延遲加載問題非常重要。

默認情況下，創(chuàng)建基于故事板的應用時，只有一個故事板文件。這種情況下，故事板內(nèi)部的視圖控制器的創(chuàng)建和加載都是由Segue來控制的，Segue會幫助我們管理好這些控制器，包括延遲加載等問題。

我們創(chuàng)建一個實用型應用程序①，研究故事板的延遲加載機理。實用型應用一般會有兩個視圖：主視圖，它顯示應用的主要功能;子視圖，它用來對應用進行一些設置。我們自己創(chuàng)建一個實用型應用，如圖8所示。

圖8 實用型應用

在Xcode 5之前可以使用Utility Application模板創(chuàng)建，Xcode 6之后就沒有這個模板了，我們可以通過SingleView Application模板創(chuàng)建StoryboardLazyLoadDemo工程。

在主視圖中點擊 按鈕，MainViewController會延遲加載FlipsideViewController，然后彈出模態(tài)模式。使用模態(tài)Segue連接MainViewController和FlipsideViewController，如圖9所示，我們基本上不需要編寫什么代碼。

圖9 模態(tài)視圖的Segue

Segue定義了兩個視圖控制器的導航關系，也用來維護和管理下一個視圖控制器的延遲加載時機，這種情況下我們無法“插手”視圖控制器的延遲加載。但是一種情況除外，那就是使用了故事板，而控制器之間沒有定義導航關系，沒有定義Segue，如圖10所示。

圖10 沒有定義Segue的故事板

這種情況下，添加showInfo:方法響應主視圖的 按鈕點擊事件，具體可參考StoryboardLazyLoadNoSegueDemo工程的MainViewController，相關代碼如下：

在單一故事板文件中，第①行代碼可以獲得當前的故事板對象。如果想在多故事板的情況下獲得非當前故事板對象，可以通過第②行代碼的UIStoryboard構(gòu)造器創(chuàng)建。本例中不用使用該語句，使用它會多創(chuàng)建一個故事板對象，就會占用更多的內(nèi)存。

3.3 xib 文件的延遲加載

相對于故事板而言，xib要靈活很多。xib文件有兩種：一種是描述視圖控制器的，另一種是描述視圖的，它們的加載方式有所區(qū)別。無論是哪一種，分散管理的xib文件使我們通過編程方式訪問它更加方便。

Xcode 6不能創(chuàng)建基于xib文件的工程了，我們通過Single View Application模板創(chuàng)建NibLazyLoadDemo工程，然后刪除主故事板文件。接著我們創(chuàng)建視圖控制器，如圖11所示，一定要選擇Also create XIB file復選框，這會幫助我們創(chuàng)建與視圖控制器對應的xib文件。

圖11 創(chuàng)建視圖控制器

創(chuàng)建好視圖控制器后，我們需要修改AppDelegate使應用啟動時能夠加載MainViewController。AppDelegate的主要代碼如下：

上述代碼中，第①~③行是我們添加的代碼，第①行代碼用于創(chuàng)建Window對象，在xib構(gòu)建的視圖中必須放到一個Window中，第②行代碼通過xib文件創(chuàng)建視圖控制器對象，然后再把視圖控制器添加到Window對象中。主視圖控制器MainViewController中showInfo:方法的代碼如下：

本例中的xib文件是視圖控制器xib文件，我們可以使用視圖控制器的initWithNibName:bundle:構(gòu)造器從xib文件中創(chuàng)建視圖控制器對象。

有些情況下，故事板和xib會混合使用。在有故事板的工程中，有時候需要使用別人已經(jīng)編寫好的xib文件和對應類(視圖或視圖控制器)。當然，通過上面的兩種方式也是可以的。

4.數(shù)據(jù)持久化的優(yōu)化

在iOS中，數(shù)據(jù)持久化的載體主要有文件、SQLite數(shù)據(jù)庫和Core Data。本節(jié)中，我們就從這幾個方面入手討論數(shù)據(jù)持久化的優(yōu)化問題。

4.1 使用文件

文件是數(shù)據(jù)持久化的重要載體。文件優(yōu)化可以包括很多方面，下面我們從文件訪問、文件結(jié)構(gòu)和文件大小這3個方面來介紹。

(1)文件訪問優(yōu)化

避免多次寫入很少的數(shù)據(jù)，最好是當數(shù)據(jù)積攢到一定數(shù)量時一次寫入。因為文件訪問涉及IO操作，我們知道頻繁的IO操作會影響性能，所以最好將文件讀寫訪問從主線程中剝離出來，由一個子線程負責。另外，過于頻繁地寫入數(shù)據(jù)會影響設備中閃存的壽命。

文件的寫入應該采用增量方式，每次只寫入變化的部分，不要為改變幾個字節(jié)寫入整個文件。這樣就要求不能采用簡單的屬性列表對象寫入方式。這是一個很復雜的問題，文件內(nèi)容的變化可以是追加、刪除和修改。文件追加很容易實現(xiàn)，刪除就比較麻煩了，需要找到要刪除的數(shù)據(jù)，這樣訪問文件就采用隨機訪問方式了。修改與刪除的問題是一樣的。與其這么麻煩，不如采用別的持久化技術了。

(2)文件結(jié)構(gòu)優(yōu)化

文件要保存數(shù)據(jù)，它就應該是結(jié)構(gòu)化的。蘋果中的.plist文件就是很好的結(jié)構(gòu)化文件，其結(jié)構(gòu)是層次模型的樹形結(jié)構(gòu)，層次的深淺會影響讀取/寫入的速度。在能夠滿足用戶需求的情況下，要減少層次深度。下面是一個世界杯足球賽部分小組信息的屬性列表文件team(5層次).plist：

該文件有5個層次，具體如圖12所示，其中第一層是數(shù)組類型集合;第二層是字典集合，其中描述了小組名和小組中的球隊列表;第三層是數(shù)組類型集合，描述了小組中的球隊列表;第四層是字典集合;第五層是字符串，描述了球隊名和球隊圖標信息。

圖12 5個層次的team.plist文件

這個文件訪問起來很不方便，遍歷起來也很不方便，也很影響性能。我們重新設計了這個屬性列表文件，其內(nèi)容如下：

此時這個文件有3個層次，其中第一層是數(shù)組類型集合，第二層是字典集合，第三層是字符串，描述了球隊名和球隊圖標信息，如圖13所示。

圖13 3層次的team.plist文件

與上面的5層次文件相比，3層次訪問起來比較方便，性能會比較好。此外，在文件大小方面，3層次文件是647KB，5層次文件是893KB。

(3)文件大小優(yōu)化

文件大小也是優(yōu)化的一個重要指標。從上面的比較可以看到，調(diào)整文件結(jié)構(gòu)可以減少文件大小。此外，我們也可以通過序列化.plist文件減少文件大小。 Foundation框架提供了NSPropertyListSerialization類，它就是為此而設計的。NSPropertyListSerialization類中有2個常用方法，具體如下所示。

+ dataWithPropertyList:format:options:error:。按照指定的格式和操作參數(shù)，序列化屬性列表對象到NSData對象。

+ propertyListWithData:options:format:error:。按照指定的格式和操作參數(shù)，從NSData對象反序列化到屬性列表對象中。

為了介紹NSPropertyListSerialization類，現(xiàn)在我們換成序列化二進制文件NotesList.binary。下面我們修改數(shù)據(jù)持久層工程PersistenceLayer中的NoteDAO類，首先，添加如下兩個方法：

在上述代碼中，readFromArray:方法從文件中讀取數(shù)據(jù)到NSMutableArray，其流程是讀取文件到NSMutableData對象，然后再從NSMutableData對象中反序列化處理屬性列表對象。本例中的屬性列表對象是NSMutableArray類型，其中第①行代碼用于處理這一過程。propertyListWithData后面的參數(shù)是反序列化的數(shù)據(jù)來源，它是NSData類型。options后面的參數(shù)是NSPropertyListReadOptions。在Swift版本中，使用表達式NSPropertyListReadOptions-(NSPropertyListMutabilityOptions.MutableContainers.rawValue)，Objective-C版本是NSPropertyListMutableContainersAndLeaves。NSPropertyListMutabilityOptions是枚舉類型，其成員值如下。

Immutable。屬性列表包含不可變對象。Objective-C版本為NSPropertyListImmutable。

MutableContainers。屬性列表父節(jié)點是可變類型，子節(jié)點是不可變類型。Objective-C版本為NSPropertyListMutableContainers。

MutableContainersAndLeaves。屬性列表父節(jié)點和子節(jié)點都是可變類型。Objective-C版本為NSPropertyListMutableContainersAndLeaves。

另外，在第①行代碼中，format參數(shù)為nil(或NULL)，說明格式是自動識別的。

南昌網(wǎng)絡公司小編提示：屬性列表對象是與屬性列表文件結(jié)構(gòu)對應的，它可以是NSData、NSString、NSArray和NSDictionary類型以及它們的可變類型。此外，還可以是NSDate和NSNumber類型。

write:toFilePath:方法把NSMutableArray數(shù)據(jù)序列化后寫入到文件中，流程是先序列化NSMutableArray數(shù)據(jù)到 NSData 對象中，然后在把 NSData 對象寫入到文件中。第②行代碼就是完成序列化處理的，+dataWithPropertyList:format:options:error:方法中array參數(shù)是要序列化的屬性列表對象，format參數(shù)是NSPropertyListFormat枚舉類型。NSPropertyListFormat枚舉類型包含的常量有如下幾個。

XMLFormat_v1_0。指定屬性列表文件格式是XML格式，仍然是純文本類型，不會壓縮文件。Objective-C版本為NSPropertyListXMLFormat_v1_0。

BinaryFormat_v1_0。指定屬性列表文件格式為二進制格式，文件是二進制類型，會壓縮文件。Objective-C版本為NSPropertyListBinaryFormat_v1_0。

OpenStepFormat。指定屬性列表文件格式為ASCII碼格式，對于舊格式的屬性列表文件，不支持寫入操作。

Objective-C版本為NSPropertyListOpenStepFormat。

本例中，我們設置的是BinaryFormat_v1_0，大小減少了，加載速度提高了，這樣就達到了優(yōu)化的效果。

4.2 使用 SQLite 數(shù)據(jù)庫

當需要處理較大的數(shù)據(jù)集合時，就不能采用文件了。因為文件不支持事務處理，這時候我們可以選擇SQLite數(shù)據(jù)庫或Core Data。本節(jié)中，我們先從表結(jié)構(gòu)、查詢和插入(或刪除)這幾個方面介紹一下SQLite數(shù)據(jù)庫方面的優(yōu)化。

(1)表結(jié)構(gòu)優(yōu)化

SQLite是嵌入式關系型數(shù)據(jù)，它可以建立多表之間復雜的關系，但是如果放在iOS、Android等這些移動設備上時，我們需要考慮設備上本地表能建多少，表中字段有多少，表之間關系的復雜程度等問題。

在CPU處理能力低、內(nèi)存少、存儲空間少的情況下，我們不能在本地建立復雜表關系，表的個數(shù)不要超過5個，表中的字段數(shù)也不宜太多。移動設備中的數(shù)據(jù)不可能是企業(yè)級系統(tǒng)數(shù)據(jù)的全部，它只是企業(yè)級系統(tǒng)的補充和擴展。例如，在你的iPhone手機中，不可能有全部的新浪微博用戶信息，一方面是不安全，另一方面是數(shù)據(jù)量很大，最高配置的iPhone也不可能存放下這么多數(shù)據(jù)。這是我們在開發(fā)移動應用時始終要牢記的：移動設備在整個應用系統(tǒng)中的角色是什么?

(2)查詢優(yōu)化

查詢是衡量數(shù)據(jù)庫性能的重要指標之一。在查詢方面可優(yōu)化的有很多，例如建立索引、限制返回記錄數(shù)和where條件子句等。

使用索引，能夠提高查詢的性能。具體哪些字段需要創(chuàng)建索引，這很關鍵。只有在表連接或where條件子句中使用字段時，才能提高查詢性能。在INTEGER PRIMARY KEY字段上，一般不用建索引。如果表中的數(shù)據(jù)很少，則建索引的效果不大。

由于移動設備屏幕相對來說比較小，屏幕上能顯示的數(shù)據(jù)不多，如果一次查詢出的記錄數(shù)超過屏幕能顯示的行數(shù)，這就沒有必要了，因為這樣反而會占用更多的內(nèi)存，耗費寶貴的CPU時間。因此，我們需要為查詢添加返回記錄數(shù)的限制。下面的語句是SQLite支持的寫法：

SELECT * FROM Note Limit 10 Offset 5;

以上語句表示從Note表查詢數(shù)據(jù)出來，其中10表示查詢的最大記錄數(shù)不超過10個，5表示偏移量，即跳過5行取10個。

在where條件子句的優(yōu)化方面，就有更多優(yōu)化方式了。比如，盡量不要使用LIKE模糊匹配查詢，如果可能，則使用=查詢;盡量不要使用IN語句，可以使用=和or替代。此外，在多個條件中，要把非文本的條件放在前面，文本條件放在后面，示例代碼如下：

(salary > 5000000) AND (lastName LIKE 'Guan') 優(yōu)于 (lastName LIKE 'Guan') AND (salary > 5000000)

這是因為非文本的條件判斷比較快，如果不滿足，就不用再計算后面的條件表達式了。

(3)插入(或刪除)優(yōu)化

索引可以提供查詢性能，但是對于插入和刪除是有負面影響的。索引就像是書中的目錄，插入和刪除數(shù)據(jù)必然造成索引重排，所以創(chuàng)建索引要慎重。

在SQLite中，有一些PRAGMA指令可以改變數(shù)據(jù)庫的行為。PRAGMA synchronous指令用于設置數(shù)據(jù)同步操作。同步是指在插入數(shù)據(jù)時，將數(shù)據(jù)同時保存到存儲介質(zhì)中。如果PRAGMA synchronous = OFF，則表示關閉了數(shù)據(jù)同步，不等待數(shù)據(jù)保存到存儲介質(zhì)就可繼續(xù)執(zhí)行插入操作，這在大量數(shù)據(jù)插入時可以大大提高速度。在Objective-C中，可以調(diào)用sqlite3_exec函數(shù)設置數(shù)據(jù)是否同步，相關語句如下：

sqlite3_open(DATABASE, &db)

sqlite3_exec(db, "PRAGMA synchronous = OFF", nil, nil, nil)

插入完成后，也可以重新設置PRAGMA synchronous = NORMAL或PRAGMA synchronous = FULL。

4.3 使用 Core Data

Core Data是面向?qū)ο蟮腛RM技術，蘋果公司推薦使用。它提供了緩沖、延遲加載等技術，其性能比較好，但有時候我們會發(fā)現(xiàn)它的性能要比SQLite差，這主要與存儲類型的設置有關。Core Data的存儲類型有NSSQLiteStoreType、NSBinaryStoreType和NSInMemoryStoreType，我們主要采用NSSQLiteStoreType類型，這樣底層存儲就采用了SQLite數(shù)據(jù)庫，SQLite數(shù)據(jù)庫的優(yōu)點也能發(fā)揮出來。

使用Core Data時，還要考慮查詢優(yōu)化問題。它的查詢是通過NSFetchRequest執(zhí)行Predicate定義的邏輯查詢條件實現(xiàn)的，在優(yōu)化規(guī)則上與SQLite的where條件子句是一樣的。此外，如果要查詢返回記錄數(shù)的限制，可以使用如下語句：

這兩條語句相當于SELECT * FROM Note Limit 10 Offset 5;。

此外，還可以設置pragma指令，相關語句如下：

在上述代碼中，我們首先把這些pragma指令放置于NSMutableDictionary可變字典中，然后以NSSQLitePragmasOption為鍵再把指令設置到可變字典中。NSPersistentStore對象的addPersistentStoreWithType:configuration:URL:

options:error:方法的options參數(shù)用于接收設置的NSDictionary對象。

為了方便分析Core Data的執(zhí)行情況，我們可以使用Instruments工具中的Core Data跟蹤模板，如圖14所示。

圖14 選擇Core Data跟蹤模板

進入Core Data跟蹤模板后，如圖15所示，可以看到其內(nèi)部有3個跟蹤項目：Core Data Fetches、Core DataCache和Core Data Saves。

圖15 Core Data跟蹤模板

當我們執(zhí)行查詢、插入和刪除操作時，在Core Data Fetches和Core Data Saves的跟蹤項目右邊會產(chǎn)生很多線。

其中，①部分的線段為Fetch count(查詢的記錄數(shù)據(jù));②部分的線段為Fetch duration(執(zhí)行查詢的持續(xù)時間)，將虛線拉到上面可以看到這些內(nèi)容的具體數(shù)值;如果有數(shù)據(jù)要保存，③部分產(chǎn)生的線段為Save duration(保存所持續(xù)的時間);④部分是更具體的信息，F(xiàn)etch entity列是查詢的實體類(Note)，F(xiàn)etch count列是查詢的記錄數(shù)，F(xiàn)etch duration列是查詢的執(zhí)行時間。

了解更多相關資訊，關注南昌網(wǎng)絡公司--百恒網(wǎng)絡官方網(wǎng)站。百恒網(wǎng)絡是一家專業(yè)從事南昌網(wǎng)站建設、微信開發(fā)、APP開發(fā)、網(wǎng)絡營銷等服務的南昌網(wǎng)絡公司，技術過硬，經(jīng)驗豐富。如有任何網(wǎng)站方面的問題，百恒網(wǎng)絡隨時歡迎大家來電咨詢，我們專業(yè)為您解答!