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

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

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

圖1 資源文件

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

1.圖片文件優化

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

圖2 設定編譯參數Compress PNG Files

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

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

圖3 未優化的PNG文件屬性

圖4 優化的PNG文件屬性

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

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

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

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

2.音頻文件優化

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

WAV文件。WAV是一種由微軟和IBM聯合開發的用于音頻數字存儲的文件格式。WAV文件的格式靈活，

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

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

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

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

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

(1)背景音樂優化

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

$ afconvert -f AIFC -d ima4 Fx08822_cast.wav

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

(2)音樂特效優化

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

$ afconvert -f caff -d LEI16 Fx08822_cast.wav

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

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

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

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

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

3.延遲加載

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

3.1 資源文件的延遲加載

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

5 圖片延遲加載實例

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

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

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

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

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

圖6 無延遲加載實現案例的Allocations模板跟蹤

圖7 使用延遲加載實現案例的Allocations模板跟蹤

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

3.2 故事板文件的延遲加載

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

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

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

圖8 實用型應用

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

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

圖9 模態視圖的Segue

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

圖10 沒有定義Segue的故事板

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

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

3.3 xib 文件的延遲加載

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

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

圖11 創建視圖控制器

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

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

本例中的xib文件是視圖控制器xib文件，我們可以使用視圖控制器的initWithNibName:bundle:構造器從xib文件中創建視圖控制器對象。

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

4.數據持久化的優化

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

4.1 使用文件

文件是數據持久化的重要載體。文件優化可以包括很多方面，下面我們從文件訪問、文件結構和文件大小這3個方面來介紹。

(1)文件訪問優化

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

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

(2)文件結構優化

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

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

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

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

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

圖13 3層次的team.plist文件

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

(3)文件大小優化

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

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

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

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

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

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

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

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

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

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

write:toFilePath:方法把NSMutableArray數據序列化后寫入到文件中，流程是先序列化NSMutableArray數據到 NSData 對象中，然后在把 NSData 對象寫入到文件中。第②行代碼就是完成序列化處理的，+dataWithPropertyList:format:options:error:方法中array參數是要序列化的屬性列表對象，format參數是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，大小減少了，加載速度提高了，這樣就達到了優化的效果。

4.2 使用 SQLite 數據庫

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

(1)表結構優化

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

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

(2)查詢優化

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

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

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

SELECT * FROM Note Limit 10 Offset 5;

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

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

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

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

(3)插入(或刪除)優化

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

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

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是面向對象的ORM技術，蘋果公司推薦使用。它提供了緩沖、延遲加載等技術，其性能比較好，但有時候我們會發現它的性能要比SQLite差，這主要與存儲類型的設置有關。Core Data的存儲類型有NSSQLiteStoreType、NSBinaryStoreType和NSInMemoryStoreType，我們主要采用NSSQLiteStoreType類型，這樣底層存儲就采用了SQLite數據庫，SQLite數據庫的優點也能發揮出來。

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

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

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

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

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

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

圖14 選擇Core Data跟蹤模板

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

圖15 Core Data跟蹤模板

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

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

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