sstoolkit 一套Category類型的庫,附帶很多自定義控件，功能不錯～
創(chuàng)新互聯(lián)自2013年創(chuàng)立以來，先為梅列等服務(wù)建站，梅列等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為梅列企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。
BlocksKit 將Block風(fēng)格帶入UIKit和Founcation
cocoa-helpers 一些Cocoa的擴(kuò)展 2年前的工程
CoconutKit 一系列擴(kuò)展和一些自定組件
STUtils 一系列擴(kuò)展包
PSFoundation 一系列擴(kuò)展 和功能增強(qiáng)
ConciseKit 一系列宏定義 挺有意思
DTFoundation 又一系列擴(kuò)展
BBBootstrap 一些常見功能的擴(kuò)展庫
阿里妹導(dǎo)讀：剛剛，阿里巴巴正式對外開源了基于 Apache 2.0 協(xié)議的協(xié)程開發(fā)框架 coobjc，開發(fā)者們可以在 Github 上自主下載。
coobjc是為iOS平臺打造的開源協(xié)程開發(fā)框架，支持Objective-C和Swift，同時提供了cokit庫為Foundation和UIKit中的部分API提供了 協(xié)程 化支持，本文將為大家詳細(xì)介紹coobjc的設(shè)計理念及核心優(yōu)勢。
從2008年第一個iOS版本發(fā)布至今的11年時間里，iOS的異步編程方式發(fā)展緩慢。
基于 Block 的異步編程回調(diào)是目前 iOS 使用最廣泛的異步編程方式，iOS 系統(tǒng)提供的 GCD 庫讓異步開發(fā)變得很簡單方便，但是基于這種編程方式的缺點也有很多，主要有以下幾點：
針對多線程以及尤其引發(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。
核心能力
內(nèi)置系統(tǒng)擴(kuò)展庫
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)都會提供兩個重要的操作：
我們基于線程的代碼執(zhí)行時候，是沒法做出暫停操作的，我們現(xiàn)在要做的事情就是要代碼執(zhí)行能夠暫停，還能夠再恢復(fù)。 基本上代碼執(zhí)行都是一種基于調(diào)用棧的模型，所以如果我們能把當(dāng)前調(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真機(jī)和模擬器。
說了這么多，還是看看代碼吧，我們從一個簡單的網(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ù)。
從上面的表格我們可以看到使用在并發(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%左右的提升。
簡明
易用
清晰
性能
程序是寫來給人讀的，只會偶爾讓機(jī)器執(zhí)行一下?！狝belson and Sussman
基于協(xié)程實現(xiàn)的編程范式能夠幫助開發(fā)者編寫出更加優(yōu)美、健壯、可讀性更強(qiáng)的代碼。
協(xié)程可以幫助我們在編寫并發(fā)代碼的過程中減少線程和鎖的使用，提升應(yīng)用的性能和穩(wěn)定性。
本文作者：淘寶技術(shù)
既然要承載 web 頁面，一個原生的 WebView 必不可少。在 iOS 中，目前已經(jīng)有兩款高性能、功能齊全的 web 瀏覽器，UIWebView (=2.0)和 WKWebView(=7.0)。
當(dāng)然，兩種 web 瀏覽器選其一即可。網(wǎng)上有很多文章，包括我之前已經(jīng)發(fā)表的博文中，都介紹過這兩種瀏覽器，讀者可以根據(jù)自己的需要選擇。
就目前的情況看，UIWebView 發(fā)展了很多年，目前市面上大部分的 web 頁面也都支持這樣的瀏覽器，因此很多公司在選擇的時候都使用這個，但是，我們知道，WKWebView 有太多改善前者的優(yōu)點，而且也是蘋果官方提倡大家使用的，為了性能，為了更多的特性，建議初次搭建的朋友采用 WKWebView。
為了實現(xiàn) h5 與 native 之間的互相調(diào)用，我們需要在兩者之間架一層橋來實現(xiàn)，關(guān)于 bridge，之前的文章也有介紹。
bridge 的功能包括：native 調(diào)用 h5，h5 回調(diào) native，h5 調(diào)用 native，native 回調(diào) h5。
有了 bridge，h5可以使用 native 支持的更多特性，native 可以獲取 h5 頁面加載的信息，也可以讓 web 頁面動態(tài)執(zhí)行一些腳本做一些事。
總之，在 web 容器框架中，這個 bridge 還是很有必要的。
嗯，這個是輔助項，做了這一步可以進(jìn)一步提高 web 容器的加載性能，而且資源緩存到本地后可以做到不依賴網(wǎng)絡(luò)，提高用戶體驗。
通常有兩種做法，
UIWebView 使用簡單，而且現(xiàn)在用戶的手機(jī)性能也已經(jīng)不再是頁面展示性能的瓶頸，所以，這里介紹的依然采用 UIWebView 作為 web 瀏覽器。
WebViewJavascriptBridge 是一款非常強(qiáng)大的第三方開源 bridge 庫，同時支持 UIWebView 和 WKWebView。
git 地址
NJKWebViewProgress 是一款能使 UIWebview 顯示加載進(jìn)度的第三方開源框架，支持代理協(xié)議處理和 progressview 展示兩種功能。
git 地址
重慶分公司
重慶分公司
