建站
咨詢
售后
建站咨詢
新聞中心
剛剛，阿里巴巴正式對外開源了基于 Apache 2.0 協(xié)議的協(xié)程開發(fā)框架 coobjc，開發(fā)者們可以在 Github 上自主下載。
創(chuàng)新互聯(lián)堅持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：成都網(wǎng)站建設(shè)、網(wǎng)站制作、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時代的鎮(zhèn)平網(wǎng)站設(shè)計、移動媒體設(shè)計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！
coobjc是為iOS平臺打造的開源協(xié)程開發(fā)框架，支持Objective-C和Swift，同時提供了cokit庫為Foundation和UIKit中的部分API提供了協(xié)程化支持，本文將為大家詳細(xì)介紹coobjc的設(shè)計理念及核心優(yōu)勢。
開源地址
https://github.com/alibaba/coobjc
iOS異步編程問題
從2008年***個iOS版本發(fā)布至今的11年時間里，iOS的異步編程方式發(fā)展緩慢。
基于 Block 的異步編程回調(diào)是目前 iOS 使用最廣泛的異步編程方式，iOS 系統(tǒng)提供的 GCD 庫讓異步開發(fā)變得很簡單方便，但是基于這種編程方式的缺點也有很多，主要有以下幾點：
- 容易進(jìn)入"嵌套地獄"
- 錯誤處理復(fù)雜和冗長
- 容易忘記調(diào)用 completion handler
- 條件執(zhí)行變得很困難
- 從互相獨立的調(diào)用中組合返回結(jié)果變得極其困難
- 在錯誤的線程中繼續(xù)執(zhí)行(如子線程操作UI)
- 難以定位原因的多線程崩潰(手淘中多線程crash已占比60%以上)
- 鎖和信號量濫用帶來的卡頓、卡死
針對多線程以及尤其引發(fā)的各種崩潰和性能問題，我們制定了很多編程規(guī)范、進(jìn)行了各種新人培訓(xùn)，嘗試降低問題發(fā)生的概率，但是問題依然很嚴(yán)峻，多線程引發(fā)的問題占比并沒有明顯的下降，異步編程本來就是很復(fù)雜的事情，單靠規(guī)范和培訓(xùn)是難以從根本上解決問題的，需要有更加好的編程方式來解決。
解決方案
上述問題在很多系統(tǒng)和語言開發(fā)中都可能會碰到，解決問題的標(biāo)準(zhǔn)方式就是使用協(xié)程，C#、Kotlin、Python、Javascript 等熱門語言均支持協(xié)程極其相關(guān)語法，使用這些語言的開發(fā)者可以很方便的使用協(xié)程及相關(guān)功能進(jìn)行異步編程。
2017 年的 C++ 標(biāo)準(zhǔn)開始支持協(xié)程，Swift5 中也包含了協(xié)程相關(guān)的標(biāo)準(zhǔn)，從現(xiàn)在的發(fā)展趨勢看基于協(xié)程的全新的異步編程方式，是我們解決現(xiàn)有異步編程問題的有效的方式，但是蘋果基本已經(jīng)不會升級 Objective-C 了，因此使用Objective-C的開發(fā)者是無法使用官方的協(xié)程能力的，而*** Swift 的發(fā)布和推廣也還需要時日，為了讓廣大iOS開發(fā)者能快速享受到協(xié)程帶來的編程方式上的改變，手機(jī)淘寶架構(gòu)團(tuán)隊基于長期對系統(tǒng)底層庫和匯編的研究，通過匯編和C語言實現(xiàn)了支持 Objective-C 和 Swift 協(xié)程的***解決方案 —— coobjc。
核心能力
- 提供了類似C#和Javascript語言中的Async/Await編程方式支持，在協(xié)程中通過調(diào)用await方法即可同步得到異步方法的執(zhí)行結(jié)果，非常適合IO、網(wǎng)絡(luò)等異步耗時調(diào)用的同步順序執(zhí)行改造。
- 提供了類似Kotlin中的Generator功能，用于懶計算生成序列化數(shù)據(jù)，非常適合多線程可中斷的序列化數(shù)據(jù)生成和訪問。
- 提供了Actor Model的實現(xiàn)，基于Actor Model，開發(fā)者可以開發(fā)出更加線程安全的模塊，避免由于直接函數(shù)調(diào)用引發(fā)的各種多線程崩潰問題。
- 提供了元組的支持，通過元組Objective-C開發(fā)者可以享受到類似Python語言中多值返回的好處。
內(nèi)置系統(tǒng)擴(kuò)展庫
- 提供了對NSArray、NSDictionary等容器庫的協(xié)程化擴(kuò)展，用于解決序列化和反序列化過程中的異步調(diào)用問題。
- 提供了對NSData、NSString、UIImage等數(shù)據(jù)對象的協(xié)程化擴(kuò)展，用于解決讀寫IO過程中的異步調(diào)用問題。
- 提供了對NSURLConnection和NSURLSession的協(xié)程化擴(kuò)展，用于解決網(wǎng)絡(luò)異步請求過程中的異步調(diào)用問題。
- 提供了對NSKeyedArchieve、NSJSONSerialization等解析庫的擴(kuò)展，用于解決解析過程中的異步調(diào)用問題。
coobjc設(shè)計
- ***層是協(xié)程內(nèi)核，包含了棧切換的管理、協(xié)程調(diào)度器的實現(xiàn)、協(xié)程間通信channel的實現(xiàn)等。
- 中間層是基于協(xié)程的操作符的包裝，目前支持async/await、Generator、Actor等編程模型。
- 最上層是對系統(tǒng)庫的協(xié)程化擴(kuò)展，目前基本上覆蓋了Foundation和UIKit的所有IO和耗時方法。
核心實現(xiàn)原理
協(xié)程的核心思想是控制調(diào)用棧的主動讓出和恢復(fù)。一般的協(xié)程實現(xiàn)都會提供兩個重要的操作：
- Yield：是讓出cpu的意思，它會中斷當(dāng)前的執(zhí)行，回到上一次Resume的地方。
- Resume：繼續(xù)協(xié)程的運行。執(zhí)行Resume后，回到上一次協(xié)程Yield的地方。
我們基于線程的代碼執(zhí)行時候，是沒法做出暫停操作的，我們現(xiàn)在要做的事情就是要代碼執(zhí)行能夠暫停，還能夠再恢復(fù)。 基本上代碼執(zhí)行都是一種基于調(diào)用棧的模型，所以如果我們能把當(dāng)前調(diào)用棧上的狀態(tài)都保存下來，然后再能從緩存中恢復(fù)，那我們就能夠?qū)崿F(xiàn)yield和 resume。
實現(xiàn)這樣操作有幾種方法呢?
- ***種：利用glibc 的 ucontext組件(云風(fēng)的庫)。
- 第二種：使用匯編代碼來切換上下文(實現(xiàn)c協(xié)程)，原理同ucontext。
- 第三種：利用C語言語法switch-case的奇淫技巧來實現(xiàn)(Protothreads)。
- 第四種：利用了 C 語言的 setjmp 和 longjmp。
- 第五種：利用編譯器支持語法糖。
上述第三種和第四種只是能過做到跳轉(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真機(jī)和模擬器。
Show me the code
說了這么多，還是看看代碼吧，我們從一個簡單的網(wǎng)絡(luò)請求加載圖片功能來看看coobjc到底是如何使用的。
下面是最普通的網(wǎng)絡(luò)請求的寫法：
下面是使用coobjc庫協(xié)程化改造后的代碼：
原本需要20行的代碼，通過coobjc協(xié)程化改造后，減少了一半，整個代碼邏輯和可讀性都更加好，這就是coobjc強(qiáng)大的能力，能把原本很復(fù)雜的異步代碼，通過協(xié)程化改造，轉(zhuǎn)變成邏輯簡潔的順序調(diào)用。
coobjc還有很多其他強(qiáng)大的能力，本文對于coobjc的實際使用就不過多介紹了，感興趣的朋友可以去官方github倉庫自行下載查看。
性能提升
我們在iPhone7 iOS11.4.1的設(shè)備上使用協(xié)程和傳統(tǒng)多線程方式分別模擬高并發(fā)讀取數(shù)據(jù)的場景，下面是兩種方式得到的壓測數(shù)據(jù)。
- 測試機(jī)器：iPhone7 iOS11.4.1
- 數(shù)據(jù)文件大?。?0M
- 協(xié)程最多使用線程數(shù)：4
- 數(shù)據(jù)測試結(jié)果(統(tǒng)計的是所有并發(fā)訪問結(jié)束的總耗時)：
從上面的表格我們可以看到使用在并發(fā)量很小的場景，由于多線程可以完全使用設(shè)備的計算核心，因此coobjc總耗時要比傳統(tǒng)多線程略高，但是由于整體耗時都很小，因此差異并不明顯，但是隨著并發(fā)量的增大，coobjc的優(yōu)勢開始逐漸體現(xiàn)出來，當(dāng)并發(fā)量超過1000以后，傳統(tǒng)多線程開始出現(xiàn)線程分配異常，而導(dǎo)致很多并發(fā)任務(wù)并沒有執(zhí)行，因此在上表中顯示的是大于20秒，實際是任務(wù)已經(jīng)無法正常執(zhí)行了，但是coobjc仍然可以正常運行。
我們在手機(jī)淘寶這種超級App中嘗試了協(xié)程化改造，針對部分性能差的頁面，我們發(fā)現(xiàn)在滑動過程中存在很多主線程IO調(diào)用、數(shù)據(jù)解析，導(dǎo)致幀率下降嚴(yán)重，通過引入coobjc，在不改變原有業(yè)務(wù)代碼的基礎(chǔ)上，通過全局hook部分IO、數(shù)據(jù)解析方法，即可讓原來在主線程中同步執(zhí)行的IO方法異步執(zhí)行，并且不影響原有的業(yè)務(wù)邏輯，通過測試驗證，這樣的改造在低端機(jī)(iPhone6及以下的機(jī)器)上的幀率有20%左右的提升。
優(yōu)勢
簡明
- 概念少：只有很少的幾個操作符，相比響應(yīng)式幾十個操作符，簡直不能再簡單了。
- 原理簡單：協(xié)程的實現(xiàn)原理很簡單，整個協(xié)程庫只有幾千行代碼。
易用
- 使用簡單：它的使用方式比GCD還要簡單，接口很少。
- 改造方便：現(xiàn)有代碼只需要進(jìn)行很少的改動就可以協(xié)程化，同時我們針對系統(tǒng)庫提供了大量協(xié)程化接口。
清晰
- 同步寫異步邏輯：同步順序方式寫代碼是人類最容易接受的方式，這可以極大的減少出錯的概率。
- 可讀性高：使用協(xié)程方式編寫的代碼比block嵌套寫出來的代碼可讀性要高很多。
性能
- 調(diào)度性能更快：協(xié)程本身不需要進(jìn)行內(nèi)核級線程的切換，調(diào)度性能快，即使創(chuàng)建上萬個協(xié)程也毫無壓力。
- 減少卡頓卡死: 協(xié)程的使用以幫助開發(fā)減少鎖、信號量的濫用，通過封裝會引起阻塞的IO等協(xié)程接口，可以從根源上減少卡頓、卡死，提升應(yīng)用整體的性能。
總結(jié)
程序是寫來給人讀的，只會偶爾讓機(jī)器執(zhí)行一下?！狝belson and Sussman
基于協(xié)程實現(xiàn)的編程范式能夠幫助開發(fā)者編寫出更加優(yōu)美、健壯、可讀性更強(qiáng)的代碼。
協(xié)程可以幫助我們在編寫并發(fā)代碼的過程中減少線程和鎖的使用，提升應(yīng)用的性能和穩(wěn)定性。
【本文為專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】
戳這里，看該作者更多好文
新聞標(biāo)題：剛剛，阿里開源 iOS 協(xié)程開發(fā)框架 coobjc！
本文路徑：http://m.5511xx.com/article/ccdsish.html
