從中間件的歷史來看移動App開發的將來

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

　　最先也是最基礎的應用開發方式是元編程(Meta Programming)：也就是從元語言到目標語言的編譯器，將元數據編譯爲目標程序代碼的開發過程。元編程的模式要求咱們要面向具體設備進行編程，每種設備在操做系統基礎上會提供給開發者大量的api服務，最終的應用的源代碼通過編譯和連接兩個過程生成能夠直接運行的應用程序。雖然開發過程的複雜度較高，但元編程生成應用的執行效率確實很是高。採用元編程方式的開發工具包括：彙編語言、c語言、PowerBuilder、VC、Objective-C等。咱們能夠經過下圖來理解元編程：

 

　　元編程以後，緊接着就出現了元驅動編程(Meta Driven Programming) ：它是直接在目標語言中實現元語言的解釋器，這是支撐中間件技術的基礎方式。元驅動編程帶來的最大的好處就是咱們沒必要再面向具體的設備進行編程，元語言須要先預編譯成中間代碼，中間代碼對於不一樣類型設備的適配工做徹底能夠交給「運行時引擎」去完成，從而達到了「write once and run anyway」的能力。 採用元驅動編程方式的開發工具包括：Java、Flex、.Net等。咱們能夠經過下圖來理解元驅動編程的模型：

 

　　這些年比較流行的應該仍是元解釋編程（Meta Interpretive Programming）：它可讓元語言直接運行在不一樣的目標環境中，這也就是咱們所說的腳本語言編程。因爲省去了編譯和預編譯的過程，代碼的語法檢查的過程只能在運行期間完成，理論上講這會下降應用的執行的效率。但隨着計算機硬件性能不斷的提高，性能問題已經被愈來愈弱化，同時元解釋編程簡潔強大的語法也大大提升了應用的開發速度，也下降了程序的複雜度。採用元解釋編程方式的開發工具包括：Javascript、Python、Lua等。咱們能夠經過下圖來理解元驅動編程的模型：

 

　　爲何在移動互聯時代，不少傳統應用開發的規則都再也不適用了呢？讓咱們來對比一下移動設備和傳統計算機體系結構之間的差別，看看移動設備到底在結構上發生了哪些重要的變化。首先移動設備去掉操做系統的緩存，爲了控制個體應用對系統形成的任何不良影響，在應用的物理內存不夠時，該應用立刻就會強制退出。 這就是app開發中爲何一點點的內存問題就會產生閃退的根本緣由，也是咱們在項目中須要經過底層原生編程來優化app穩定性的必要緣由之一。另外因爲移動操做系統中個體應用獨立化的設計，讓系統級的運行時引擎無處加載，這天然也就顛覆了元驅動編程在app開發中應用的可行性，因而程序員們就又要從新開始尋找移動中間件技術的解決方案了。

　　第一代移動中間件的編程(HTML5 Based App Programming)是基於HTML5技術的跨平臺app開發模型。在這個模型中通常都經過內嵌的webkit內核來實現原生擴展代碼的橋接，用HTML5構建網頁UI，用網頁中的Javascript編寫業務代碼。在這個模型下HTML5技術天生就具有跨平臺的能力，並且不少傳統的網站開發程序員在技術上也能夠很天然的過分。採用第一代移動中間件模型的產品包括：PhoneGap平臺、數字天堂中間件產品、烽火中間件產品等。咱們能夠經過下圖來理解第一代移動中間件產品的模型：

 

　　在第一代移動中間件技術的發展過程，吸引了大量傳統的web程序員，不少人都但願可以經過html5技術進入app開發的陣營裏。但通過幾年內大量的嘗試後咱們發現，市場上主流app開發工做仍然仍是要交給原生開發人員完成，幾年下來用Html5開發出來的優質app在應用商店裏仍然是百裏挑一。html5的交互體驗能力和原生app開發之間的差距彷佛愈來愈大了，雖然硬件設備的高速發展解決了部分html5頁面運行效率的問題，但android和IOS每次大版本升級在UI交互能力上的提升卻讓html5技術有點愈來愈可望不可即了。

　　隨着技術的發展很天然又出現了對第一代移動中間件編程技術的改進模型，其結構以下圖所示：

 

　　在改進模型中的變化主要體如今兩個方面：首先是對原生擴展能力進行了進一步加強。除了對文件、照相機、通信錄等本地能力的擴展外，還加強了對原生UI框架的擴展能力以及對第三方服務的擴展能力；另外改進模型中還增長了擴展模塊的概念對外提供開放平臺，容許開發者擴展本身開發原生組件。雖然改進的模型在很大程度上了加強了HTML5和原生的原生交互能力，但最大的技術瓶頸仍然能解決，即對於基礎UI的構建仍是隻能經過網頁方式實現。開發者仍然須要經過網頁渲染來模擬原生交互，所不一樣的只是能夠經過網頁內的javascript再去調用一些原生擴展功能而已。目前採用第一代移動中間件改進模型的產品包括：Appcan、APICloud、HBuilder等。

 　　HTML5技術是第一代移動中間件技術發展的核心動力，但隨着IT技術的發展，它也成爲了移動中間件技術進一步發展的最大瓶頸。不管你們在第一代中間件的改進模型多麼努力，卻始終改變不了WebView的單線程模型、改變不了DOM/CSS的複雜而低效的排版和渲染水平、改變不了瀏覽器經過內嵌Cavas、WebGL和定時器來實現動畫的在用戶體驗效果上的失敗。 不少人都還在幻想着HTML5會成爲App的將來，要知道HTML5這項Web時代的技術自己就不是爲移動互聯時代而生的，HTML5的骨子裏根本就不具有移動互聯的基因，它與App的將來實際已是漸行漸遠了。

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

 

　　Facebook在React Native產品中所提出的 「Learning once, write anywhere」 自己也是一種複用的思想。你們厭煩了各類各樣的編程語言，若是有一種語言真的可以統一移動開發領域，對於全部人都是好事。先不說這個框架後續是否能獲得大衆承認，單從源碼來講，這個框架源碼裏有很是多的設計思想和實現方式值得學習。React Native產品雖然在實用性還有很大的不足，但它最大的價值則是爲移動中間件技術提供了全新的發展思路。或許不少人尚未關注到，2015年中旬的時候一款DeviceOne的移動中間件產品正式對外發布，它對React Native產品架構進行全面的繼承和改進，不只實現了跨平臺移動開發的「Write once, run anywhere」能力（同時支持IOS、Android、Windows10），還實現了原生開發擴展平臺的徹底開放。咱們來研究一下這第二代移動中間件的改進模型吧：

 

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

　　隨着移動互聯時代的高速發展，人類對「低成本高品質」app開發技術的需求愈來愈迫切。Fred Brooks在人月神話中曾闡述的 「沒有銀彈」理論一直以來對IT界產生了很深的影響：他認爲不存在一種技術能使得軟件開發在生產力、可靠性、簡潔性方面提升一個數量級。但在我看來也不必定要那麼悲觀了，凡事都沒那麼絕對，任何原則都有其假設的前提和範圍，若是超過這個範圍，原則可能都要失效了。例如：若是超出了宇宙大爆炸基點的範圍，咱們就會失去任何參照物，那麼就連時間概念同時也都會消失，更況且Fred Brooks的理論呢？雖然「沒有銀彈」理論在軟件工程範圍內是被廣泛承認的，但咱們這並不能僅以此就推理出 「低成本高品質」的需求是無解的。App的開發技術的發展歷程不是可簡單線性描述，也更不會侷限於軟件工程理論的範圍內。就像Kevin Kelly在《失控》中所說的那樣，IT技術應該更貼近大天然自身的發展規律。工業時代的標誌是機械設計能力的登峯造極，而以IT技術爲表明的新生物文明則應使設計再次迴歸天然。React native和Device one的出現就讓咱們看到了app開發的新但願，這可能就是咱們期待了已久的移動中間件技術發展拐點。凡事不破不立，React native經過擴展標籤的方式實現了去HTML5化，而Device one繼而則在支持跨平臺的同時還還進一步實現了去中心化，按照這樣思路再發展下去移動中間件技術的將來將會是怎樣的呢？一旦咱們能經過分佈式的、至下而上的去中心化控制系統來激發大量個體（開發者）的差別化發展，就可以最大限度的實現整個系統的自學習和自遞增，當系統的進化進而再反過來再影響和改變個體的時候，那麼軟件開發的生產力、可靠性、簡潔性可能就會在每次迭代過程當中實現突破，甚至能以指數級別的速度開啓全新的增加…