開發(fā)一個ios的app采用的技術(shù)架構(gòu)是什么呀？

開發(fā)一個ios程序一般使用C/S構(gòu)架，屬于分布式架構(gòu)的一種。也就是使用云+端的模式。阿里云提供的有PaaS和IaaS服務(wù)，這樣比較傳統(tǒng)開發(fā)，節(jié)約了總體擁有成本，簡化了開發(fā)和部署。

專注于為中小企業(yè)提供成都做網(wǎng)站、網(wǎng)站建設(shè)服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)岳陽縣免費(fèi)做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了上千家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實(shí)現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。

剛剛，阿里開源 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é)程 化支持，本文將為大家詳細(xì)介紹coobjc的設(shè)計(jì)理念及核心優(yōu)勢。

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

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

針對多線程以及尤其引發(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)隊(duì)基于長期對系統(tǒng)底層庫和匯編的研究，通過匯編和C語言實(shí)現(xiàn)了支持 Objective-C 和 Swift 協(xié)程的完美解決方案 —— coobjc。

核心能力

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

coobjc設(shè)計(jì)

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

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

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

核心實(shí)現(xiàn)原理

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

我們基于線程的代碼執(zhí)行時候，是沒法做出暫停操作的，我們現(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)就是要針對不同cpu實(shí)現(xiàn)一套，我們目前實(shí)現(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的實(shí)際使用就不過多介紹了，感興趣的朋友可以去官方github倉庫自行下載查看。

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

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

我們在手機(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ù)邏輯，通過測試驗(yàn)證，這樣的改造在低端機(jī)(iPhone6及以下的機(jī)器)上的幀率有20%左右的提升。

簡明

易用

清晰

性能

程序是寫來給人讀的，只會偶爾讓機(jī)器執(zhí)行一下。——Abelson and Sussman

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

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

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

移動APP開發(fā)框架盤點(diǎn)2：Web移動前端框架大全

開源項(xiàng)目其實(shí)有一個成熟周期，這個周期大概是三年左右，自React框架在2013年發(fā)布并引爆了前端框架的大潮，這個屬于前端的周期就此開始了。

之后在2015年5月開源的React Native又開啟了屬于Web移動前端的周期，15-16年，18-19年，21-22年正好就是屬于移動前端的三個爆發(fā)點(diǎn)。

三年前，在第一個成熟收獲期，我盤點(diǎn)了移動開發(fā)框架。在這第二個成熟收獲期，理所當(dāng)然要來盤點(diǎn)一波。

不過，當(dāng)我點(diǎn)開github項(xiàng)目的code-frequency時，還是被這個準(zhǔn)到嚇人的周期猜想驚呆了，先給你們看一波，剩下的自行驗(yàn)證。

1、

2、

再來說第二個比較有意思的發(fā)現(xiàn)，停止維護(hù)的項(xiàng)目絕大多數(shù)是Vue框架項(xiàng)目。

盤點(diǎn)開始的時候我還覺得React框架處于絕對劣勢，到完成時我發(fā)現(xiàn)React無論在選擇面還是成熟度上都超過了Vue。

原因我這里就不分析了，反正大家都有自己的看法。

網(wǎng)頁類框架就是前端組件框架，這一次雖然有大量項(xiàng)目停止維護(hù)，但是也有很多項(xiàng)目堅(jiān)持了下來，而且還涌現(xiàn)出了一批新項(xiàng)目。

大廠占了主導(dǎo)，因?yàn)檫@些年大廠在移動開發(fā)上的需求，遠(yuǎn)高于其它方面。個人項(xiàng)目要堅(jiān)持確實(shí)不易。

本來是想要做一個驗(yàn)證項(xiàng)目，把所有框架都試用一遍并給出推薦度的。由于進(jìn)度太慢，還是下一次再發(fā)吧。

這次的重點(diǎn)是漸進(jìn)類框架，就是所謂多端同構(gòu)框架（小程序框架）。這幾年國內(nèi)的重點(diǎn)的各種小程序平臺，所以多端框架的需求很是旺盛。

不過大多數(shù)先行者都沒挺過來還是讓我很意外，只有Taro成功了，想想還是有很多讓人唏噓的東西。

在這里還是先預(yù)測一波吧，因?yàn)檫@一類框架最變化最大，最終還是有很多框架要出局的。

漸進(jìn)類框架是一個過渡性的產(chǎn)品，最終會變成橋接類框架的一部分，所以，與橋接類框架協(xié)同才是框架的出路。

這個賽道基本全是大廠了。

騰訊新一代跨端開發(fā)框架Hippy

Hippy一看就是淘寶Weex的對標(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ū)動 UI 指令生成；中間層 C++ HippyCore 負(fù)責(zé)抹平平臺差異性和提供高性能模塊；渲染層 Android 和 iOS 負(fù)責(zé)提供終端底層模塊、組件，并與布局引擎通信。

對Weex慘遭遺棄，我上次就說過：「ReactNative提供工具，Weex提供框架，將平臺差異化屏蔽（Write Once, Run Everywhere）。所以Weex則注定功能相對弱小，并且坑比較多?！筗eex最終下馬也是必然的，淘寶又發(fā)布升級版北海，為了實(shí)現(xiàn)（Write Once, Run Everywhere），它采用自繪，而且是基于Flutter自繪。

所以Hippy3.x就一如既往的Kpi功能層層加碼，很有騰訊風(fēng)格。在未來的 3.x 中業(yè)務(wù)與渲染層中的具體實(shí)現(xiàn)可根據(jù)用戶實(shí)際場景進(jìn)行切換：業(yè)務(wù)層上不再局限于 JS 驅(qū)動，還可選擇（如：DSL/Dart/WASM 等）其它語言進(jìn)行驅(qū)動；在渲染層中，渲染引擎除了支持現(xiàn)有原生（Native）渲染之外，還可以選擇其他渲染 Renderer，如 Flutter(Voltron) 渲染。

「Kraken 北海」是一款高性能Web渲染引擎。底層基于 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 會執(zhí)行相關(guān)邏輯并創(chuàng)建一系列需要發(fā)送給 Dart 層處理的指令。

Kraken 其實(shí)就是一個小程序平臺，而且追求全平臺完全一致。我雖然認(rèn)為各平臺不一致是很自然的事情，但是也表示理解，畢竟別人吹牛有當(dāng)真的傳統(tǒng)（KFC表示認(rèn)同）。

Kraken 現(xiàn)在也是一個小號瀏覽器，所以它的主要工作就是摳標(biāo)準(zhǔn)，畢竟它是一款基于 W3C 標(biāo)準(zhǔn)的高性能渲染引擎。

最后，我勸淘寶領(lǐng)導(dǎo)定Kpi要理智些，畢竟Hippy4我還蠻期待的。

滴滴出品的超輕量級動態(tài)化跨端開發(fā)框架，主打輕量和實(shí)用。

Hummer 以 JS 引擎為基石，目前已支持 JavaScriptCore、Hermers、QuickJS 等業(yè)內(nèi)知名 JS 引擎（這里本來還有個V8的，我刪除了，源碼里面沒有，Kpi需要）。再配合經(jīng)過調(diào)優(yōu)的 Yoga 布局引擎，抹平了兩端視圖布局差異（性能更佳的自研布局引擎開發(fā)中）。順便提一下，Hippy采用V8（功能更強(qiáng)）自研布局引擎（性能更佳）。

Hummer 的特點(diǎn)是拋棄了業(yè)界其他動態(tài)化跨端框架普遍使用的DSL層和VDOM層，因此原生 Hummer 不具備前端開發(fā)常用的響應(yīng)式編程的能力，但同時換來的是接近原生開發(fā)的體驗(yàn)和性能。再以原生 Hummer 為基礎(chǔ)，在此之上開發(fā)了一套基于MVVM架構(gòu)的開發(fā)框架 —— Tenon ，通過 Tenon，可以把使用 Vue/React 編寫的代碼，轉(zhuǎn)換成原生 Hummer 的代碼。

Hummer也是一個小程序平臺，而且超輕量。如果想要無限提升自己APP的能力，可以考慮嵌入Hummer。

Web移動前端框架正在迎來第三個高速發(fā)展期，各類框架得到極大繁榮。

個人在具體項(xiàng)目的貢獻(xiàn)已經(jīng)微乎其微了，創(chuàng)新、架構(gòu)創(chuàng)新是唯一制勝的手段，這也是我看好React的根本原因。

最后，還是想做點(diǎn)微不足道的 探索 ，現(xiàn)在前端組件庫層出不窮，更換組件庫帶來的代價有點(diǎn)大。想創(chuàng)建一個框架，來實(shí)現(xiàn)上次說的組件公約數(shù)和公倍數(shù)，無縫切換組件庫。理論上支持所有組件庫 ，也能為后來者提供彎道超車的機(jī)會。我想大廠可能沒有需求，也不會愿意發(fā)布這種框架，畢竟都是平臺部門說了算。

這個庫就是useMobile，當(dāng)然分為useMobileReact和useMobileVue。下次先發(fā)布useMobileReact。等我發(fā)布后，再來填上面表中缺的推薦度。

原文地址：

當(dāng)前文章：iosapp開發(fā)框架,安卓ios開發(fā)框架
文章鏈接：http://m.newbst.com/article2/dssihic.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供搜索引擎優(yōu)化、服務(wù)器托管、網(wǎng)站策劃、小程序開發(fā)、網(wǎng)站營銷、面包屑導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)