[[149563]]

在移動(dòng)開(kāi)發(fā)領(lǐng)域我們發(fā)現(xiàn)一個(gè)很奇怪的現(xiàn)象：普通菜鳥(niǎo)新手經(jīng)過(guò)3個(gè)月的培訓(xùn)就可以拿到 8K 甚至上萬(wàn)的工作；在北京稍微有點(diǎn)工作經(jīng)驗(yàn)的 iOS 開(kāi)發(fā)，就要求 2 萬(wàn)一個(gè)月的工資。不知道大家是否想過(guò)：移動(dòng)應(yīng)用開(kāi)發(fā)已經(jīng)在市場(chǎng)上火熱了這么多年了，為什么很多公司還仍然會(huì)面臨移動(dòng)開(kāi)發(fā)人才稀缺的問(wèn)題呢？對(duì)于移動(dòng)開(kāi)發(fā)人才的增長(zhǎng)速度總是趕不上市場(chǎng)需求發(fā)展的原因，我認(rèn)為不應(yīng)該簡(jiǎn)單歸為市場(chǎng)供求關(guān)系的問(wèn)題，其源動(dòng)力還是來(lái)自移動(dòng)應(yīng)用整體的開(kāi)發(fā)模式和開(kāi)發(fā)效率低下的內(nèi)因。正是這強(qiáng)大的市場(chǎng)需求和低下的原生開(kāi)發(fā)效率結(jié)合在一起才導(dǎo)致了這幾年軟件開(kāi)發(fā)行業(yè)人才的嚴(yán)重失衡，導(dǎo)致大家沒(méi)辦法也只能漲工資的方式來(lái)?yè)屓瞬拧榇宋覀円恢痹趯ふ腋咝詢r(jià)比的應(yīng)用開(kāi)發(fā)方案（實(shí)現(xiàn)低成本投入和高品質(zhì)的產(chǎn)出），盡可能的降低應(yīng)用開(kāi)發(fā)復(fù)雜性。應(yīng)用復(fù)雜性的本質(zhì)是邏輯和控制，邏輯決定了代碼復(fù)雜性的下限，而控制則包括對(duì)應(yīng)用環(huán)境和設(shè)備環(huán)境的進(jìn)一步優(yōu)化。我們常抱怨應(yīng)用不夠簡(jiǎn)潔的最根本原因：就是其沒(méi)能處理好邏輯與控制之間的耦合。說(shuō)到應(yīng)用復(fù)雜度的解耦，最常見(jiàn)的解決方案就是通過(guò)元語(yǔ)言抽象讓邏輯和控制進(jìn)行分離，也就是人們通常所說(shuō)的中間件方案。先普及一下：什么叫元語(yǔ)言？簡(jiǎn)單說(shuō)，元語(yǔ)言就是對(duì)應(yīng)用語(yǔ)法和語(yǔ)義的配置，對(duì)應(yīng)的元數(shù)據(jù)則是對(duì)這些配置的具體描述。也就是說(shuō)元既是數(shù)據(jù)也是代碼。為了能說(shuō)清楚這個(gè)問(wèn)題，讓我們來(lái)簡(jiǎn)單回顧一下中間件開(kāi)發(fā)技術(shù)的發(fā)展歷史：

最早也是最基礎(chǔ)的應(yīng)用開(kāi)發(fā)方式是元編程(Meta Programming)：也就是從元語(yǔ)言到目標(biāo)語(yǔ)言的編譯器，將元數(shù)據(jù)編譯為目標(biāo)程序代碼的開(kāi)發(fā)過(guò)程。元編程的模式要求我們要面向具體設(shè)備進(jìn)行編程，每種設(shè)備在操作系統(tǒng)基礎(chǔ)上會(huì)提供給開(kāi)發(fā)者大量的api服務(wù)，最終的應(yīng)用的源代碼經(jīng)過(guò)編譯和鏈接兩個(gè)過(guò)程生成可以直接運(yùn)行的應(yīng)用程序。雖然開(kāi)發(fā)過(guò)程的復(fù)雜度較高，但元編程生成應(yīng)用的執(zhí)行效率確實(shí)非常高。采用元編程方式的開(kāi)發(fā)工具包括：匯編語(yǔ)言、c語(yǔ)言、PowerBuilder、VC、Objective-C等。我們可以通過(guò)下圖來(lái)理解元編程：

元編程之后，緊接著就出現(xiàn)了元驅(qū)動(dòng)編程(Meta Driven Programming) ：它是直接在目標(biāo)語(yǔ)言中實(shí)現(xiàn)元語(yǔ)言的解釋器，這是支撐中間件技術(shù)的基礎(chǔ)方式。元驅(qū)動(dòng)編程帶來(lái)的***的好處就是我們不必再面向具體的設(shè)備進(jìn)行編程，元語(yǔ)言需要先預(yù)編譯成中間代碼，中間代碼對(duì)于不同類型設(shè)備的適配工作完全可以交給“運(yùn)行時(shí)引擎”去完成，從而達(dá)到了“write once and run anyway”的能力。 采用元驅(qū)動(dòng)編程方式的開(kāi)發(fā)工具包括：Java、Flex、.Net等。我們可以通過(guò)下圖來(lái)理解元驅(qū)動(dòng)編程的模型：

這些年比較流行的應(yīng)該還是元解釋編程（Meta Interpretive Programming）：它可以讓元語(yǔ)言直接運(yùn)行在不同的目標(biāo)環(huán)境中，這也就是我們所說(shuō)的腳本語(yǔ)言編程。由于省去了編譯和預(yù)編譯的過(guò)程，代碼的語(yǔ)法檢查的過(guò)程只能在運(yùn)行期間完成，理論上講這會(huì)降低應(yīng)用的執(zhí)行的效率。但隨著計(jì)算機(jī)硬件性能不斷的提升，性能問(wèn)題已經(jīng)被越來(lái)越弱化，同時(shí)元解釋編程簡(jiǎn)潔強(qiáng)大的語(yǔ)法也大大提高了應(yīng)用的開(kāi)發(fā)速度，也降低了程序的復(fù)雜度。采用元解釋編程方式的開(kāi)發(fā)工具包括：Javascript、Python、Lua等。我們可以通過(guò)下圖來(lái)理解元驅(qū)動(dòng)編程的模型：

為什么在移動(dòng)互聯(lián)時(shí)代，很多傳統(tǒng)應(yīng)用開(kāi)發(fā)的規(guī)則都不再適用了呢？讓我們來(lái)對(duì)比一下移動(dòng)設(shè)備和傳統(tǒng)計(jì)算機(jī)體系結(jié)構(gòu)之間的差異，看看移動(dòng)設(shè)備到底在結(jié)構(gòu)上發(fā)生了哪些重要的變化。首先移動(dòng)設(shè)備去掉操作系統(tǒng)的緩存，為了控制個(gè)體應(yīng)用對(duì)系統(tǒng)造成的任何不良影響，在應(yīng)用的物理內(nèi)存不夠時(shí)，該應(yīng)用馬上就會(huì)強(qiáng)制退出。 這就是app開(kāi)發(fā)中為什么一點(diǎn)點(diǎn)的內(nèi)存問(wèn)題就會(huì)產(chǎn)生閃退的根本原因，也是我們?cè)陧?xiàng)目中需要通過(guò)底層原生編程來(lái)優(yōu)化app穩(wěn)定性的必要原因之一。另外由于移動(dòng)操作系統(tǒng)中個(gè)體應(yīng)用獨(dú)立化的設(shè)計(jì)，讓系統(tǒng)級(jí)的運(yùn)行時(shí)引擎無(wú)處加載，這自然也就顛覆了元驅(qū)動(dòng)編程在app開(kāi)發(fā)中應(yīng)用的可行性，于是程序員們就又要重新開(kāi)始尋找移動(dòng)中間件技術(shù)的解決方案了。

***代移動(dòng)中間件的編程(HTML5 Based App Programming)是基于HTML5技術(shù)的跨平臺(tái)app開(kāi)發(fā)模型。在這個(gè)模型中一般都通過(guò)內(nèi)嵌的webkit內(nèi)核來(lái)實(shí)現(xiàn)原生擴(kuò)展代碼的橋接，用HTML5構(gòu)建網(wǎng)頁(yè)UI，用網(wǎng)頁(yè)中的Javascript編寫業(yè)務(wù)代碼。在這個(gè)模型下HTML5技術(shù)天生就具備跨平臺(tái)的能力，而且很多傳統(tǒng)的網(wǎng)站開(kāi)發(fā)程序員在技術(shù)上也可以很自然的過(guò)度。采用***代移動(dòng)中間件模型的產(chǎn)品包括：PhoneGap平臺(tái)、數(shù)字天堂中間件產(chǎn)品、烽火中間件產(chǎn)品等。我們可以通過(guò)下圖來(lái)理解***代移動(dòng)中間件產(chǎn)品的模型：

在***代移動(dòng)中間件技術(shù)的發(fā)展過(guò)程，吸引了大量傳統(tǒng)的web程序員，很多人都希望能夠通過(guò)html5技術(shù)進(jìn)入app開(kāi)發(fā)的陣營(yíng)里。但經(jīng)過(guò)幾年內(nèi)大量的嘗試后我們發(fā)現(xiàn)，市場(chǎng)上主流app開(kāi)發(fā)工作仍然還是要交給原生開(kāi)發(fā)人員完成，幾年下來(lái)用Html5開(kāi)發(fā)出來(lái)的優(yōu)質(zhì)app在應(yīng)用商店里仍然是鳳毛麟角。html5的交互體驗(yàn)?zāi)芰驮鷄pp開(kāi)發(fā)之間的差距似乎越來(lái)越大了，雖然硬件設(shè)備的高速發(fā)展解決了部分html5頁(yè)面運(yùn)行效率的問(wèn)題，但android和IOS每次大版本升級(jí)在UI交互能力上的提高卻讓html5技術(shù)有點(diǎn)越來(lái)越望塵莫及了。

隨著技術(shù)的發(fā)展很自然又出現(xiàn)了對(duì)***代移動(dòng)中間件編程技術(shù)的改進(jìn)模型，其結(jié)構(gòu)如下圖所示：

在改進(jìn)模型中的變化主要體現(xiàn)在兩個(gè)方面：首先是對(duì)原生擴(kuò)展能力進(jìn)行了進(jìn)一步增強(qiáng)。除了對(duì)文件、照相機(jī)、通訊錄等本地能力的擴(kuò)展外，還增強(qiáng)了對(duì)原生UI框架的擴(kuò)展能力以及對(duì)第三方服務(wù)的擴(kuò)展能力；另外改進(jìn)模型中還增加了擴(kuò)展模塊的概念對(duì)外提供開(kāi)放平臺(tái)，允許開(kāi)發(fā)者擴(kuò)展自己開(kāi)發(fā)原生組件。雖然改進(jìn)的模型在很大程度上了增強(qiáng)了HTML5和原生的原生交互能力，但***的技術(shù)瓶頸仍然能解決，即對(duì)于基礎(chǔ)UI的構(gòu)建還是只能通過(guò)網(wǎng)頁(yè)方式實(shí)現(xiàn)。開(kāi)發(fā)者仍然需要通過(guò)網(wǎng)頁(yè)渲染來(lái)模擬原生交互，所不同的只是可以通過(guò)網(wǎng)頁(yè)內(nèi)的javascript再去調(diào)用一些原生擴(kuò)展功能而已。目前采用***代移動(dòng)中間件改進(jìn)模型的產(chǎn)品包括：Appcan、APICloud、HBuilder等。

HTML5技術(shù)是***代移動(dòng)中間件技術(shù)發(fā)展的核心動(dòng)力，但隨著IT技術(shù)的發(fā)展，它也成為了移動(dòng)中間件技術(shù)進(jìn)一步發(fā)展的***瓶頸。無(wú)論大家在***代中間件的改進(jìn)模型多么努力，卻始終改變不了WebView的單線程模型、改變不了DOM/CSS的復(fù)雜而低效的排版和渲染水平、改變不了瀏覽器通過(guò)內(nèi)嵌Cavas、WebGL和定時(shí)器來(lái)實(shí)現(xiàn)動(dòng)畫的在用戶體驗(yàn)效果上的失敗。 很多人都還在幻想著HTML5會(huì)成為App的未來(lái)，要知道HTML5這項(xiàng)Web時(shí)代的技術(shù)本身就不是為移動(dòng)互聯(lián)時(shí)代而生的，HTML5的骨子里根本就不具備移動(dòng)互聯(lián)的基因，它與App的未來(lái)實(shí)際已經(jīng)是漸行漸遠(yuǎn)了。

Facebook在2015年初重磅推出了React Native移動(dòng)開(kāi)發(fā)中間件技術(shù)，在結(jié)構(gòu)上完全擺脫了HTML5的束縛，真正開(kāi)啟了一套通過(guò)自定義原生控件渲染UI的框架的道路，我們可以稱之為第二代移動(dòng)中間件的編程(Meta Extended App Programming)。我們可以通過(guò)下圖來(lái)理解該模型：

Facebook在React Native產(chǎn)品中所提出的 “Learning once, write anywhere” 本身也是一種復(fù)用的思想。大家厭煩了各種各樣的編程語(yǔ)言，如果有一種語(yǔ)言真的能夠統(tǒng)一移動(dòng)開(kāi)發(fā)領(lǐng)域，對(duì)于所有人都是好事。先不說(shuō)這個(gè)框架后續(xù)是否能得到大眾認(rèn)可，單從源碼來(lái)說(shuō)，這個(gè)框架源碼里有非常多的設(shè)計(jì)思想和實(shí)現(xiàn)方式值得學(xué)習(xí)。React Native產(chǎn)品雖然在實(shí)用性還有很大的不足，但它***的價(jià)值則是為移動(dòng)中間件技術(shù)提供了全新的發(fā)展思路?；蛟S很多人還沒(méi)有關(guān)注到，2015年中旬的時(shí)候一款DeviceOne的移動(dòng)中間件產(chǎn)品正式對(duì)外發(fā)布，它對(duì)React Native產(chǎn)品架構(gòu)進(jìn)行全面的繼承和改進(jìn)，不僅實(shí)現(xiàn)了跨平臺(tái)移動(dòng)開(kāi)發(fā)的“Write once, run anywhere”能力（同時(shí)支持IOS、Android、Windows10），還實(shí)現(xiàn)了原生開(kāi)發(fā)擴(kuò)展平臺(tái)的完全開(kāi)放。我們來(lái)研究一下這第二代移動(dòng)中間件的改進(jìn)模型吧：

在DeviceOne這個(gè)模型中所有UI組件功能組件都已經(jīng)被抽象成可被自由擴(kuò)展的跨平臺(tái)組件，就連Webkit本身在模型中也僅僅退化成一個(gè)普通的UI組件而已，App開(kāi)發(fā)者可以自由選擇js腳本、lua腳本甚至python腳本來(lái)編寫業(yè)務(wù)邏輯，讓昂貴的原生開(kāi)發(fā)人員能夠更專注于底層技術(shù)創(chuàng)新和組件封裝，讓應(yīng)用開(kāi)發(fā)人員可以更加專注于具體項(xiàng)目的業(yè)務(wù)需求，實(shí)現(xiàn)原生開(kāi)發(fā)和應(yīng)用開(kāi)發(fā)的分離，也就是讓邏輯和控制充分解耦。

隨著移動(dòng)互聯(lián)時(shí)代的高速發(fā)展，人類對(duì)“低成本高品質(zhì)”app開(kāi)發(fā)技術(shù)的需求越來(lái)越迫切。Fred Brooks在人月神話中曾闡述的 “沒(méi)有銀彈”理論一直以來(lái)對(duì)IT界產(chǎn)生了很深的影響：他認(rèn)為不存在一種技術(shù)能使得軟件開(kāi)發(fā)在生產(chǎn)力、可靠性、簡(jiǎn)潔性方面提高一個(gè)數(shù)量級(jí)。但在我看來(lái)也不一定要那么悲觀了，凡事都沒(méi)那么絕對(duì)，任何原則都有其假設(shè)的前提和范圍，如果超過(guò)這個(gè)范圍，原則可能都要失效了。例如：如果超出了宇宙大爆炸基點(diǎn)的范圍，我們就會(huì)失去任何參照物，那么就連時(shí)間概念同時(shí)也都會(huì)消失，更何況Fred Brooks的理論呢？雖然“沒(méi)有銀彈”理論在軟件工程范圍內(nèi)是被普遍認(rèn)可的，但我們這并不能僅以此就推理出 “低成本高品質(zhì)”的需求是無(wú)解的。App的開(kāi)發(fā)技術(shù)的發(fā)展歷程不是可簡(jiǎn)單線性描述，也更不會(huì)局限于軟件工程理論的范圍內(nèi)。就像Kevin Kelly在《失控》中所說(shuō)的那樣，IT技術(shù)應(yīng)該更貼近大自然自身的發(fā)展規(guī)律。工業(yè)時(shí)代的標(biāo)志是機(jī)械設(shè)計(jì)能力的登峰造極，而以IT技術(shù)為代表的新生物文明則應(yīng)使設(shè)計(jì)再次回歸自然。React native和Device one的出現(xiàn)就讓我們看到了app開(kāi)發(fā)的新希望，這可能就是我們期待了已久的移動(dòng)中間件技術(shù)發(fā)展拐點(diǎn)。凡事不破不立，React native通過(guò)擴(kuò)展標(biāo)簽的方式實(shí)現(xiàn)了去HTML5化，而Device one繼而則在支持跨平臺(tái)的同時(shí)還還進(jìn)一步實(shí)現(xiàn)了去中心化，按照這樣思路再發(fā)展下去移動(dòng)中間件技術(shù)的未來(lái)將會(huì)是怎樣的呢？一旦我們能通過(guò)分布式的、至下而上的去中心化控制系統(tǒng)來(lái)激發(fā)大量個(gè)體（開(kāi)發(fā)者）的差異化發(fā)展，就能夠***限度的實(shí)現(xiàn)整個(gè)系統(tǒng)的自學(xué)習(xí)和自遞增，當(dāng)系統(tǒng)的進(jìn)化進(jìn)而再反過(guò)來(lái)再影響和改變個(gè)體的時(shí)候，那么軟件開(kāi)發(fā)的生產(chǎn)力、可靠性、簡(jiǎn)潔性可能就會(huì)在每次迭代過(guò)程中實(shí)現(xiàn)突破，甚至能以指數(shù)級(jí)別的速度開(kāi)啟全新的增長(zhǎng)…