iOS-常用框架解讀

讀取流程

創(chuàng)新互聯(lián)公司-云計算及IDC服務(wù)提供商，涵蓋公有云、IDC機房租用、綿陽服務(wù)器托管、等保安全、私有云建設(shè)等企業(yè)級互聯(lián)網(wǎng)基礎(chǔ)服務(wù)，歡迎咨詢：18982081108

磁盤讀取后或者網(wǎng)絡(luò)請求后。

記錄器 基于不同的場景提供關(guān)于記錄的封裝、適配。一般分為頁面式，流式，自定義式。

記錄管理者 管理統(tǒng)計記錄數(shù)據(jù)，包含記錄緩存，磁盤存儲，上傳器。

如何降低數(shù)據(jù)的丟失率？ 兩種解決方案：

記錄上傳的時機

上傳時機的選擇

從三個方面分析架構(gòu)設(shè)計：整體架構(gòu)、數(shù)據(jù)流、反向更新。

View 的功能包含：控件的初始化、設(shè)置數(shù)據(jù)、交互事件代理等。 ViewController 的功能：視圖創(chuàng)建與組合、協(xié)調(diào)邏輯、事件回調(diào)處理等，事件回調(diào)處理指的是視圖層的事件。

業(yè)務(wù)邏輯處理（預(yù)排版）、數(shù)據(jù)增刪改查封裝者、線程安全處理（保證數(shù)據(jù)刷新和用戶手動更新數(shù)據(jù)的數(shù)據(jù)同步）。

網(wǎng)絡(luò)請求、數(shù)據(jù)解析、增刪改查、本地處理邏輯（適配）

數(shù)據(jù)流包含：網(wǎng)絡(luò)數(shù)據(jù)、業(yè)務(wù)數(shù)據(jù)、UI數(shù)據(jù)三部分。 網(wǎng)絡(luò)數(shù)據(jù)經(jīng)過 Engine 層處理加工產(chǎn)生業(yè)務(wù)數(shù)據(jù)，業(yè)務(wù)數(shù)據(jù)經(jīng)過 ViewModel 層處理產(chǎn)生UI數(shù)據(jù)，UI數(shù)據(jù)會轉(zhuǎn)交給視圖控制器控制視圖的顯示。

業(yè)務(wù)數(shù)據(jù)強引用網(wǎng)絡(luò)數(shù)據(jù)和UI數(shù)據(jù)，同時UI數(shù)據(jù)通過弱引用找到業(yè)務(wù)數(shù)據(jù)。

用戶交互網(wǎng)絡(luò)刷新等都會導(dǎo)致視圖層變化，通過代理方式通知視圖控制器?？刂破鲗iewModel的強引用找到對應(yīng)ViewModel，然后通過UI數(shù)據(jù)對業(yè)務(wù)數(shù)據(jù)的弱引用找到對應(yīng)的業(yè)務(wù)數(shù)據(jù)同時打上臟標記（借鑒系統(tǒng)UIView更新機制的思想）。最后ViewModel進行數(shù)據(jù)流的重新驅(qū)動，將臟數(shù)據(jù)重新處理生成新的UI數(shù)據(jù)更新視圖。

四、iOS中圖形圖像渲染技術(shù)棧及流水線

下圖為 iOS APP 圖形渲染框架， APP 在顯示可視化的圖形時，使用到了 Core Animation 、 Core Graphics 、 Core Image 等框架，這些框架在渲染圖形時，都需要通過 OpenGL ES / Metal 來驅(qū)動 GPU 進行渲染與繪制。

UIKit 是 iOS 開發(fā)者最常用的框架，里面提供了 UIView 。

UIView 供開發(fā)者用來:

Core Animation 源自于 Layer Kit, 是一個復(fù)合引擎,主要職責包含渲染（ CALayer ）、構(gòu)建和實現(xiàn)動畫。 CALayer 是用戶所能在屏幕上看到一切的基礎(chǔ)。

Core Graphics 是基于Quartz 的高級繪圖引擎，主要用于運行時繪制圖像。其功能有繪制路徑、顏色管理、漸變、陰影、創(chuàng)建圖像、圖像遮罩、PDF文檔創(chuàng)建顯示及分析。

Core Image 擁有一系列現(xiàn)成的圖像過濾器，可以對已存在的圖片進行高效處理。大部分情況下，``Core Image ``` 是在GPU中完成工作，如果GPU忙，會使用CPU進行處理。

Core Animation 、 Core Graphics 、 Core Image 這個三個框架間也存在著依賴關(guān)系。

上面提到 CALayer 是用戶所能在屏幕上看到一切的基礎(chǔ)。所以 Core Graphics 、 Core Image 是需要依賴于 CALayer 來顯示界面的。由于 CALayer 又是 Core Animation 框架提供的，所以說 Core Graphics 、 Core Image 是依賴于``Core Animation ```的。

上文還提到每一個 UIView 內(nèi)部都關(guān)聯(lián)一個 CALayer 圖層，即 backing layer ，每一個 CALayer 都包含一個 content 屬性指向一塊緩存區(qū)，即 backing store ， 里面存放位圖（Bitmap）。 iOS 中將該緩存區(qū)保存的圖片稱為 寄宿圖 。

這個寄宿圖有兩個設(shè)置方式：

CALayer 是如何調(diào)用 GPU 并顯示可視化內(nèi)容的呢？下面我們就需要介紹一下 Core Animation 流水線的工作原理。

事實上，app 本身并不負責渲染，渲染則是由一個獨立的進程負責，即 Render Server 進程。

App 通過 IPC 將渲染任務(wù)及相關(guān)數(shù)據(jù)提交給 Render Server 。 Render Server 處理完數(shù)據(jù)后，再傳遞至 GPU。最后由 GPU 調(diào)用 iOS 的圖像設(shè)備進行顯示。

Core Animation 流水線的詳細過程如下：

對上述步驟進行串聯(lián)，它們執(zhí)行所消耗的時間遠遠超過 16.67 ms，因此為了滿足對屏幕的 60 FPS 刷新率的支持，需要將這些步驟進行分解，通過流水線的方式進行并行執(zhí)行，如下圖所示。

在 Core Animation 流水線中，app 調(diào)用 Render Server 前的最后一步 Commit Transaction 其實可以細分為 4 個步驟：

參考文章： iOS 圖像渲染原理

剛剛，阿里開源 iOS 協(xié)程開發(fā)框架 coobjc！

阿里妹導(dǎo)讀：剛剛，阿里巴巴正式對外開源了基于 Apache 2.0 協(xié)議的協(xié)程開發(fā)框架 coobjc，開發(fā)者們可以在 Github 上自主下載。

coobjc是為iOS平臺打造的開源協(xié)程開發(fā)框架，支持Objective-C和Swift，同時提供了cokit庫為Foundation和UIKit中的部分API提供了 協(xié)程 化支持，本文將為大家詳細介紹coobjc的設(shè)計理念及核心優(yōu)勢。

從2008年第一個iOS版本發(fā)布至今的11年時間里，iOS的異步編程方式發(fā)展緩慢。

基于 Block 的異步編程回調(diào)是目前 iOS 使用最廣泛的異步編程方式，iOS 系統(tǒng)提供的 GCD 庫讓異步開發(fā)變得很簡單方便，但是基于這種編程方式的缺點也有很多，主要有以下幾點：

針對多線程以及尤其引發(fā)的各種崩潰和性能問題，我們制定了很多編程規(guī)范、進行了各種新人培訓，嘗試降低問題發(fā)生的概率，但是問題依然很嚴峻，多線程引發(fā)的問題占比并沒有明顯的下降，異步編程本來就是很復(fù)雜的事情，單靠規(guī)范和培訓是難以從根本上解決問題的，需要有更加好的編程方式來解決。

上述問題在很多系統(tǒng)和語言開發(fā)中都可能會碰到，解決問題的標準方式就是使用協(xié)程，C#、Kotlin、Python、Javascript 等熱門語言均支持協(xié)程極其相關(guān)語法，使用這些語言的開發(fā)者可以很方便的使用協(xié)程及相關(guān)功能進行異步編程。

2017 年的 C++ 標準開始支持協(xié)程，Swift5 中也包含了協(xié)程相關(guān)的標準，從現(xiàn)在的發(fā)展趨勢看基于協(xié)程的全新的異步編程方式，是我們解決現(xiàn)有異步編程問題的有效的方式，但是蘋果基本已經(jīng)不會升級 Objective-C 了，因此使用Objective-C的開發(fā)者是無法使用官方的協(xié)程能力的，而最新 Swift 的發(fā)布和推廣也還需要時日，為了讓廣大iOS開發(fā)者能快速享受到協(xié)程帶來的編程方式上的改變，手機淘寶架構(gòu)團隊基于長期對系統(tǒng)底層庫和匯編的研究，通過匯編和C語言實現(xiàn)了支持 Objective-C 和 Swift 協(xié)程的完美解決方案 —— coobjc。

核心能力

內(nèi)置系統(tǒng)擴展庫

coobjc設(shè)計

最底層是協(xié)程內(nèi)核，包含了棧切換的管理、協(xié)程調(diào)度器的實現(xiàn)、協(xié)程間通信channel的實現(xiàn)等。

中間層是基于協(xié)程的操作符的包裝，目前支持async/await、Generator、Actor等編程模型。

最上層是對系統(tǒng)庫的協(xié)程化擴展，目前基本上覆蓋了Foundation和UIKit的所有IO和耗時方法。

核心實現(xiàn)原理

協(xié)程的核心思想是控制調(diào)用棧的主動讓出和恢復(fù)。一般的協(xié)程實現(xiàn)都會提供兩個重要的操作：

我們基于線程的代碼執(zhí)行時候，是沒法做出暫停操作的，我們現(xiàn)在要做的事情就是要代碼執(zhí)行能夠暫停，還能夠再恢復(fù)。 基本上代碼執(zhí)行都是一種基于調(diào)用棧的模型，所以如果我們能把當前調(diào)用棧上的狀態(tài)都保存下來，然后再能從緩存中恢復(fù)，那我們就能夠?qū)崿F(xiàn)yield和 resume。

實現(xiàn)這樣操作有幾種方法呢？

上述第三種和第四種只是能過做到跳轉(zhuǎn)，但是沒法保存調(diào)用棧上的狀態(tài)，看起來基本上不能算是實現(xiàn)了協(xié)程，只能算做做demo，第五種除非官方支持，否則自行改寫編譯器通用性很差。而第一種方案的 ucontext 在iOS上是廢棄了的，不能使用。那么我們使用的是第二種方案，自己用匯編模擬一下 ucontext。

模擬ucontext的核心是通過getContext和setContext實現(xiàn)保存和恢復(fù)調(diào)用棧。需要熟悉不同CPU架構(gòu)下的調(diào)用約定(Calling Convention). 匯編實現(xiàn)就是要針對不同cpu實現(xiàn)一套，我們目前實現(xiàn)了 armv7、arm64、i386、x86_64，支持iPhone真機和模擬器。

說了這么多，還是看看代碼吧，我們從一個簡單的網(wǎng)絡(luò)請求加載圖片功能來看看coobjc到底是如何使用的。

下面是最普通的網(wǎng)絡(luò)請求的寫法：

下面是使用coobjc庫協(xié)程化改造后的代碼：

原本需要20行的代碼，通過coobjc協(xié)程化改造后，減少了一半，整個代碼邏輯和可讀性都更加好，這就是coobjc強大的能力，能把原本很復(fù)雜的異步代碼，通過協(xié)程化改造，轉(zhuǎn)變成邏輯簡潔的順序調(diào)用。

coobjc還有很多其他強大的能力，本文對于coobjc的實際使用就不過多介紹了，感興趣的朋友可以去官方github倉庫自行下載查看。

我們在iPhone7 iOS11.4.1的設(shè)備上使用協(xié)程和傳統(tǒng)多線程方式分別模擬高并發(fā)讀取數(shù)據(jù)的場景，下面是兩種方式得到的壓測數(shù)據(jù)。

從上面的表格我們可以看到使用在并發(fā)量很小的場景，由于多線程可以完全使用設(shè)備的計算核心，因此coobjc總耗時要比傳統(tǒng)多線程略高，但是由于整體耗時都很小，因此差異并不明顯，但是隨著并發(fā)量的增大，coobjc的優(yōu)勢開始逐漸體現(xiàn)出來，當并發(fā)量超過1000以后，傳統(tǒng)多線程開始出現(xiàn)線程分配異常，而導(dǎo)致很多并發(fā)任務(wù)并沒有執(zhí)行，因此在上表中顯示的是大于20秒，實際是任務(wù)已經(jīng)無法正常執(zhí)行了，但是coobjc仍然可以正常運行。

我們在手機淘寶這種超級App中嘗試了協(xié)程化改造，針對部分性能差的頁面，我們發(fā)現(xiàn)在滑動過程中存在很多主線程IO調(diào)用、數(shù)據(jù)解析，導(dǎo)致幀率下降嚴重，通過引入coobjc，在不改變原有業(yè)務(wù)代碼的基礎(chǔ)上，通過全局hook部分IO、數(shù)據(jù)解析方法，即可讓原來在主線程中同步執(zhí)行的IO方法異步執(zhí)行，并且不影響原有的業(yè)務(wù)邏輯，通過測試驗證，這樣的改造在低端機(iPhone6及以下的機器)上的幀率有20%左右的提升。

簡明

易用

清晰

性能

程序是寫來給人讀的，只會偶爾讓機器執(zhí)行一下?！狝belson and Sussman

基于協(xié)程實現(xiàn)的編程范式能夠幫助開發(fā)者編寫出更加優(yōu)美、健壯、可讀性更強的代碼。

協(xié)程可以幫助我們在編寫并發(fā)代碼的過程中減少線程和鎖的使用，提升應(yīng)用的性能和穩(wěn)定性。

本文作者：淘寶技術(shù)

iOS Speech框架 詳解

原文地址：

一、引言

? ? iOS10系統(tǒng)是一個較有突破性的系統(tǒng)，其在Message，Notification等方面都開放了很多實用性的開發(fā)接口。本篇博客將主要探討iOS10中新引入的SpeechFramework框架。有個這個框架，開發(fā)者可以十分容易的為自己的App添加語音識別功能，不需要再依賴于其他第三方的語音識別服務(wù)，并且，Apple的Siri應(yīng)用的強大也證明了Apple的語音服務(wù)是足夠強大的，不通過第三方，也大大增強了用戶的安全性。

二、SpeechFramework框架中的重要類

? ? SpeechFramework框架比較輕量級，其中的類并不十分冗雜，在學習SpeechFramework框架前，我們需要對其中類與類與類之間的關(guān)系有個大致的熟悉了解。

SFSpeechRecognizer：這個類是語音識別的操作類，用于語音識別用戶權(quán)限的申請，語言環(huán)境的設(shè)置，語音模式的設(shè)置以及向Apple服務(wù)發(fā)送語音識別的請求。

SFSpeechRecognitionTask：這個類是語音識別服務(wù)請求任務(wù)類，每一個語音識別請求都可以抽象為一個SFSpeechRecognitionTask實例，其中SFSpeechRecognitionTaskDelegate協(xié)議中約定了許多請求任務(wù)過程中的監(jiān)聽方法。

SFSpeechRecognitionRequest:語音識別請求類，需要通過其子類來進行實例化。

SFSpeechURLRecognitionRequest：通過音頻URL來創(chuàng)建語音識別請求。

SFSpeechAudioBufferRecognitionRequest:通過音頻流來創(chuàng)建語音識別請求。

SFSpeechRecognitionResult：語音識別請求結(jié)果類。

SFTranscription：語音轉(zhuǎn)換后的信息類。

SFTranscriptionSegment：語音轉(zhuǎn)換中的音頻節(jié)點類。

三、申請用戶語音識別權(quán)限與進行語音識別請求

? ? 開發(fā)者若要在自己的App中使用語音識別功能，需要獲取用戶的同意。首先需要在工程的Info.plist文件中添加一個Privacy-Speech Recognition Usage Description鍵，其實需要對應(yīng)一個String類型的值，這個值將會在系統(tǒng)獲取權(quán)限的警告框中顯示，Info.plist文件如下圖所示：

使用SFSpeechRecognize類的requestAuthorization方法來進行用戶權(quán)限的申請，用戶的反饋結(jié)果會在這個方法的回調(diào)block中傳入，如下：

? //申請用戶語音識別權(quán)限

? [SFSpeechRecognizer requestAuthorization:^(SFSpeechRecognizerAuthorizationStatus status) {? ?

? }];

SFSpeechRecognizerAuthorzationStatus枚舉中定義了用戶的反饋結(jié)果，如下：

typedef NS_ENUM(NSInteger, SFSpeechRecognizerAuthorizationStatus) {

? ? //結(jié)果未知 用戶尚未進行選擇

? ? SFSpeechRecognizerAuthorizationStatusNotDetermined,

? ? //用戶拒絕授權(quán)語音識別

? ? SFSpeechRecognizerAuthorizationStatusDenied,

? ? //設(shè)備不支持語音識別功能

? ? SFSpeechRecognizerAuthorizationStatusRestricted,

? ? //用戶授權(quán)語音識別

? ? SFSpeechRecognizerAuthorizationStatusAuthorized,

};

如果申請用戶語音識別權(quán)限成功，開發(fā)者可以通過SFSpeechRecognizer操作類來進行語音識別請求，示例如下：

? ? //創(chuàng)建語音識別操作類對象

? ? SFSpeechRecognizer * rec = [[SFSpeechRecognizer alloc]init];

? ? //通過一個音頻路徑創(chuàng)建音頻識別請求

? ? SFSpeechRecognitionRequest * request = [[SFSpeechURLRecognitionRequest alloc]initWithURL:[[NSBundle mainBundle] URLForResource:@"7011" withExtension:@"m4a"]];

? ? //進行請求

? ? [rec recognitionTaskWithRequest:request resultHandler:^(SFSpeechRecognitionResult * _Nullable result, NSError * _Nullable error) {

? ? ? ? //打印語音識別的結(jié)果字符串

? ? ? ? NSLog(@"%@",result.bestTranscription.formattedString);

? ? }];

四、深入SFSpeechRecognizer類

SFSpeechRecognizer類的主要作用是申請權(quán)限，配置參數(shù)與進行語音識別請求。其中比較重要的屬性與方法如下：

//獲取當前用戶權(quán)限狀態(tài)

+ (SFSpeechRecognizerAuthorizationStatus)authorizationStatus;

//申請語音識別用戶權(quán)限

+ (void)requestAuthorization:(void(^)(SFSpeechRecognizerAuthorizationStatus status))handler;

//獲取所支持的所有語言環(huán)境

+ (NSSetNSLocale * *)supportedLocales;

//初始化方法 需要注意 這個初始化方法將默認以設(shè)備當前的語言環(huán)境作為語音識別的語言環(huán)境

- (nullable instancetype)init;

//初始化方法 設(shè)置一個特定的語言環(huán)境

- (nullable instancetype)initWithLocale:(NSLocale *)locale NS_DESIGNATED_INITIALIZER;

//語音識別是否可用

@property (nonatomic, readonly, getter=isAvailable) BOOL available;

//語音識別操作類協(xié)議代理

@property (nonatomic, weak) idSFSpeechRecognizerDelegate delegate;

//設(shè)置語音識別的配置參數(shù) 需要注意 在每個語音識別請求中也有這樣一個屬性 這里設(shè)置將作為默認值

//如果SFSpeechRecognitionRequest對象中也進行了設(shè)置 則會覆蓋這里的值

/*

typedef NS_ENUM(NSInteger, SFSpeechRecognitionTaskHint) {

? ? SFSpeechRecognitionTaskHintUnspecified = 0,? ? // 無定義

? ? SFSpeechRecognitionTaskHintDictation = 1,? ? ? // 正常的聽寫風格

? ? SFSpeechRecognitionTaskHintSearch = 2,? ? ? ? ? // 搜索風格

? ? SFSpeechRecognitionTaskHintConfirmation = 3,? ? // 短語風格

};

*/

@property (nonatomic) SFSpeechRecognitionTaskHint defaultTaskHint;

//使用回調(diào)Block的方式進行語音識別請求 請求結(jié)果會在Block中傳入

- (SFSpeechRecognitionTask *)recognitionTaskWithRequest:(SFSpeechRecognitionRequest *)request

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? resultHandler:(void (^)(SFSpeechRecognitionResult * __nullable result, NSError * __nullable error))resultHandler;

//使用代理回調(diào)的方式進行語音識別請求

- (SFSpeechRecognitionTask *)recognitionTaskWithRequest:(SFSpeechRecognitionRequest *)request

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? delegate:(id SFSpeechRecognitionTaskDelegate)delegate;

//設(shè)置請求所占用的任務(wù)隊列

@property (nonatomic, strong) NSOperationQueue *queue;

SFSpeechRecognizerDelegate協(xié)議中只約定了一個方法，如下:

//當語音識別操作可用性發(fā)生改變時會被調(diào)用

- (void)speechRecognizer:(SFSpeechRecognizer *)speechRecognizer availabilityDidChange:(BOOL)available;

? ? 通過Block回調(diào)的方式進行語音識別請求十分簡單，如果使用代理回調(diào)的方式，開發(fā)者需要實現(xiàn)SFSpeechRecognitionTaskDelegate協(xié)議中的相關(guān)方法，如下：

//當開始檢測音頻源中的語音時首先調(diào)用此方法

- (void)speechRecognitionDidDetectSpeech:(SFSpeechRecognitionTask *)task;

//當識別出一條可用的信息后 會調(diào)用

/*

需要注意，apple的語音識別服務(wù)會根據(jù)提供的音頻源識別出多個可能的結(jié)果 每有一條結(jié)果可用 都會調(diào)用此方法

*/

- (void)speechRecognitionTask:(SFSpeechRecognitionTask *)task didHypothesizeTranscription:(SFTranscription *)transcription;

//當識別完成所有可用的結(jié)果后調(diào)用

- (void)speechRecognitionTask:(SFSpeechRecognitionTask *)task didFinishRecognition:(SFSpeechRecognitionResult *)recognitionResult;

//當不再接受音頻輸入時調(diào)用 即開始處理語音識別任務(wù)時調(diào)用

- (void)speechRecognitionTaskFinishedReadingAudio:(SFSpeechRecognitionTask *)task;

//當語音識別任務(wù)被取消時調(diào)用

- (void)speechRecognitionTaskWasCancelled:(SFSpeechRecognitionTask *)task;

//語音識別任務(wù)完成時被調(diào)用

- (void)speechRecognitionTask:(SFSpeechRecognitionTask *)task didFinishSuccessfully:(BOOL)successfully;

SFSpeechRecognitionTask類中封裝了屬性和方法如下：

//此任務(wù)的當前狀態(tài)

/*

typedef NS_ENUM(NSInteger, SFSpeechRecognitionTaskState) {

SFSpeechRecognitionTaskStateStarting = 0,? ? ? // 任務(wù)開始

SFSpeechRecognitionTaskStateRunning = 1,? ? ? ? // 任務(wù)正在運行

SFSpeechRecognitionTaskStateFinishing = 2,? ? ? // 不在進行音頻讀入 即將返回識別結(jié)果

SFSpeechRecognitionTaskStateCanceling = 3,? ? ? // 任務(wù)取消

SFSpeechRecognitionTaskStateCompleted = 4,? ? ? // 所有結(jié)果返回完成

};

*/

@property (nonatomic, readonly) SFSpeechRecognitionTaskState state;

//音頻輸入是否完成

@property (nonatomic, readonly, getter=isFinishing) BOOL finishing;

//手動完成音頻輸入 不再接收音頻

- (void)finish;

//任務(wù)是否被取消

@property (nonatomic, readonly, getter=isCancelled) BOOL cancelled;

//手動取消任務(wù)

- (void)cancel;

關(guān)于音頻識別請求類，除了可以使用SFSpeechURLRecognitionRequest類來進行創(chuàng)建外，還可以使用SFSpeechAudioBufferRecognitionRequest類來進行創(chuàng)建：

@interface SFSpeechAudioBufferRecognitionRequest : SFSpeechRecognitionRequest

@property (nonatomic, readonly) AVAudioFormat *nativeAudioFormat;

//拼接音頻流

- (void)appendAudioPCMBuffer:(AVAudioPCMBuffer *)audioPCMBuffer;

- (void)appendAudioSampleBuffer:(CMSampleBufferRef)sampleBuffer;

//完成輸入

- (void)endAudio;

@end

五、語音識別結(jié)果類SFSpeechRecognitionResult

? ? SFSpeechRecognitionResult類是語音識別結(jié)果的封裝，其中包含了許多套平行的識別信息，其每一份識別信息都有可信度屬性來描述其準確程度。SFSpeechRecognitionResult類中屬性如下：

//識別到的多套語音轉(zhuǎn)換信息數(shù)組 其會按照準確度進行排序

@property (nonatomic, readonly, copy) NSArraySFTranscription * *transcriptions;

//準確性最高的識別實例

@property (nonatomic, readonly, copy) SFTranscription *bestTranscription;

//是否已經(jīng)完成 如果YES 則所有所有識別信息都已經(jīng)獲取完成

@property (nonatomic, readonly, getter=isFinal) BOOL final;

SFSpeechRecognitionResult類只是語音識別結(jié)果的一個封裝，真正的識別信息定義在SFTranscription類中，SFTranscription類中屬性如下：

//完整的語音識別準換后的文本信息字符串

@property (nonatomic, readonly, copy) NSString *formattedString;

//語音識別節(jié)點數(shù)組

@property (nonatomic, readonly, copy) NSArraySFTranscriptionSegment * *segments;

當對一句完整的話進行識別時，Apple的語音識別服務(wù)實際上會把這句語音拆分成若干個音頻節(jié)點，每個節(jié)點可能為一個單詞，SFTranscription類中的segments屬性就存放這些節(jié)點。SFTranscriptionSegment類中定義的屬性如下：

//當前節(jié)點識別后的文本信息

@property (nonatomic, readonly, copy) NSString *substring;

//當前節(jié)點識別后的文本信息在整體識別語句中的位置

@property (nonatomic, readonly) NSRange substringRange;

//當前節(jié)點的音頻時間戳

@property (nonatomic, readonly) NSTimeInterval timestamp;

//當前節(jié)點音頻的持續(xù)時間

@property (nonatomic, readonly) NSTimeInterval duration;

//可信度/準確度 0-1之間

@property (nonatomic, readonly) float confidence;

//關(guān)于此節(jié)點的其他可能的識別結(jié)果

@property (nonatomic, readonly) NSArrayNSString * *alternativeSubstrings;

溫馨提示：SpeechFramework框架在模擬器上運行會出現(xiàn)異常情況，無法進行語音識別請求。會報出kAFAssistantErrorDomain的錯誤，還望有知道解決方案的朋友，給些建議，Thanks。