OCUnit 是 OC 官方測(cè)試框架， 現(xiàn)在被 XCTest 所取代。
創(chuàng)新互聯(lián)建站專注于企業(yè)網(wǎng)絡(luò)營(yíng)銷推廣、網(wǎng)站重做改版、永安網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、HTML5、商城網(wǎng)站建設(shè)、集團(tuán)公司官網(wǎng)建設(shè)、外貿(mào)網(wǎng)站制作、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)等建站業(yè)務(wù)，價(jià)格優(yōu)惠性價(jià)比高，為永安等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。
XCTest 是與 Foundation 框架平行的測(cè)試框架。
GHUnit 是第三方的測(cè)試框架。 github地址
OCMock都是第三方的測(cè)試框架。 github地址
千峰扣丁學(xué)堂iOS開發(fā)為您解答：
1、Core
OS層：位于iOS框架的最底層，主要包含內(nèi)核、文件系統(tǒng)、網(wǎng)絡(luò)基礎(chǔ)架構(gòu)、安全管理、電源管理、設(shè)備驅(qū)動(dòng)、線程管理、內(nèi)存管理等。簡(jiǎn)而言之，該層提供了最低級(jí)的、系統(tǒng)級(jí)的服務(wù)。
2、Core
Services層：可稱之為核心服務(wù)層，顧名思義，它提供諸如字符串管理、集合管理、網(wǎng)絡(luò)操作、URL實(shí)用工具、聯(lián)系人管理、偏好設(shè)置等服務(wù)。除此之外，它還提供很多基于硬件特性的服務(wù)，如GPS、加速儀、陀螺儀等。該層包含了Core
Location、Core Motion、SystemConfiguration、Foundation與Core
Foundation子模塊。其中Foundation與Core Foundation子模塊提供了對(duì)公共數(shù)據(jù)類型(字符串、集合等)的抽象，Core
Foundation中的Core Data子模塊可以實(shí)現(xiàn)對(duì)象圖形管理與對(duì)象持久化。
3、Media層：依賴于Core
Services層提供的功能，主要負(fù)責(zé)圖形與多媒體服務(wù)。它包含了CoreGraphics、Core Text、OpenGL ES、Core
Animation、AVFoundation、Core Audio等與圖形、視頻和音頻相關(guān)的功能模塊。
4、Cocoa
Touch層：是直接向iOS應(yīng)用程序提供各種基礎(chǔ)功能的支持。其中的UIKit框架提供各種可視化控件供應(yīng)用程序使用，如窗口、視圖、視圖控制器與各種用戶控件等。另外UIKit也定義了應(yīng)用程序的默認(rèn)行為和事件處理結(jié)構(gòu)。
基礎(chǔ)是要過關(guān)的，oop、多線程、db、基本算法或數(shù)據(jù)結(jié)構(gòu)是必須的。
還要熟練掌握Objective-C語言，C/C++語言；3.熟悉Cocoa開發(fā)框架，包括UI、網(wǎng)絡(luò)等方面，熟悉IOS開發(fā)工具和相關(guān)開發(fā)測(cè)試工具的使用，掌握常用的數(shù)據(jù)結(jié)構(gòu)與常用算法，較好的邏輯思維分析和表達(dá)和溝通能力，要有一定的自學(xué)能力，較強(qiáng)的團(tuán)隊(duì)協(xié)作意識(shí)。
更多關(guān)于ios游戲開發(fā)需要哪些知識(shí)，進(jìn)入：查看更多內(nèi)容
阿里妹導(dǎo)讀：剛剛，阿里巴巴正式對(duì)外開源了基于 Apache 2.0 協(xié)議的協(xié)程開發(fā)框架 coobjc，開發(fā)者們可以在 Github 上自主下載。
coobjc是為iOS平臺(tái)打造的開源協(xié)程開發(fā)框架，支持Objective-C和Swift，同時(shí)提供了cokit庫(kù)為Foundation和UIKit中的部分API提供了 協(xié)程 化支持，本文將為大家詳細(xì)介紹coobjc的設(shè)計(jì)理念及核心優(yōu)勢(shì)。
從2008年第一個(gè)iOS版本發(fā)布至今的11年時(shí)間里，iOS的異步編程方式發(fā)展緩慢。
基于 Block 的異步編程回調(diào)是目前 iOS 使用最廣泛的異步編程方式，iOS 系統(tǒng)提供的 GCD 庫(kù)讓異步開發(fā)變得很簡(jiǎn)單方便，但是基于這種編程方式的缺點(diǎn)也有很多，主要有以下幾點(diǎn)：
針對(duì)多線程以及尤其引發(fā)的各種崩潰和性能問題，我們制定了很多編程規(guī)范、進(jìn)行了各種新人培訓(xùn)，嘗試降低問題發(fā)生的概率，但是問題依然很嚴(yán)峻，多線程引發(fā)的問題占比并沒有明顯的下降，異步編程本來就是很復(fù)雜的事情，單靠規(guī)范和培訓(xùn)是難以從根本上解決問題的，需要有更加好的編程方式來解決。
上述問題在很多系統(tǒng)和語言開發(fā)中都可能會(huì)碰到，解決問題的標(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ā)展趨勢(shì)看基于協(xié)程的全新的異步編程方式，是我們解決現(xiàn)有異步編程問題的有效的方式，但是蘋果基本已經(jīng)不會(huì)升級(jí) Objective-C 了，因此使用Objective-C的開發(fā)者是無法使用官方的協(xié)程能力的，而最新 Swift 的發(fā)布和推廣也還需要時(shí)日，為了讓廣大iOS開發(fā)者能快速享受到協(xié)程帶來的編程方式上的改變，手機(jī)淘寶架構(gòu)團(tuán)隊(duì)基于長(zhǎng)期對(duì)系統(tǒng)底層庫(kù)和匯編的研究，通過匯編和C語言實(shí)現(xiàn)了支持 Objective-C 和 Swift 協(xié)程的完美解決方案 —— coobjc。
核心能力
內(nèi)置系統(tǒng)擴(kuò)展庫(kù)
coobjc設(shè)計(jì)
最底層是協(xié)程內(nèi)核，包含了棧切換的管理、協(xié)程調(diào)度器的實(shí)現(xiàn)、協(xié)程間通信channel的實(shí)現(xiàn)等。
中間層是基于協(xié)程的操作符的包裝，目前支持async/await、Generator、Actor等編程模型。
最上層是對(duì)系統(tǒng)庫(kù)的協(xié)程化擴(kuò)展，目前基本上覆蓋了Foundation和UIKit的所有IO和耗時(shí)方法。
核心實(shí)現(xiàn)原理
協(xié)程的核心思想是控制調(diào)用棧的主動(dòng)讓出和恢復(fù)。一般的協(xié)程實(shí)現(xiàn)都會(huì)提供兩個(gè)重要的操作：
我們基于線程的代碼執(zhí)行時(shí)候，是沒法做出暫停操作的，我們現(xiàn)在要做的事情就是要代碼執(zhí)行能夠暫停，還能夠再恢復(fù)。 基本上代碼執(zhí)行都是一種基于調(diào)用棧的模型，所以如果我們能把當(dāng)前調(diào)用棧上的狀態(tài)都保存下來，然后再能從緩存中恢復(fù)，那我們就能夠?qū)崿F(xiàn)yield和 resume。
實(shí)現(xiàn)這樣操作有幾種方法呢？
上述第三種和第四種只是能過做到跳轉(zhuǎn)，但是沒法保存調(diào)用棧上的狀態(tài)，看起來基本上不能算是實(shí)現(xiàn)了協(xié)程，只能算做做demo，第五種除非官方支持，否則自行改寫編譯器通用性很差。而第一種方案的 ucontext 在iOS上是廢棄了的，不能使用。那么我們使用的是第二種方案，自己用匯編模擬一下 ucontext。
模擬ucontext的核心是通過getContext和setContext實(shí)現(xiàn)保存和恢復(fù)調(diào)用棧。需要熟悉不同CPU架構(gòu)下的調(diào)用約定(Calling Convention). 匯編實(shí)現(xiàn)就是要針對(duì)不同cpu實(shí)現(xiàn)一套，我們目前實(shí)現(xiàn)了 armv7、arm64、i386、x86_64，支持iPhone真機(jī)和模擬器。
說了這么多，還是看看代碼吧，我們從一個(gè)簡(jiǎn)單的網(wǎng)絡(luò)請(qǐng)求加載圖片功能來看看coobjc到底是如何使用的。
下面是最普通的網(wǎng)絡(luò)請(qǐng)求的寫法：
下面是使用coobjc庫(kù)協(xié)程化改造后的代碼：
原本需要20行的代碼，通過coobjc協(xié)程化改造后，減少了一半，整個(gè)代碼邏輯和可讀性都更加好，這就是coobjc強(qiáng)大的能力，能把原本很復(fù)雜的異步代碼，通過協(xié)程化改造，轉(zhuǎn)變成邏輯簡(jiǎn)潔的順序調(diào)用。
coobjc還有很多其他強(qiáng)大的能力，本文對(duì)于coobjc的實(shí)際使用就不過多介紹了，感興趣的朋友可以去官方github倉(cāng)庫(kù)自行下載查看。
我們?cè)趇Phone7 iOS11.4.1的設(shè)備上使用協(xié)程和傳統(tǒng)多線程方式分別模擬高并發(fā)讀取數(shù)據(jù)的場(chǎng)景，下面是兩種方式得到的壓測(cè)數(shù)據(jù)。
從上面的表格我們可以看到使用在并發(fā)量很小的場(chǎng)景，由于多線程可以完全使用設(shè)備的計(jì)算核心，因此coobjc總耗時(shí)要比傳統(tǒng)多線程略高，但是由于整體耗時(shí)都很小，因此差異并不明顯，但是隨著并發(fā)量的增大，coobjc的優(yōu)勢(shì)開始逐漸體現(xiàn)出來，當(dāng)并發(fā)量超過1000以后，傳統(tǒng)多線程開始出現(xiàn)線程分配異常，而導(dǎo)致很多并發(fā)任務(wù)并沒有執(zhí)行，因此在上表中顯示的是大于20秒，實(shí)際是任務(wù)已經(jīng)無法正常執(zhí)行了，但是coobjc仍然可以正常運(yùn)行。
我們?cè)谑謾C(jī)淘寶這種超級(jí)App中嘗試了協(xié)程化改造，針對(duì)部分性能差的頁(yè)面，我們發(fā)現(xiàn)在滑動(dòng)過程中存在很多主線程IO調(diào)用、數(shù)據(jù)解析，導(dǎo)致幀率下降嚴(yán)重，通過引入coobjc，在不改變?cè)袠I(yè)務(wù)代碼的基礎(chǔ)上，通過全局hook部分IO、數(shù)據(jù)解析方法，即可讓原來在主線程中同步執(zhí)行的IO方法異步執(zhí)行，并且不影響原有的業(yè)務(wù)邏輯，通過測(cè)試驗(yàn)證，這樣的改造在低端機(jī)(iPhone6及以下的機(jī)器)上的幀率有20%左右的提升。
簡(jiǎn)明
易用
清晰
性能
程序是寫來給人讀的，只會(huì)偶爾讓機(jī)器執(zhí)行一下?！狝belson and Sussman
基于協(xié)程實(shí)現(xiàn)的編程范式能夠幫助開發(fā)者編寫出更加優(yōu)美、健壯、可讀性更強(qiáng)的代碼。
協(xié)程可以幫助我們?cè)诰帉懖l(fā)代碼的過程中減少線程和鎖的使用，提升應(yīng)用的性能和穩(wěn)定性。
本文作者：淘寶技術(shù)
開源項(xiàng)目其實(shí)有一個(gè)成熟周期，這個(gè)周期大概是三年左右，自React框架在2013年發(fā)布并引爆了前端框架的大潮，這個(gè)屬于前端的周期就此開始了。
之后在2015年5月開源的React Native又開啟了屬于Web移動(dòng)前端的周期，15-16年，18-19年，21-22年正好就是屬于移動(dòng)前端的三個(gè)爆發(fā)點(diǎn)。
三年前，在第一個(gè)成熟收獲期，我盤點(diǎn)了移動(dòng)開發(fā)框架。在這第二個(gè)成熟收獲期，理所當(dāng)然要來盤點(diǎn)一波。
不過，當(dāng)我點(diǎn)開github項(xiàng)目的code-frequency時(shí)，還是被這個(gè)準(zhǔn)到嚇人的周期猜想驚呆了，先給你們看一波，剩下的自行驗(yàn)證。
1、
2、
再來說第二個(gè)比較有意思的發(fā)現(xiàn)，停止維護(hù)的項(xiàng)目絕大多數(shù)是Vue框架項(xiàng)目。
盤點(diǎn)開始的時(shí)候我還覺得React框架處于絕對(duì)劣勢(shì)，到完成時(shí)我發(fā)現(xiàn)React無論在選擇面還是成熟度上都超過了Vue。
原因我這里就不分析了，反正大家都有自己的看法。
網(wǎng)頁(yè)類框架就是前端組件框架，這一次雖然有大量項(xiàng)目停止維護(hù)，但是也有很多項(xiàng)目堅(jiān)持了下來，而且還涌現(xiàn)出了一批新項(xiàng)目。
大廠占了主導(dǎo)，因?yàn)檫@些年大廠在移動(dòng)開發(fā)上的需求，遠(yuǎn)高于其它方面。個(gè)人項(xiàng)目要堅(jiān)持確實(shí)不易。
本來是想要做一個(gè)驗(yàn)證項(xiàng)目，把所有框架都試用一遍并給出推薦度的。由于進(jìn)度太慢，還是下一次再發(fā)吧。
這次的重點(diǎn)是漸進(jìn)類框架，就是所謂多端同構(gòu)框架（小程序框架）。這幾年國(guó)內(nèi)的重點(diǎn)的各種小程序平臺(tái)，所以多端框架的需求很是旺盛。
不過大多數(shù)先行者都沒挺過來還是讓我很意外，只有Taro成功了，想想還是有很多讓人唏噓的東西。
在這里還是先預(yù)測(cè)一波吧，因?yàn)檫@一類框架最變化最大，最終還是有很多框架要出局的。
漸進(jìn)類框架是一個(gè)過渡性的產(chǎn)品，最終會(huì)變成橋接類框架的一部分，所以，與橋接類框架協(xié)同才是框架的出路。
這個(gè)賽道基本全是大廠了。
騰訊新一代跨端開發(fā)框架Hippy
Hippy一看就是淘寶Weex的對(duì)標(biāo)項(xiàng)目，Kpi功能全面壓制。所以官方支持 React 和 Vue 兩種主流前端框架。在Weex2019年實(shí)質(zhì)停更后發(fā)布，要不要這么卷？
Hippy 2.x 架構(gòu)主要分成三層，UI(JS) 層 Hippy-React 和 Hippy-Vue 負(fù)責(zé)驅(qū)動(dòng) UI 指令生成；中間層 C++ HippyCore 負(fù)責(zé)抹平平臺(tái)差異性和提供高性能模塊；渲染層 Android 和 iOS 負(fù)責(zé)提供終端底層模塊、組件，并與布局引擎通信。
對(duì)Weex慘遭遺棄，我上次就說過：「ReactNative提供工具，Weex提供框架，將平臺(tái)差異化屏蔽（Write Once, Run Everywhere）。所以Weex則注定功能相對(duì)弱小，并且坑比較多?！筗eex最終下馬也是必然的，淘寶又發(fā)布升級(jí)版北海，為了實(shí)現(xiàn)（Write Once, Run Everywhere），它采用自繪，而且是基于Flutter自繪。
所以Hippy3.x就一如既往的Kpi功能層層加碼，很有騰訊風(fēng)格。在未來的 3.x 中業(yè)務(wù)與渲染層中的具體實(shí)現(xiàn)可根據(jù)用戶實(shí)際場(chǎng)景進(jìn)行切換：業(yè)務(wù)層上不再局限于 JS 驅(qū)動(dòng)，還可選擇（如：DSL/Dart/WASM 等）其它語言進(jìn)行驅(qū)動(dòng)；在渲染層中，渲染引擎除了支持現(xiàn)有原生（Native）渲染之外，還可以選擇其他渲染 Renderer，如 Flutter(Voltron) 渲染。
「Kraken 北?！故且豢罡咝阅躓eb渲染引擎。底層基于 Flutter 進(jìn)行渲染。
Kraken 不限制上層開發(fā)者使用的框架，無論你是使用 Vue 、Rax 還是 React 都可以開發(fā) Kraken 應(yīng)用。
Kraken 的 runtime 通過 JS Engine Binding 的方式提供了一系列 Web 標(biāo)準(zhǔn)的 API 接口，調(diào)用相應(yīng) API 會(huì)執(zhí)行相關(guān)邏輯并創(chuàng)建一系列需要發(fā)送給 Dart 層處理的指令。
Kraken 其實(shí)就是一個(gè)小程序平臺(tái)，而且追求全平臺(tái)完全一致。我雖然認(rèn)為各平臺(tái)不一致是很自然的事情，但是也表示理解，畢竟別人吹牛有當(dāng)真的傳統(tǒng)（KFC表示認(rèn)同）。
Kraken 現(xiàn)在也是一個(gè)小號(hào)瀏覽器，所以它的主要工作就是摳標(biāo)準(zhǔn)，畢竟它是一款基于 W3C 標(biāo)準(zhǔn)的高性能渲染引擎。
最后，我勸淘寶領(lǐng)導(dǎo)定Kpi要理智些，畢竟Hippy4我還蠻期待的。
滴滴出品的超輕量級(jí)動(dòng)態(tài)化跨端開發(fā)框架，主打輕量和實(shí)用。
Hummer 以 JS 引擎為基石，目前已支持 JavaScriptCore、Hermers、QuickJS 等業(yè)內(nèi)知名 JS 引擎（這里本來還有個(gè)V8的，我刪除了，源碼里面沒有，Kpi需要）。再配合經(jīng)過調(diào)優(yōu)的 Yoga 布局引擎，抹平了兩端視圖布局差異（性能更佳的自研布局引擎開發(fā)中）。順便提一下，Hippy采用V8（功能更強(qiáng)）自研布局引擎（性能更佳）。
Hummer 的特點(diǎn)是拋棄了業(yè)界其他動(dòng)態(tài)化跨端框架普遍使用的DSL層和VDOM層，因此原生 Hummer 不具備前端開發(fā)常用的響應(yīng)式編程的能力，但同時(shí)換來的是接近原生開發(fā)的體驗(yàn)和性能。再以原生 Hummer 為基礎(chǔ)，在此之上開發(fā)了一套基于MVVM架構(gòu)的開發(fā)框架 —— Tenon ，通過 Tenon，可以把使用 Vue/React 編寫的代碼，轉(zhuǎn)換成原生 Hummer 的代碼。
Hummer也是一個(gè)小程序平臺(tái)，而且超輕量。如果想要無限提升自己APP的能力，可以考慮嵌入Hummer。
Web移動(dòng)前端框架正在迎來第三個(gè)高速發(fā)展期，各類框架得到極大繁榮。
個(gè)人在具體項(xiàng)目的貢獻(xiàn)已經(jīng)微乎其微了，創(chuàng)新、架構(gòu)創(chuàng)新是唯一制勝的手段，這也是我看好React的根本原因。
最后，還是想做點(diǎn)微不足道的 探索 ，現(xiàn)在前端組件庫(kù)層出不窮，更換組件庫(kù)帶來的代價(jià)有點(diǎn)大。想創(chuàng)建一個(gè)框架，來實(shí)現(xiàn)上次說的組件公約數(shù)和公倍數(shù)，無縫切換組件庫(kù)。理論上支持所有組件庫(kù) ，也能為后來者提供彎道超車的機(jī)會(huì)。我想大廠可能沒有需求，也不會(huì)愿意發(fā)布這種框架，畢竟都是平臺(tái)部門說了算。
這個(gè)庫(kù)就是useMobile，當(dāng)然分為useMobileReact和useMobileVue。下次先發(fā)布useMobileReact。等我發(fā)布后，再來填上面表中缺的推薦度。
原文地址：
既然要承載 web 頁(yè)面，一個(gè)原生的 WebView 必不可少。在 iOS 中，目前已經(jīng)有兩款高性能、功能齊全的 web 瀏覽器，UIWebView (=2.0)和 WKWebView(=7.0)。
當(dāng)然，兩種 web 瀏覽器選其一即可。網(wǎng)上有很多文章，包括我之前已經(jīng)發(fā)表的博文中，都介紹過這兩種瀏覽器，讀者可以根據(jù)自己的需要選擇。
就目前的情況看，UIWebView 發(fā)展了很多年，目前市面上大部分的 web 頁(yè)面也都支持這樣的瀏覽器，因此很多公司在選擇的時(shí)候都使用這個(gè)，但是，我們知道，WKWebView 有太多改善前者的優(yōu)點(diǎn)，而且也是蘋果官方提倡大家使用的，為了性能，為了更多的特性，建議初次搭建的朋友采用 WKWebView。
為了實(shí)現(xiàn) h5 與 native 之間的互相調(diào)用，我們需要在兩者之間架一層橋來實(shí)現(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 頁(yè)面加載的信息，也可以讓 web 頁(yè)面動(dòng)態(tài)執(zhí)行一些腳本做一些事。
總之，在 web 容器框架中，這個(gè) bridge 還是很有必要的。
嗯，這個(gè)是輔助項(xiàng)，做了這一步可以進(jìn)一步提高 web 容器的加載性能，而且資源緩存到本地后可以做到不依賴網(wǎng)絡(luò)，提高用戶體驗(yàn)。
通常有兩種做法，
UIWebView 使用簡(jiǎn)單，而且現(xiàn)在用戶的手機(jī)性能也已經(jīng)不再是頁(yè)面展示性能的瓶頸，所以，這里介紹的依然采用 UIWebView 作為 web 瀏覽器。
WebViewJavascriptBridge 是一款非常強(qiáng)大的第三方開源 bridge 庫(kù)，同時(shí)支持 UIWebView 和 WKWebView。
git 地址
NJKWebViewProgress 是一款能使 UIWebview 顯示加載進(jìn)度的第三方開源框架，支持代理協(xié)議處理和 progressview 展示兩種功能。
git 地址
重慶分公司
重慶分公司
