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

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

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

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

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

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

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

隨著技術的發(fā)展很自然又出現(xiàn)了對***代移動中間件編程技術的改進模型，其結構如下圖所示：

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

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

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

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

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

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