既然要承載 web 頁面，一個原生的 WebView 必不可少。在 iOS 中，目前已經有兩款高性能、功能齊全的 web 瀏覽器，UIWebView (=2.0)和 WKWebView(=7.0)。
成都創(chuàng)新互聯(lián)-專業(yè)網站定制、快速模板網站建設、高性價比港閘網站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式港閘網站制作公司更省心,省錢,快速模板網站建設找我們，業(yè)務覆蓋港閘地區(qū)。費用合理售后完善，10年實體公司更值得信賴。
當然，兩種 web 瀏覽器選其一即可。網上有很多文章，包括我之前已經發(fā)表的博文中，都介紹過這兩種瀏覽器，讀者可以根據自己的需要選擇。
就目前的情況看，UIWebView 發(fā)展了很多年，目前市面上大部分的 web 頁面也都支持這樣的瀏覽器，因此很多公司在選擇的時候都使用這個，但是，我們知道，WKWebView 有太多改善前者的優(yōu)點，而且也是蘋果官方提倡大家使用的，為了性能，為了更多的特性，建議初次搭建的朋友采用 WKWebView。
為了實現 h5 與 native 之間的互相調用，我們需要在兩者之間架一層橋來實現，關于 bridge，之前的文章也有介紹。
bridge 的功能包括：native 調用 h5，h5 回調 native，h5 調用 native，native 回調 h5。
有了 bridge，h5可以使用 native 支持的更多特性，native 可以獲取 h5 頁面加載的信息，也可以讓 web 頁面動態(tài)執(zhí)行一些腳本做一些事。
總之，在 web 容器框架中，這個 bridge 還是很有必要的。
嗯，這個是輔助項，做了這一步可以進一步提高 web 容器的加載性能，而且資源緩存到本地后可以做到不依賴網絡，提高用戶體驗。
通常有兩種做法，
UIWebView 使用簡單，而且現在用戶的手機性能也已經不再是頁面展示性能的瓶頸，所以，這里介紹的依然采用 UIWebView 作為 web 瀏覽器。
WebViewJavascriptBridge 是一款非常強大的第三方開源 bridge 庫，同時支持 UIWebView 和 WKWebView。
git 地址
NJKWebViewProgress 是一款能使 UIWebview 顯示加載進度的第三方開源框架，支持代理協(xié)議處理和 progressview 展示兩種功能。
git 地址
Bee framework
==================
[Bee Framework][1] 是一款iOS平臺的MVC應用快速開發(fā)框架，使用Objective-C開發(fā)。
其早期原型曾經被應用在 [QQ游戲大廳 for iPhone][2]、[QQ空間 for iPhone][3] 等多款精品APP中。 在最近幾個月中，我梳理并重構了設計，并取名為Bee，寓意著“清晰，靈活，高效，純粹”。
Bee 從根本上解決了iOS開發(fā)者長期困擾的各種問題，諸如：分層架構如何設計，層與層之間消息傳遞與處理，網絡操作及緩存，異步及多線程，以及適配產品多變的UI布局需求。
特點
--------------------
* 代碼注入
借助于OC語言特性，Bee將核心邏輯注入到NSObject基類中去，在使用Bee時，大多數情況下可以不必修改現有類繼承關系，這樣設計是把雙刃劍，也有可能與您現有方法名沖突。
在您代碼中任何位置都可以這樣做：
[self GET:@""];
[self POST:@"" data:[NSData data]];
[self postNotification:@"SOME_NOTIFICATION"];
[self sendMessage:@"SOME_MESSAGE" timeoutSeconds:10.0f];
[self sendUISignal:@"SOME_SIGNAL"];
* 基于MVC模型
典型的MVC架構，清楚的分為View、Controller、Model三個層次，業(yè)務數據、業(yè)務邏輯、界面展現、交互邏輯完全分離。
* 事件驅動
對于Controller、Model均與狀態(tài)無關（Stateless），因此由三種Event驅動：Message、Request、Notification。對于View，我們拋棄掉了老舊的Delegate（語言級實現方式），引入新概念UISignal（框架級實現方式）用來驅動界面交互事件或狀態(tài)改變。
* UISignal
UISignal擁有極強的路由能力，可以在UIView - UIView - UIViewController - UINavigationController - UIViewController 之間完成復雜且高效的的UI信號路由。
基于MVC的快速開發(fā)框架 Bee Framework 是一款iOS快速開發(fā)框架，允許開發(fā)者使用Objective-C和XML/CSS來進行iPhone和iPad開發(fā)，由 Gavin Kwoe 和 QFish 開發(fā)并維護。
這套布局庫是以android的線性布局，相對布局，框架布局，表格布局為藍本。同時又具有IOS的AutoLayout的功能，和部分SIZECLASS功能，以及IOS9中的UIStackView的功能，參考了masonry的一些語法機制，但是他卻可以運行在IOS5版本的應用中。使用簡單方便，代碼清晰，而且少。 并且附帶四篇教程文檔：
阿里妹導讀：剛剛，阿里巴巴正式對外開源了基于 Apache 2.0 協(xié)議的協(xié)程開發(fā)框架 coobjc，開發(fā)者們可以在 Github 上自主下載。
coobjc是為iOS平臺打造的開源協(xié)程開發(fā)框架，支持Objective-C和Swift，同時提供了cokit庫為Foundation和UIKit中的部分API提供了 協(xié)程 化支持，本文將為大家詳細介紹coobjc的設計理念及核心優(yōu)勢。
從2008年第一個iOS版本發(fā)布至今的11年時間里，iOS的異步編程方式發(fā)展緩慢。
基于 Block 的異步編程回調是目前 iOS 使用最廣泛的異步編程方式，iOS 系統(tǒng)提供的 GCD 庫讓異步開發(fā)變得很簡單方便，但是基于這種編程方式的缺點也有很多，主要有以下幾點：
針對多線程以及尤其引發(fā)的各種崩潰和性能問題，我們制定了很多編程規(guī)范、進行了各種新人培訓，嘗試降低問題發(fā)生的概率，但是問題依然很嚴峻，多線程引發(fā)的問題占比并沒有明顯的下降，異步編程本來就是很復雜的事情，單靠規(guī)范和培訓是難以從根本上解決問題的，需要有更加好的編程方式來解決。
上述問題在很多系統(tǒng)和語言開發(fā)中都可能會碰到，解決問題的標準方式就是使用協(xié)程，C#、Kotlin、Python、Javascript 等熱門語言均支持協(xié)程極其相關語法，使用這些語言的開發(fā)者可以很方便的使用協(xié)程及相關功能進行異步編程。
2017 年的 C++ 標準開始支持協(xié)程，Swift5 中也包含了協(xié)程相關的標準，從現在的發(fā)展趨勢看基于協(xié)程的全新的異步編程方式，是我們解決現有異步編程問題的有效的方式，但是蘋果基本已經不會升級 Objective-C 了，因此使用Objective-C的開發(fā)者是無法使用官方的協(xié)程能力的，而最新 Swift 的發(fā)布和推廣也還需要時日，為了讓廣大iOS開發(fā)者能快速享受到協(xié)程帶來的編程方式上的改變，手機淘寶架構團隊基于長期對系統(tǒng)底層庫和匯編的研究，通過匯編和C語言實現了支持 Objective-C 和 Swift 協(xié)程的完美解決方案 —— coobjc。
核心能力
內置系統(tǒng)擴展庫
coobjc設計
最底層是協(xié)程內核，包含了棧切換的管理、協(xié)程調度器的實現、協(xié)程間通信channel的實現等。
中間層是基于協(xié)程的操作符的包裝，目前支持async/await、Generator、Actor等編程模型。
最上層是對系統(tǒng)庫的協(xié)程化擴展，目前基本上覆蓋了Foundation和UIKit的所有IO和耗時方法。
核心實現原理
協(xié)程的核心思想是控制調用棧的主動讓出和恢復。一般的協(xié)程實現都會提供兩個重要的操作：
我們基于線程的代碼執(zhí)行時候，是沒法做出暫停操作的，我們現在要做的事情就是要代碼執(zhí)行能夠暫停，還能夠再恢復。 基本上代碼執(zhí)行都是一種基于調用棧的模型，所以如果我們能把當前調用棧上的狀態(tài)都保存下來，然后再能從緩存中恢復，那我們就能夠實現yield和 resume。
實現這樣操作有幾種方法呢？
上述第三種和第四種只是能過做到跳轉，但是沒法保存調用棧上的狀態(tài)，看起來基本上不能算是實現了協(xié)程，只能算做做demo，第五種除非官方支持，否則自行改寫編譯器通用性很差。而第一種方案的 ucontext 在iOS上是廢棄了的，不能使用。那么我們使用的是第二種方案，自己用匯編模擬一下 ucontext。
模擬ucontext的核心是通過getContext和setContext實現保存和恢復調用棧。需要熟悉不同CPU架構下的調用約定(Calling Convention). 匯編實現就是要針對不同cpu實現一套，我們目前實現了 armv7、arm64、i386、x86_64，支持iPhone真機和模擬器。
說了這么多，還是看看代碼吧，我們從一個簡單的網絡請求加載圖片功能來看看coobjc到底是如何使用的。
下面是最普通的網絡請求的寫法：
下面是使用coobjc庫協(xié)程化改造后的代碼：
原本需要20行的代碼，通過coobjc協(xié)程化改造后，減少了一半，整個代碼邏輯和可讀性都更加好，這就是coobjc強大的能力，能把原本很復雜的異步代碼，通過協(xié)程化改造，轉變成邏輯簡潔的順序調用。
coobjc還有很多其他強大的能力，本文對于coobjc的實際使用就不過多介紹了，感興趣的朋友可以去官方github倉庫自行下載查看。
我們在iPhone7 iOS11.4.1的設備上使用協(xié)程和傳統(tǒng)多線程方式分別模擬高并發(fā)讀取數據的場景，下面是兩種方式得到的壓測數據。
從上面的表格我們可以看到使用在并發(fā)量很小的場景，由于多線程可以完全使用設備的計算核心，因此coobjc總耗時要比傳統(tǒng)多線程略高，但是由于整體耗時都很小，因此差異并不明顯，但是隨著并發(fā)量的增大，coobjc的優(yōu)勢開始逐漸體現出來，當并發(fā)量超過1000以后，傳統(tǒng)多線程開始出現線程分配異常，而導致很多并發(fā)任務并沒有執(zhí)行，因此在上表中顯示的是大于20秒，實際是任務已經無法正常執(zhí)行了，但是coobjc仍然可以正常運行。
我們在手機淘寶這種超級App中嘗試了協(xié)程化改造，針對部分性能差的頁面，我們發(fā)現在滑動過程中存在很多主線程IO調用、數據解析，導致幀率下降嚴重，通過引入coobjc，在不改變原有業(yè)務代碼的基礎上，通過全局hook部分IO、數據解析方法，即可讓原來在主線程中同步執(zhí)行的IO方法異步執(zhí)行，并且不影響原有的業(yè)務邏輯，通過測試驗證，這樣的改造在低端機(iPhone6及以下的機器)上的幀率有20%左右的提升。
簡明
易用
清晰
性能
程序是寫來給人讀的，只會偶爾讓機器執(zhí)行一下?！狝belson and Sussman
基于協(xié)程實現的編程范式能夠幫助開發(fā)者編寫出更加優(yōu)美、健壯、可讀性更強的代碼。
協(xié)程可以幫助我們在編寫并發(fā)代碼的過程中減少線程和鎖的使用，提升應用的性能和穩(wěn)定性。
本文作者：淘寶技術
重慶分公司
重慶分公司
