摘要：一直以來(lái)，程序員對(duì)移動(dòng)跨平臺(tái)的追求就沒(méi)有停止努力，跨平臺(tái)是為了提高開(kāi)發(fā)效率，隨著帶來(lái)的必然是性能的降低。特別是隨著微信的崛起，這種方式已經(jīng)應(yīng)用很廣了，微信承載了一個(gè)統(tǒng)一跨平臺(tái)的瀏覽器功能，而且能調(diào)用不少原生功能。

移動(dòng)開(kāi)發(fā)這些年，移動(dòng)開(kāi)發(fā)者人數(shù)越來(lái)越多，類似的培訓(xùn)公司發(fā)展也很快，不過(guò)伴隨著的是移動(dòng)應(yīng)用的需求這幾年發(fā)展更為旺盛。要開(kāi)發(fā)好的App，純?cè)_(kāi)發(fā)肯定是最佳選擇。但是這么多年發(fā)展，原生開(kāi)發(fā)的難度并沒(méi)有降低多少，特別是作為一個(gè)需要長(zhǎng)期運(yùn)營(yíng)的App，需要原生人員的長(zhǎng)期跟進(jìn)，人員成本很高。另外，從蘋(píng)果和Android的崛起開(kāi)始，為了支持截然不同的二個(gè)操作系統(tǒng)，相當(dāng)于二套開(kāi)發(fā)人員開(kāi)發(fā)二個(gè)功能完全的App，可想開(kāi)發(fā)效率的低下。

一直以來(lái)，程序員對(duì)移動(dòng)跨平臺(tái)的追求就沒(méi)有停止努力，跨平臺(tái)是為了提高開(kāi)發(fā)效率，隨著帶來(lái)的必然是性能的降低。但從軟件發(fā)展的歷史看，部分損失某一方面的性能來(lái)?yè)Q取效率的提高還是非常值得的。
就好像我們用c語(yǔ)言替代匯編，損失了掉的那些運(yùn)行效率基本是可以忽略不計(jì)的，我們換來(lái)的是開(kāi)發(fā)效率大幅提高，相對(duì)于匯編語(yǔ)言而言C語(yǔ)言同時(shí)也部分解決了跨平臺(tái)跨設(shè)備的問(wèn)題（至少不用再考慮對(duì)特定寄存器的編程了）。
同樣當(dāng)歷史發(fā)展到大量用Java替代C語(yǔ)言開(kāi)發(fā)的時(shí)候，我們損失掉了c語(yǔ)言的Native設(shè)備的開(kāi)發(fā)能力的同時(shí)，所換來(lái)的多線程開(kāi)發(fā)、分布式開(kāi)發(fā)、跨平臺(tái)開(kāi)發(fā)能力的增強(qiáng)，也完全符合www時(shí)代發(fā)展的需要的。

天然的，移動(dòng)開(kāi)發(fā)的程序員首先想到的H5和Webview，這是最容易實(shí)現(xiàn)的跨平臺(tái)方案。在H5的路上移動(dòng)開(kāi)發(fā)者們做了很多努力。純?cè)_(kāi)發(fā)我們暫時(shí)不提，光從跨平臺(tái)來(lái)說(shuō)，發(fā)展的歷程可以大概分3個(gè)階段：

純H5方式
由于web應(yīng)用已經(jīng)在PC應(yīng)用上占了半壁江山，最早的時(shí)候大家想著直接使用手機(jī)的系統(tǒng)瀏覽器加載一個(gè)網(wǎng)址，這最容易實(shí)現(xiàn)，顯然問(wèn)題很多，性能就不提了，其它方面，比如不同的瀏覽器適配很難，瀏覽器的安全性限制了大部分手機(jī)上的設(shè)備無(wú)法使用，存儲(chǔ)本地都受限制。但是這種方式并沒(méi)有消亡，它有一定的適應(yīng)范圍。特別是隨著微信的崛起，這種方式已經(jīng)應(yīng)用很廣了，微信承載了一個(gè)統(tǒng)一跨平臺(tái)的瀏覽器功能，而且能調(diào)用不少原生功能。很多想長(zhǎng)期運(yùn)營(yíng)的App都會(huì)有微信的入口，而且通常是先做微信推廣，再做App。

以上的方式還有一個(gè)明顯的缺陷就是應(yīng)用的差異性，桌面上沒(méi)有App的圖標(biāo)，大家都從瀏覽器或微信入口，對(duì)于一個(gè)長(zhǎng)期運(yùn)營(yíng)的想有一定知名度的應(yīng)用來(lái)說(shuō)肯定無(wú)法接受。
接下來(lái)移動(dòng)開(kāi)發(fā)者的想法就是用一個(gè)有自己圖標(biāo)和入口的原生的App的殼加載一個(gè)原生的Webview組件，然后加載網(wǎng)頁(yè)，同時(shí)通過(guò)js和原生的橋接技術(shù)來(lái)實(shí)現(xiàn)html和原生功能的調(diào)用。這種技術(shù)的代表是phonegap技術(shù)，它影響了國(guó)內(nèi)很多移動(dòng)開(kāi)發(fā)者和公司，有不少框架和技術(shù)都是基于或?qū)W習(xí)它。在它被改名之前，我們也完整下載和研究過(guò)它的代碼。
這個(gè)時(shí)期的應(yīng)用特點(diǎn)是：
＊ 整個(gè)核心就一個(gè)webview，里面頁(yè)面的切換都是本地網(wǎng)頁(yè)或web網(wǎng)頁(yè)的跳轉(zhuǎn)
＊ 沒(méi)有任何原生ui的參與，所有ui都是靠webview的標(biāo)簽。有一些簡(jiǎn)單原生ui可以以窗口的方式調(diào)用起來(lái)。
＊ 整個(gè)應(yīng)用的邏輯都是靠html里的js來(lái)驅(qū)動(dòng)。
＊ 能調(diào)用原生的一些基礎(chǔ)功能，比如攝像頭，存儲(chǔ)，數(shù)據(jù)庫(kù)等等。

這種方式起初還是有一定市場(chǎng)的，主要是開(kāi)發(fā)效率非常高，很多已有的PC端的網(wǎng)站改吧改吧就出來(lái)一個(gè)跨Andoid和iOS的應(yīng)用。但是這樣的應(yīng)用只能說(shuō)勉強(qiáng)能用，稍微復(fù)雜一點(diǎn)就連用都不能用了。性能和體驗(yàn)問(wèn)題是最主要的，更何況早期Android 2.x時(shí)代，iOS4.x，5.x時(shí)代手機(jī)的性能也不高。

2．H5和Native的混合 （Hybrid）
手機(jī)的性能越來(lái)越好，H5也越來(lái)越流暢，但是隨之而來(lái)的是好的原生App越來(lái)越多，H5在很多方面還是無(wú)法替代原生。于是越來(lái)越多的原生功能和H5混合在一起，形成了Hybrid開(kāi)發(fā)的模式。
這里我要說(shuō)跨平臺(tái)的發(fā)展分了二種思路或二個(gè)方向：
＊ 原生為主，更多的加入H5的元素，我們暫且稱之為Native/H5
＊ H5為主，更多的加入Native的元素, 我們暫且稱之為H5/Native

首先我們看Native/H5，這種應(yīng)用很多，而且是現(xiàn)有市場(chǎng)上的主流，特別是大型的優(yōu)秀的以內(nèi)容為主的App，代表是微信，天貓，京東這些App。里面都大量使用Webview加載大量網(wǎng)頁(yè)。因?yàn)樵母潞苈闊?，而那些需要大量?jī)?nèi)容更新的App必然會(huì)選擇Webview作為內(nèi)容承載。很顯然，這種方式并沒(méi)有降低多少成本，原生人員還是需要二套，內(nèi)容頁(yè)面還需要一套熟悉web技術(shù)等人員。

我們?cè)倏碒5/Native，國(guó)內(nèi)的代表應(yīng)該是Appcan，APICloud，wex5等移動(dòng)開(kāi)發(fā)平臺(tái)。這些框架的最早期就是我上面提到的純H5方式，慢慢加上更多的原生因素，比如一個(gè)webview改成多個(gè)webview，頁(yè)面上加入不少原生的ui元素，比如頁(yè)面的titlebar使用原生的ui，還有很多，他們一直在努力解決體驗(yàn)和性能的問(wèn)題。也有很多App產(chǎn)出了。國(guó)外也有很多框架，不少是通過(guò)html實(shí)現(xiàn)一套和原生樣子很像的ui組件。但是相比Native/H5, 我覺(jué)得H5/Native的發(fā)展思路不對(duì)。
我們來(lái)看看它們的區(qū)別，我們先來(lái)看二個(gè)App的截圖：

我使用了Android的開(kāi)發(fā)者模式，可以看到原生UI組件的邊框。我們可以看到他們的差別
＊ 天貓App的主要／主體頁(yè)面是純?cè)捻?yè)面，頁(yè)面上所有大大小小的元素都是原生的UI組件。而下面的截圖主體部分都是Webview組件，但是加入一些原生UI。
Native/H5的App所有核心的主要的界面都是純?cè)?，就像一棵?shù)一樣，通常只有到末端的內(nèi)容頁(yè)面是網(wǎng)頁(yè)。頁(yè)面的跳轉(zhuǎn)都是原生效果。H5/Native主要的框架界面也是Webview加載Html，很顯然，體驗(yàn)上和性能上來(lái)說(shuō)H5/Native要差很多。

＊ Native/H5的主要邏輯都是靠原生來(lái)驅(qū)動(dòng)。H5只是負(fù)責(zé)簡(jiǎn)單的頁(yè)面展示和很少的邏輯處理。H5/Native所有的邏輯處理都是靠Webview里的html里的js來(lái)處理。這一塊，性能相比又差了很多。另外復(fù)雜度上高了很多，webview只是原生眾多組件中的一個(gè)，由它來(lái)支撐和控制整個(gè)App基本上很難，很多開(kāi)發(fā)中的坑無(wú)法解決。

＊ 從成本上來(lái)說(shuō)，Native/H5只是稍微降低了一點(diǎn)成本，因?yàn)檫€是需要多套人馬。H5/Native的成本就降低了很多了，因?yàn)橹恍枰惶譿eb開(kāi)發(fā)人員。

JS/Lua和Native的混合
從上面我們可以看到Native/H5 和H5/Native 中間我們還需要再努力努力再尋求一個(gè)中間狀態(tài)，就是盡可能的不犧牲性能的基礎(chǔ)上再降低效率和成本。這幾年證明通過(guò)webview和H5的方式已經(jīng)無(wú)法再優(yōu)化了。

從Facebook的React Native開(kāi)始，一種新的趨勢(shì)已經(jīng)逐漸冒出來(lái)，他們的思路是從Native/H5為源頭，但是拋棄webview，保留js。Facebook自己相當(dāng)于重新設(shè)計(jì)了一套類似H5的規(guī)范，并設(shè)計(jì)類似一個(gè)webview的組件來(lái)解析這套規(guī)范，包括ui和js代碼。但是這里的標(biāo)簽對(duì)應(yīng)的都是可擴(kuò)展的純?cè)慕M件。
包括國(guó)內(nèi)的阿里推出的weex和LuaViewSDK，思想上和React Native類似的。

他們的思路就是從原生開(kāi)發(fā)人員的角度出發(fā)，盡量擴(kuò)大跨平臺(tái)的范圍，但是又不帶來(lái)體驗(yàn)的下降。這種趨勢(shì)應(yīng)該是正確的發(fā)展方向。

不過(guò)這幾個(gè)技術(shù)現(xiàn)在都是一個(gè)SDK，也就是并不能實(shí)現(xiàn)真正的跨平臺(tái)，做不到一套開(kāi)發(fā)人員，一套代碼就能發(fā)布多個(gè)平臺(tái)。就像React Native的口號(hào)是Learn Once，Write Anyway。

我要重點(diǎn)介紹一下國(guó)內(nèi)一個(gè)移動(dòng)開(kāi)發(fā)平臺(tái)Deviceone。Deviceone的發(fā)展走過(guò)我上面提過(guò)的所有階段，它經(jīng)歷是差不多4年，在內(nèi)部已經(jīng)有5個(gè)大版本的迭代了?？傮w來(lái)說(shuō)，也是長(zhǎng)期追求效率和性能的最優(yōu)化的一個(gè)結(jié)果。

Deviceone的特點(diǎn)是：
? deviceone有一個(gè)核心框架，可以理解為類似React Native一樣的SDK，可以解析自定義的ui標(biāo)簽和js／lua 代碼的功能。差別就是，deviceone定義的ui并不是類似h5，而是把ui代碼和js/lua代碼完全分開(kāi)成不同的文件。Ui文件通過(guò)IDE的拖拽功能來(lái)實(shí)現(xiàn)，然后通過(guò)屬性設(shè)置的方式，當(dāng)然也支持js/lua代碼訪問(wèn)。我們直觀的看看IDE里可視化ui的圖。

? deviceone并不只是一個(gè)能實(shí)現(xiàn)跨平臺(tái)的原生SDK，在這個(gè)框架的基礎(chǔ)上，deviceone對(duì)android，ios，windows的移動(dòng)基礎(chǔ)框架做了抽象，包括移動(dòng)系統(tǒng)基礎(chǔ)元素Activity，UIViewCotroller之類的，也標(biāo)準(zhǔn)化了事件機(jī)制，存儲(chǔ)管理，綁定機(jī)制，同步異步等等基礎(chǔ)結(jié)構(gòu)。目標(biāo)就是App開(kāi)發(fā)者無(wú)需了解Android，iOS技術(shù)的細(xì)節(jié)，用一套代碼實(shí)現(xiàn)真正的跨平臺(tái)，write once，run anyway。

? deviceone并沒(méi)有脫離原生開(kāi)發(fā)，只不過(guò)把原生開(kāi)發(fā)和App開(kāi)發(fā)者分離了，原生開(kāi)發(fā)者只負(fù)責(zé)開(kāi)發(fā)和業(yè)務(wù)無(wú)關(guān)的組件，比如Button，VideoView之類的。而App開(kāi)發(fā)者不需要理解操作系統(tǒng)的差異，只需要參考組件的一套JS／Lua的API，然后專心整理自己App的業(yè)務(wù)需求，就能搭建出跨平臺(tái)的App。

? deviceone最大的價(jià)值就是提供了一套組件重用的規(guī)范和標(biāo)準(zhǔn)，而且是跨平臺(tái)的組件。我們平常用原生開(kāi)發(fā)很多都是最基礎(chǔ)的代碼重用，組件重用也僅限于單個(gè)平臺(tái)。而deviceone的組件商店已經(jīng)積累了快100個(gè)跨平臺(tái)的原生組件了，是由deviceone官方和一些個(gè)人原生開(kāi)發(fā)者開(kāi)發(fā)的，有很多都開(kāi)源了，大家可以參考。目前正在以收費(fèi)組件的方式吸引更多原生開(kāi)發(fā)者參與。

? deviceone在現(xiàn)有的很多第三方組件基礎(chǔ)上由實(shí)現(xiàn)了跨平臺(tái)的封裝。大量的第三方平臺(tái)提供了優(yōu)質(zhì)的服務(wù)，通常原生開(kāi)發(fā)人員只需要集成android和ios都sdk就可以使用，大大簡(jiǎn)化了開(kāi)發(fā)人員的。我們?cè)谶@個(gè)基礎(chǔ)上又簡(jiǎn)化了一步，一套js的sdk就可以使用。我們已經(jīng)集成了很多常用的比如百度地圖，極光推送，幾個(gè)常用的支付，分享等等。

? deviceone提供了強(qiáng)大的可配置組件云打包系統(tǒng)，開(kāi)發(fā)者可以在100個(gè)組件里勾選自己需要的組件，然后打包成調(diào)試App和發(fā)布App。另外提供了很多配置項(xiàng)，盡量簡(jiǎn)化開(kāi)發(fā)者的工作。

? deviceone對(duì)外正式發(fā)布半年多，已經(jīng)積累了很多企業(yè)應(yīng)用，最近幾個(gè)月逐漸開(kāi)始積累不少個(gè)人應(yīng)用，感興趣的可以去蘋(píng)果的商店和android的市場(chǎng)上搜索一下“慧影時(shí)間流”，“納豆－點(diǎn)餐”，“愛(ài)搶劵”，“易經(jīng)造命”體驗(yàn)一下。這一個(gè)月應(yīng)該又有不少上線應(yīng)用，請(qǐng)多關(guān)注。

介紹了不少，感興趣可以去多關(guān)注國(guó)內(nèi)這個(gè)優(yōu)秀的產(chǎn)品，我相信不少移動(dòng)開(kāi)發(fā)者被國(guó)內(nèi)各種框架的“折磨”失去了對(duì)國(guó)內(nèi)移動(dòng)開(kāi)發(fā)平臺(tái)的信心，但是這個(gè)平臺(tái)值得你花一點(diǎn)時(shí)間去研究和體驗(yàn)。