這是一個最好的時代,也是一個最壞的時代 －－ 狄更斯
以下所有内容僅代表筆者個人的思考，水準有限，必有謬誤。文無第一，錯了必改。
有一個問題我時常在思考：如果WP沒有失敗，現在市場占有率能在30%左右，移動市場上是android、iOS、WP三分天下的話，現在的無線開發人員，該怎麼樣開發一款app？我們會不會保持現在的無線開發模式，建立android、iOS、WP三個開發團隊進行app的開發？
如果帶着這樣的假設來審視我們現在的開發模式的話，那我們一定會問，現在的開發模式是否過重？同樣的業務功能，我們如何進行多端、多app的透出？我們如何能夠做到我們的功能能夠盡快的傳遞到使用者的手上？
這裡我不打算讨論h5 app與native app的争論，在可以預見的未來，我們可以看到hybrid app的開發會是相當長時間内的主流。在hybrid的基礎上，無線開發亟待解決的問題主要是兩個：
開發效率
動态釋出
就開發效率開始，我們先簡單看看有哪些跨平台開發的模式。
本質上，真正意義上的跨平台是不存在的。隻是在具體實作上，平台的特性（異性）在哪一層被封裝有所不同。舉例來說，html運作環境的平台異性是通過浏覽器核心予以封裝的，而java則是通過JVM。
實作跨平台應用有幾種可能的選擇：
CrossApp以C++作為引擎開發語言，圖形渲染基于OpenGL ES 2.0，采用MVC架構模式。現在正在整合SpiderMonkey，後續打算支援JS直接開發App（這個路子是不是有點熟？）。去年我稍微撸了一下CrossApp的源代碼，貌似不少代碼是借鑒cocos2dx的。
通過做遊戲的思路做app，這條實作路徑我表示懷疑，現在也的确沒聽說有爆款app的産生。
C++ -- portable code
這種方式的特點是能不能跨平台，能跨多少平台都是由運作時架構決定的：
Java -- portable bytecode
C# -- portable bytecode
個人觀點：Swift的發展軌迹和C#還是挺像的，都是為了解決應用開發效率問題應運而生，大廠借助平台優勢進行強勢推廣，開發者熱情如火...最後，我們可以看看最後會怎麼樣。最近一直在傳Swift要成為android的"first class language"，這個事情我是不信的，有些事情知道就好。
通過一種殼語言和自定義的解析器進行文法解析，連結到操作平台的原生API進行功能操作，這種方式可以說是當下跨平台開發的一種主流模式（也是各個大廠積極探索的方向）。相比前兩種方式，這種方式的好處在于既能夠繞過稽核機制進行動态分發，動态分發的代碼又能夠擁有原生的功能與體驗。這種方式大概也是所有方式中唯一可以兼顧 提高開發效率與實作動态釋出 的方案。
這種方式大概的分層圖如下：

Interpreter與bridge在其中隻是抽象的層次概念，interpreter用于進行殼語言的解析與原生提供的功能的映射關系（可以看作自定義的協定解析），bridge用于殼語言與原生語言的互動（或綁定）。具體到真正的實作上，基于殼語言與native接口的通信路徑的選擇不同，子產品劃分與上下層關系可能會略有差别。比如說，它的結構也有可能是這個樣子的：
講到這裡，深深地感到沒有講清楚，那就拿weex舉個例子（一切以weex的presentation slides為準）。
weex的殼語言示例如下：
webview裡應該跑不起來吧。看下架構圖上述代碼是如何進行運轉的（圖是從weex的presentation slides裡截的，紫色底的标注是我打的）：
這種方式的劣勢有二：
殼語言的文法定義比較靈活（随意），是以會明顯帶來學習曲線的問題。通常的解決辦法是DSL使用html加javascript（加入的功能與标簽都是自己做的擴充，并非真正意義上的國際标準）。
目标app不接你的架構（interpreter or bridge)你就瞎，還是需要做h5的降級方案。
因為portable DSL有着同時解決開發效率與動态釋出問題的好處（可能性），是以下一部分就着這點接着講。
來到阿裡之初，聽到大家談論h5的開發時，我的内心還是頗為惶恐的，因為在我印象裡，h5是這個樣子的：

那麼我們一直在談的h5到底是什麼呢(答案引自知乎）：
H5 最早的出處，現在已經很難說清了。
不過這也無可厚非，現在幾乎所有網際網路從業人員嘴上都挂着這個詞。我試着總結了一下，H5 基本可以代表這麼幾個意思：
H5 使用手冊（使用範圍：中國）
以微信營銷為首的廣告、活動類傳播頁
高逼格叫法：互動營銷
慣用者：廣告，新媒體人、網際網路營運
狂霸酷炫叼的桌面/響應式網頁（模版）
高逼格叫法：@優秀網頁設計
慣用者：外圍設計師，甲方，“網頁開發愛好者”，小白級微部落客
與 Native 開發相對應的使用 web 語言開發手機 App 的技術
高逼格叫法：Mobile Web, Web App，Hybrid App
慣用者：幾乎已經是網際網路行業共識。産品，Native 程式員
近幾年各種前端技術進化的總稱……
相關概念：SPA，NodeJS，CSS 3, ES 6 …
慣用者：前端團隊命名，前端招聘……
與 Flash 技術相對應的在 PC 端實作大量多媒體互動的網頁技術
相關概念：Canvas，CSS 3，SVG，HTML5 Video
慣用者：Flasher，甲方，設計師
與 Flash, Unity3D 等技術相對應的網頁遊戲技術
相關概念：Canvas，WebGL，ThreeJS
慣用者：頁遊行業
與 Cocos2D 等遊戲開發技術對應的手機遊戲開發技術
相關概念：H5 手遊，Canvas
慣用者：手遊行業
HTML 5 API
慣用者：前端工程師
好吧你說什麼就是什麼
慣用者：接外包/私活中的前端程式員
現在我已經很習慣使用術語h5了，本文前部分提h5已經很溜了。當你發現一件事情的解釋成本太高的時候，為了順暢地溝通，最好的方式就是适應它。
當我們在說native的時候，我們到底在說什麼？一個通俗的解釋就是除去h5的其餘技術部分，包括但不限于android的java、iOS的OC，還有c/c++。至此我們完成了一個完美的循環證明，無線技術分兩塊：h5與native，h5就是不屬于native的那部分，native就是不屬于h5的那部分。
當下我們在移動應用開發中提到的“native”當出自“native app”，即指向系統提供的原生能力的使用。如果說我們當下日常使用中對于“h5”已經意義寬泛化了的話，那麼我們可能對“native”可能已經意義窄化了。很多時候，我們在談“native”的時候僅僅是在談“native UI”。
回歸到正題，這裡既然需要談一下portable DSL的開發方式，那麼就說下我對“native”在這種開發方式下的了解：本質上portable DSL提供的是一種能夠通過解釋執行的語言，通過解釋執行的語言賦予這種開發方式以更高的開發效率與定制化能力；“native”在其中是指為了完成底層架構的一種需要編譯才能獲得的系統能力。
這種開發方式在PC時代并不罕見，不少ERP軟體（由于ERP軟體的特殊性，所有企業幾乎都需要進行定制化地二次開發）提供的都是一個基礎架構，實際在企業上線前都需要通過腳本語言去二次開發自定義的操作界面與業務流程。
下一部分就是今年北京QCon基于portable DSL的移動動态化方案的分享。
今年四月去北京參加QCon2016，移動開發中很大一塊集中在動态化方案上（另一塊是直播，今年真是直播大年）。
在動态化方案上，一共聽了4個講座：
<a href="http://yunpan.alibaba-inc.com/share/link/D3VEVGdVU9">老樹開新花: LuaView － Lua在聚劃算App動态化中的應用</a>
<a href="http://yunpan.alibaba-inc.com/share/link/E3VEVGiVHA">Hybrid app走向輕混</a>
<a href="http://yunpan.alibaba-inc.com/share/link/A3VEVGiVHE">ReactMix: HTML+CSS+JS寫ReactNative</a>
Weex與LuaView都是阿裡的産品
Weex算是React Native的競品：據說Weex中借鑒了不少Vue.js的文法，是以說是Vue Native，問題也不太大。
LuaView用的是相對古典的思路：Lua在遊戲app裡的應用是非常廣泛的。在過去的很多年中，也有不斷的嘗試規模化地用于應用類app的開發中。LuaView在其中算是走的比較靠前的（具體内容可以翻閱PPT）。
兩個方案的優劣我就不評論了（水準不夠），隻想着重提兩個點：
殼語言的學習和使用成本是重中之重
工程化的能力決定一切
ReactMix是基于RN的開發，補齊了css特性，實作“write once，run anywhere”。
這個分享是接着Weex的分享的，思路有些不同。感興趣的同學可以搜一下知乎，可以看到一些相關讨論，連結我就不放了。
對于RN，我比較贊同的是兩個理念：
“learn once, write anywhere”
virtual DOM
對于ReactMix，我倒是有兩個疑慮：
“write once, run anywhere”的願景很美好，但是卻很難。當能花80%的平台差異性可以通過20%的努力來完成時，後面的20%可能需要80%的努力來做，可能還到不到。換句話說，靈活性與一緻性不可兼得
DOM和CSS基本是性能殺手了，支援CSS全特性其實是在打破RN本身的假設
分析技術也并不複雜，有三個特點：
封裝了微信的sdk，是以開發的應用頁面可以無縫跑在微信裡（可以将WeX5看成是微信生态圈裡的産品）
實作了一個開發工具鍊，可以通過拖、拉、拽的方式完成WeX5的界面開發
主要優化集中在h5端，對于native的功能依賴不高，對于密集互動型的場景和渲染密集型的場景考慮不足
這種思路算是比較古典的開發方式了，但是的确像分享人所說的
其他技術的頁面都沒法在微信裡跑（隻要你沒适配微信sdk）
比較适合小團隊冷啟動（因為不用安裝app，隻需要微信掃碼）
技術上的亮點稍微有些乏善可陳。
WeX5的結構
移動平台的web化是趨勢，當下的問題，我們能看到，就需要努力去通過技術變革的手段去解決。現在正處于技術變革的時代，變革意味着機會。也許我們現在正處在一個移動開發最壞的時代，也許我們現在正處在移動開發最好的時代。