本文作者：鄒達(dá)，APICloud CTO，10 年來一直專注于移動瀏覽器引擎研究，參與過國內(nèi)外多個瀏覽器引擎，Javascript 引擎和跨平臺應(yīng)用引擎架構(gòu)和開發(fā)。

如果說以前的微信公眾號還是一個媒體化的平臺，那么 2016 年的公眾號會有一種新的形態(tài)，叫應(yīng)用號。應(yīng)用號預(yù)示著比公眾號更強(qiáng)大的功能、更優(yōu)質(zhì)的體驗以及更豐富的服務(wù)。應(yīng)用號的出現(xiàn)是微信產(chǎn)品的一次重大升級，無論是為了體現(xiàn)用戶價值觀？還是追求產(chǎn)品商業(yè)化？作為一名技術(shù)人員，我不想過多討論，而是更愿意從技術(shù)的角度來分析一些其中 Web 技術(shù)的發(fā)展。

微信做為一款超級 App，有著巨大的入口流量，需要不斷的產(chǎn)生動態(tài)的內(nèi)容，Web 技術(shù)在微信中一直發(fā)揮中重要的作用。如果說公眾號還是標(biāo)準(zhǔn) Web 技術(shù)＋簡單橋接擴(kuò)展，那么在應(yīng)用號中，Web 技術(shù)將依靠更強(qiáng)大的 Web 執(zhí)行容器在微信中發(fā)揮更大的作用。我們可以來看看在微信中 Web 與 Native 技術(shù)的結(jié)合過程，從嵌入系統(tǒng) Webview, 到 X5 增強(qiáng)瀏覽器引擎，到功能擴(kuò)展的 JS-SDK，再到剛剛發(fā)布的 weUI，再到應(yīng)用號。微信團(tuán)隊一直推進(jìn)著 Web 技術(shù)在 Native App 中融合與發(fā)展。

隨著移動設(shè)備的快速更新?lián)Q代，以 HTML5 為代表的 Web 技術(shù)在 NativeApp 中有了越來越多的應(yīng)用場景。一方面是 Native App 開發(fā)團(tuán)隊在保證功能和性能的同時，需要提高開發(fā)效率，降低運營成本；另一方面是 App 用戶在滿足需求和體驗的同時，需要更快的獲取動態(tài)的內(nèi)容；這些都需要 Web 技術(shù)在 App 開發(fā)中發(fā)揮越來越多的作用和價值。但這種價值絕對不能稱為脫離或顛覆。在今天，更多的是 “融合”！

我從 06 年開始做了 10 年瀏覽器引擎和跨平臺 App 引擎。見證了這 10 年來，Web 技術(shù)在 Native App 中不斷的應(yīng)用和發(fā)展。從功能機(jī)到智能機(jī)，從 k-java 到移動 App，從 WebBrowser 到 Webkit，我們可以將 Web 技術(shù)在 Native App 中的發(fā)展分為 5 個階段，內(nèi)置、嵌入、橋接、混合、融合。

一 . 內(nèi)置自定義 Web 容器時代

2010 年之前，那時還是 feature phone 為主流的時代，硬件配置低，系統(tǒng)功能弱，手機(jī)應(yīng)用以內(nèi)置為主。但 SP 業(yè)務(wù)已得到長足的發(fā)展，用戶需要動態(tài)獲取內(nèi)容來滿足資訊和娛樂的需求。這個時期 Web 技術(shù)在 Native 應(yīng)用中的使用方式是 Native 應(yīng)用開發(fā)商與瀏覽器廠商合作，在應(yīng)用中內(nèi)置某個廠商的瀏覽器引擎，作為 Web 的執(zhí)行容器。應(yīng)用從服務(wù)器端動態(tài)下載 web 文件，解壓后交給 Web 容器離線運行。內(nèi)容和功能都很簡單，通常就是圖片＋文字的排版，以及按鍵交互。形式如圖書、雜志、小游戲以及小工具等。這類需求也驅(qū)動了當(dāng)時一些主流瀏覽器廠商去思考瀏覽器的在傳統(tǒng)價值以外的作用，并積極參與到 W3C Widget 規(guī)范的制訂。這一時期也是移動瀏覽器廠商的黃金時代。

二. 嵌入系統(tǒng) Webview 時代

2010 年，Android 系統(tǒng)在國內(nèi)興起，iPhone 也逐漸普及，以 Android 和 iOS 為主的原生應(yīng)用生態(tài)系統(tǒng)開始不斷的培養(yǎng)用戶到 AppStore 下載應(yīng)用，以及以獨立 App 作為入口的使用習(xí)慣。這一時期 App 開發(fā)需求也逐漸增長，但是競爭還不算激烈。客戶可以接受原生的開發(fā)成本和周期。應(yīng)用開發(fā)商利潤豐厚，開發(fā)者紛紛開始學(xué)習(xí) Android 和 iOS App 開發(fā)。系統(tǒng)自帶瀏覽器的功能和性能已經(jīng)超過當(dāng)時的第三方瀏覽器。在 App 中通過嵌入系統(tǒng) Webview 來展示本地或服務(wù)器端的界面已經(jīng)比較常見。這一時期 Web 技術(shù)的應(yīng)用以內(nèi)容展示為主，所能完成的功能被限制在標(biāo)準(zhǔn)瀏覽器支持的范圍內(nèi)。而傳統(tǒng)瀏覽器廠商依靠 Lisence 收費的商業(yè)模式終結(jié)，并且逐漸淡出市場。

三 .Webview 的橋接擴(kuò)展時代

2011 年， Android 和 iOS 在手機(jī)系統(tǒng)中逐漸已經(jīng)占據(jù)了統(tǒng)治地位。App 開發(fā)需求迅速增長，競爭加劇，原生開發(fā)人員供不應(yīng)求，客戶開始考慮成本和周期，開發(fā)商開始考慮效率和利潤。開發(fā)者開始思考 Webview 在展示內(nèi)容之外是否還可以完成部分 App 功能。由于系統(tǒng)內(nèi)置的都是 Webkit 引擎，支持標(biāo)準(zhǔn)的 Web 技術(shù)，并且支持開放擴(kuò)展。國內(nèi)外以 Phone Gap 為代表的廠商開始了對 Webview 的橋接擴(kuò)展，并且形成一套完整的調(diào)用機(jī)制，在 JS 中可以任意調(diào)用原生接口。

這種橋接擴(kuò)展主要集中于設(shè)備功能，提供的是一種能力，但是更多具體的映射還需要開發(fā)者自己來完成。由于沒有涉及窗口系統(tǒng)、交互響應(yīng)、動畫效果，事件管理以及應(yīng)用生命周期管理等的擴(kuò)展，所以雖然開發(fā)出的 App 基本功能可以滿足需求，但是性能和體驗太差。此時通過 Webview＋橋接擴(kuò)展的方式，原生工程師和 Web 工程師一起協(xié)作已經(jīng)可以完成一款 App 的開發(fā)了。這一時期標(biāo)準(zhǔn) Web 技術(shù)（HTML，CSS，JS）和橋接擴(kuò)展機(jī)制在移動 App 中的使用趨勢也造成了一批傳統(tǒng)的使用非標(biāo)準(zhǔn) web 技術(shù)（自定義 XML 標(biāo)簽和 JS 語法）的移動中間件廠商的消亡。

四. 移動應(yīng)用開發(fā)平臺的 Hybrid App 時代

從 2012 年開始，App 創(chuàng)業(yè)火爆，App 需求持續(xù)增長，有了更多的應(yīng)用場景和行業(yè)結(jié)合：LBS，IoT，O2O，社交、視頻等等。一方面是使用 HTML＋CSS 進(jìn)行界面布局存在 Dom 樹更新及單層渲染的性能問題，而且標(biāo)準(zhǔn) JavaScript 規(guī)范支持的能力非常有限，需要大量的擴(kuò)展來滿足行業(yè)需求；另一方面是原生開發(fā)模式成本高、效率低，行業(yè)呼喚更高效的跨平臺開發(fā)模式。

這一時期，國內(nèi)外跨平臺技術(shù)也是層出不窮，不斷涌現(xiàn)出新的產(chǎn)品，但我們可以其他們分為兩類：

? 一類是繼續(xù)堅持使用 HTML＋CSS 進(jìn)行界面布局，通過對頁面渲染進(jìn)行優(yōu)化和對標(biāo)準(zhǔn) JS 進(jìn)行原生擴(kuò)展來實現(xiàn)跨平臺 App 開發(fā)。

? 另一類是放棄使用 HTML＋CSS 的界面布局，選擇一種第三方的中間語言（如 JS，C# 等）來映射成 Android 和 iOS 的系統(tǒng)調(diào)用，從而實現(xiàn)跨平臺。這種方式的界面布局需要通過中間語言組合系統(tǒng) UI 組件來完成，目前看渲染性能是比 HTML＋CSS 的方式要好些，但這樣也失去了 HTML＋CSS 布局的標(biāo)準(zhǔn)性和靈活便捷。

本文探討的主要是 Web 技術(shù)在 App 中的發(fā)展過程，不可能沒有 HTML 和 CSS，所以這里我們將集中討論第一類的跨平臺產(chǎn)品（Web＋Native 混合）。像 ReactNative 雖然他所選擇的第三方語言是 JS，但是他也可以選擇其他語言，由于 HTML 和 CSS 已經(jīng)不是其界面布局的方式，所以我認(rèn)為其已經(jīng)脫離了標(biāo)準(zhǔn)的 Web 的技術(shù)，這里不再過多討論。

此時國內(nèi) HTML5 也逐漸火熱，大量的 Web 程序員期待進(jìn)入 Native App 的開發(fā)領(lǐng)域。此時，面向 Web 工程師的移動應(yīng)用開發(fā)平臺（Web＋Native 混合）開始出現(xiàn)，提供了一站式的跨平臺 App 開發(fā)和管理服務(wù)，形成了一種新的 Web 技術(shù)與 Native App 相結(jié)合的模式。

HybridApp 是一個以 Web 技術(shù)為主的 Native App 開發(fā)模式，開發(fā)者不需要具備任何的 Native 技能，使用標(biāo)準(zhǔn)的 web 技術(shù)，通過調(diào)用平臺的擴(kuò)展 API，就可以開發(fā)出獨立的跨平臺 App。并且能保證 App 的功能、性能和體驗。

Hybrid App 引擎需要在橋接擴(kuò)展的基礎(chǔ)上提供更多的功能，如：

1. MVC 架構(gòu)；

2. 應(yīng)用生命周期和統(tǒng)一事件管理；

3. 優(yōu)化交互響應(yīng)、動畫效果、數(shù)據(jù)緩存等；

4. Web 界面與 Native 組件的混合渲染；

5. 豐富的獨立功能模塊與聚合開放平臺 API；

6. 對主流 HTML 編輯器進(jìn)行擴(kuò)展來支持 App 開發(fā)；

7. App 安全機(jī)制及 Web 代碼全包加密；

這一時期出現(xiàn)了優(yōu)秀跨平臺 App 引擎，如 APICloud DeepEngine，通過 Deep Engine 在降低開發(fā)成本，提高開發(fā)效率的同時，可以開發(fā)出滿足客戶需要和用戶運行體驗的商用 App。基于 APICloud，客戶也開發(fā)出了安裝量過千萬的主流優(yōu)質(zhì)應(yīng)用。

五. 基于 SuperWebview 的融合時代

進(jìn)入 2016 年，雖然 Hybrid App 已經(jīng)被行業(yè)廣泛認(rèn)可，但是目前 Native 還仍是主流的開發(fā)模式，大多數(shù)優(yōu)質(zhì) App 都是原生的。如何能在這些 Native App 中使用 Web 技術(shù)？如何能在這些主流 App 中使用 Web 技術(shù)完成部分功能的同時，又能保證 App 的性能和體驗？如何能讓 Native 工程師和 Web 工程師能更好的協(xié)作？

對于這些問題，我們不能只是嵌入一個系統(tǒng) Webview，或引入一套橋接擴(kuò)展機(jī)制，而是需要一個功能強(qiáng)大完整的超級 Webview，并且是為每一個應(yīng)用根據(jù)實際配置動態(tài)生成專屬的 SDK。這種超級 Webview 應(yīng)具備的如下功能：

1. 功能強(qiáng)大，具備 MVC 架構(gòu)和性能優(yōu)化；

2. 聚合 API，支持?jǐn)U展模塊和開放平臺服務(wù)；

3. 動態(tài)生成，根據(jù)配置，為每個應(yīng)用動態(tài)生成專屬的 SDK；

4. 云修復(fù)，實現(xiàn)應(yīng)用內(nèi)更新功能。

方便協(xié)作，保持 Web 和 Native 開發(fā)的獨立性，降低融合成本，提高效率。

APICloud 在 2016 年開年推出的這款超越性產(chǎn)品——SuperWebview，SuperWebview 的出現(xiàn)必將加速 Web 技術(shù)在 Native App 中的融合，并且在優(yōu)質(zhì)的 Native App，甚至超級 App 中發(fā)揮更大的作用。任何一款 Native App 在集成 SuperWebview 之后，都可以大幅縮短迭代周期，支持功能的動態(tài)增加。由 Web 技術(shù)實現(xiàn)部分的功能更新無需再反復(fù)提交 AppStore 審核。用戶也無需重新下載安裝。

開發(fā)一款 App，到底誰當(dāng)主角？是 Native＋Web，還是 Web＋Native？那要看誰更適合當(dāng)主角，誰當(dāng)主角才能把戲演好。一部好戲不能只有一個主角，配合互補(bǔ)才能演出好戲。

NativeApp 伴隨著移動設(shè)備而生，Web 技術(shù)也是自出生就與 Native App 互補(bǔ)和共存。APICloud 從未想過 “顛覆”，只是想提供一種實實在在的高效的 App 開發(fā)方式，讓 Web 技術(shù)和 NativeApp 能夠更好的融合，發(fā)揮出各自應(yīng)有的優(yōu)勢和價值。

超越源于融合！

請關(guān)注我們 加速會 官方微信公號： jiasuhuihao 獲取最時尚、最前沿的互聯(lián)網(wǎng)資訊。