深度解析混合開發技術成熟度曲線

衆所周知，HTML5技術自己具備許多優點。可是，若是HTML5想成爲移動互聯網時代App開發的主流技術，有一個必要的前提條件，就是它的功能、性能和API擴展能力上必需要達到Native的水平。而在這一點上，依靠W3C規範的定義和瀏覽器廠商的支持是不現實的，混合開發技術是惟一出路。

使人欣喜的是混合開發技術經歷了近10年的發展，今天終於足夠成熟，而且實現了大規模的商業應用。根據Gartner技術成熟度曲線模型的定義，混合開發技術已經具有「穩步攀升的光明期」要求的全部條件。

技術成熟度曲線模型 「技術成熟度曲線模型」是業界公認的、用於衡量一項技術成熟度的標準模型。Gartner做爲全球最權威的IT研究與顧問諮詢公司，每一年也是根據此模型來分析和推論各類技術的成熟度。

該模型認爲一項技術的發展能夠分爲5個階段，而且對每一個階段的邊界和特徵進行了明確的定義。

• 第一個階段-技術創新的啓動期：技術概念被提出、相關產品出現、媒體有報道、有早期用戶嘗試、行業應用可行性尚未證實

• 第二個階段-太高指望的高峯期：技術體系成型、更多相關產品發佈、媒體大肆報道、個別成功案例出現、過多、太高的不切實際的行業指望

• 第三個階段-泡沫出現的低谷期：技術侷限和缺點暴露、部分產品運營艱難甚至死掉、媒體興趣降低、一些用戶驗證失敗、行業前景不明

• 第四個階段-穩步攀升的光明期：技術特徵清晰而且被用戶理解、平臺化、組件化和生態化的產品出現、媒體從新認識、大規模和重量級的成功案例出現、行業應用前景明確

• 第五個階段-實質生產的高峯期：技術體系完備而且標準化，產品相關的生態和產業鏈蓬勃發展、媒體一致好評、成爲主流技術並普遍應用、行業應用穩定

混合開發技術的成熟度曲線 根據「技術成熟度曲線模型」的定義，咱們能夠繪製一條描述混合開發技術的成熟度曲線，因而可知證今天的混合開發技術正處於第四個階段的後期，並即將從「穩步攀升的光明期」邁入「實質生產的高峯期」。

咱們來簡單回顧一下混合開發技術的發展歷程：

第一個階段：2009～2012年左右，混合開發技術的概念被正式提出，此時已經有PhoneGap相似的產品在市場上發佈，而且有必定量的媒體報道。

第二個階段：2012～2015年左右，混合技術蓬勃發展而且被媒體大肆報道，2014年下半年HTML5標準定稿，同時市場上有更多混合開發技術的產品發佈，好比在2014年面世的APICloud，在2015年Facebook推出的ReactNative，此時行業對混合開發技術抱有很高的指望的。

第三個階段：2015～2016年左右，混合開發技術進入了一個低谷期，至少在行業用戶的眼中是一個低谷，這有多方面的緣由：

• 太高的指望形成在一些不適合的領域內應用

• 因爲不理解技術特色和原理，因此採用了不合理的開發方式

• 技術產品自己不夠成熟，在性能和兼容性方面還存在問題

• 學習資源太少和缺少優質的社區，開發者自己須要一個踩坑和成熟的過程

• 擴展模塊太少致使功能受限，這是最主要的緣由之一;開發者用混合技術開發一款app，最後發現大量的功能還須要本身經過Native來擴展，最典型的就是各種開放服務SDK的封裝，常見的例如：支付、地圖、推送、統計、客服、IM、IoT、AI等等，每一類服務又分不一樣的廠商，若是混合開發技術平臺自己不提供相應的模塊或插件，開發者就得本身封裝，這裏面的工做量和要踩的坑很是之多。

其實任何一門技術的成熟，必定須要經歷平臺化、組件化和生態化的發展過程，這個過程須要大量的開發者參與，而且須要大量的應用來驗證，使用者必定會遇到問題和挑戰，若是指望太高或者使用方式不正確，負面的評價和失望的結論就不免會出現。

第四個階段：在2016～2018年，混合開發技術逐漸成爲一項被人熟知的常規技術，用戶可以根據自身產品的研發需求天然的選擇和合理的使用。雖然媒體關注度有所降低，可是卻在實際應用中取得了實實在在的發展和完善，表現爲：技術特色逐漸被掌握、應用領域明確、功能覆蓋愈來愈全面、性能體驗顯著提高、一些優質的混合開發技術產品完成了平臺化、組件化和生態化的發展過程、大規模的成功應用案例，混合開發模式已經成爲一線互聯網公司App開發的主流開發模式。

第五個階段：將來，考慮到開發效率和成本，同時又要兼顧功能和體驗，純原生的開發模式會愈來愈少，基於HTML5的混合開發技術將成爲全行業移動應用開發的主流技術。混合開發的思想會被全部的用戶接受，混合開發技術的門檻會愈來愈低，而且逐漸造成一些標準化的產品。

混合開發技術處於光明期的6大特徵 下面就詳細闡述一下目前混合開發技術處於光明期的6大特徵

(1) 技術特色清晰，用戶可以正確使用混合開發技術

今天的開發人員對混合開發技術的特色已經有了充分了解，開發一款App，哪些功能可使用HTML5，哪些功能必需要用Native模塊擴展，詳細你們已經有了清晰的認識。怎樣應用混合技術對app開發很是重要，這裏總結以下幾點：

• HTML&CSS的解析：能用HTML+CSS來佈局的界面必定要用，HTML和CSS通過了這麼多年的發展，標準已經很是完備，佈局效率也是最高的。雖然HTML和CSS的解析須要一點時間，可是移動app的頁面一般都很小，元素也不多。只要咱們嚴格控制每個頁面中HTML和CSS代碼的大小，徹底按照產品設計來精細的編寫HTML和CSS代碼，不要引入重型的框架，不要出現無用的代碼，那麼這個解析過程對界面顯示速度的影響其實很小。

• Layout&Render的機制：瀏覽器的渲染機制與原生不一樣，瀏覽器的渲染須要通過Dom Tree-》Layout Tree-》Draw的過程，而且這個Draw的實現是在瀏覽器內部本身完成的，這決定了其渲染速度要比原生慢。特別是在移動app中表現得更明顯，由於在移動app中，用戶會進行頻繁的交互操做，例如：下拉刷新、界面滾動、手勢動畫等，這些操做效果引發的界面變化須要瀏覽器對整個界面進行重繪(從新Layout和Draw)，瀏覽器自己渲染的效率就不高，頻繁重繪形成的結果就表現爲閃屏、界面卡頓，用戶體驗差。因此，在混合開發必定要儘可能避免引發瀏覽器的重繪，要經過原生的機制(調用混合開發平臺的擴展API)實現下拉刷新、界面滾動、手勢動畫等會引發瀏覽器重繪的功能。其實HTML5界面的第一次渲染的用戶體驗並不差，由於打開新頁面用戶能夠接受有一個短暫的響應時間，並且一般界面切換會伴隨轉場動畫和加載過程。可是頻繁的瀏覽器重繪就會影響體驗。

• 界面切換和轉場效果：App的界面切換會伴隨各類轉場效果，這樣用戶的操做感好，交互體驗也好。HTML5的a標籤跳轉默認沒有動畫，SPA方式下div切換也沒有動畫，用HTML5的JS或CSS3來模擬這些Native窗口的的轉場效果體驗不好。在混合開發中app須要構造和原生同樣的多窗口UI結構，這樣就可使用原生的轉場效果，一般每個混合技術平臺都有本身的一套UI結構，諸如Widget、Layout、Window、Frame和UIModules組件。一款App若是有50個界面，那麼就須要構建50個Window，每個界面都是一個獨立的Window(Window是一個標準Native的窗口，可使用Native的界面切換和轉場效果)，在每個Window內部加載HTML5頁面。

• 網絡請求和數據存儲：標準HTML5在跨域異步請求、Socket通訊、異步和結構化的本地數據存儲、存儲容量、圖片和數據緩存等方面相比Native在功能和性能上還存在很大差距。混合開發中咱們須要經過原生方式實現這些功能，目前標準的混合開發技術平臺都會爲這些功能提供了封裝好的API，方便開發者調用。

• JavaScript的執行和橋接：不少開發者認爲因爲JavaScript是在瀏覽器主線程中執行，耗時的JavaScript操做會阻塞主線程，從而影響界面的渲染。其實任何耗時的操做，放在主線程中都會阻塞UI，在Native開發中也是同樣，在Native開發中，遇到耗時的操做咱們也要新起一個線程，不能將這部分代碼放到的UI線程中執行，不然同樣阻塞UI。耗時的JavaScript操做，例如：複雜的數據解析、數據加解密、複雜的運算等等，在混合開發的中，咱們須要將這些耗時的操做放到Native擴展模塊中來完成，在Native代碼中新起一個線程來執行。一樣，今天的混合開發技術平臺也都會爲這些耗時的功能提供標準化的擴展模塊。另外就是JavaScript與Native的橋接成本，其實不管這種橋接是經過映射仍是命令隊列來實現，相比於功能調用本事的執行成本，這部分的成本能夠忽略不計。

• 開放服務的集成和封裝：App中會用到不少的開放服務，經常使用的例如：支付、地圖、客服、統計、推送、IM、IoT通訊、各種AI識別等等。一般服務廠商都會提供Native版本的SDK，這些Native的SDK在HTML5沒法直接調用，JS版本的SDK要麼沒有，要麼功能不全。因此，混合開發中咱們須要經過原生的方式分別封裝不一樣廠商的Android和iOS版本的SDK，才能在本身的app中集成使用這些服務。而在有些混合開發平臺，已經已經封裝好了大部分主流開放服務的API，開發者能夠直接調用，下圖是APICloud的模塊Store中聚合的相關模塊。

其實，混合開發技術的本質就是要用Native技術來解決HTML5功能和性能的問題，哪些方面須要混合?如何進行混合?掌握混合技術的特色並正確使用則很是關鍵。

(2) 應用領域清晰，用戶根據自身需求正確選擇

任何應用均可以使用混合技術開發，關鍵仍是要根據自身需求來選擇。若是一款應用核心功能和大部分的界面都必需要原生實現，那麼就沒必須使用混合，例如遊戲、美圖等。若是隻有個別界面須要原生實現，其餘界面用HTML5沒問題，那就能夠採用混合，例如電商類app，商品分類、商品列表、商品詳情、購物車、訂單等界面用HTML5實現沒有問題並且效率更高，今天幾乎全部主流電商app(淘寶、京東、天貓等)都採用混合開發，混合開發技術已是電商app面向運營快速迭代的技術支撐。

(3) 功能覆蓋全面，用戶無需再花精力本身擴展

混合開發技術平臺通過這麼了多年的發展和完善，功能已經很是全面，基本能夠覆蓋app開發須要的全部功能。

(4) 性能體驗優化，已經基本達到原生的標準

今天，開發者已經很是清楚HTML5會存在哪些性能問題，在混合開發模式中，若是使用HTML5會產生性能問題，咱們就會經過原生擴展的方式來代替，咱們能夠合理的使用HTML5技術。因此現在使用混合技術開發的app，擁有和Naive同樣的UI結構和功能擴展，性能方面已經能夠達到Native的標準。

咱們對比分析了一款在APICloud平臺開發的電商app，分別與淘寶和京東兩款app在5個方面進行對比，測試覆蓋了全部主流機型，測試時間以秒爲單位，測試結果性能基本無差異。

• 應用啓動速度：測試從點擊應用圖標開始，到進入首頁的時間

• 導航切換速度：三款應用都是底部導航，切換底部菜單，測試切換的時間

• 打開新頁面速度：點擊商品列表，打開商品詳情界面，測試打開新頁面的時間

• 調用擴展模塊速度：點擊二維碼按鈕，打開掃描界面，測試調用Native模塊的時間

• 調用開放服務速度：點擊語音按鈕，打開語音識別界面，測試調用開放服務的時間

(5) 完成了平臺化、組件化和生態化發展

目前跨平臺技術領域分爲兩個發展方向：

第一個是HTML5 + Native混合方向;

其中APICloud和微信小程序都屬於前者(雖然微信小程序開發使用本身定義的標籤和樣式，可是執行前仍是要轉化爲標準HTML5)。

HTML5 + Native混合，也就是咱們一般所說的混合開發。

這種模式的開發主體是HTML5，但整個app的架構是Native架構：經過HTML5快速實現app的UI佈局、產品業務邏輯，在開發過程當中涉及HTML5沒法實現或者體驗很差的功能，則藉助Native模塊來實現。

第二個是中間語言編譯方向;

中間語言編譯方向，表明產品爲React Native(RN)，Xamarin以及Google剛剛發佈的Flutter。

如何理解中間語言編譯?

以RN爲例，傳統的app開發，要求開發者使用Android和iOS原生技術-Java、Object-C、C/C++等進行開發，而RN的開發過程則要求開發者使用JS進行編碼輸出app，但在app執行過程當中，JS又映射回到安卓和iOS原生層面執行。藉助JS快速實現編碼，翻譯爲原生代碼執行，這就是中間語言編譯方向。

Xamarin則要求使用微軟本身的語言C#，對於大部分開發者而言，C#的學習成本比較高且Xamarin須要付費使用，所以它目前在國內應用比較少。Flutter的開發語言爲Dart，它是谷歌發明的編程語言，這個語言頗有趣，它的語法相似於C語言，又將JS和Java的一些設計思想以及語法規則融合了進去。Dart語言在此前應用比較少，可參考的資料很少，開發者上手須要一個過程。

其實今天，兩個類型中不少的混合開發技術產品都已經完成了平臺化、組件化和生態化的發展過程，例如：小程序、React Native、APICloud等。

(6) 大規模成功案例出現，成爲企業App開發的主流技術

今天佔領咱們手機桌面的不少app都是採用混合技術開發的，上圖中這些app的開發人員在不一樣的場合都分享過使用混合技術開發各自產品的經驗。這裏你們可能會有一個疑問，在這些主流產品中混合技術佔的比重是多少?是否是隻是個別界面使用了，其實在這些app中HTML5佔的比重仍是很高的，包括咱們平時很是熟悉的手機QQ、58同城、支付寶、淘寶、美團等生活類app，以及海爾、春秋航空、Intel、中信證券、VIPKID等大型企業應用類app。

以上，從6個方面對目前的混合開發技術進行了全面的分析，按照Gartner技術成熟度曲線的每一個階段的定義，咱們能夠清晰的看到，今天的混合開發技術正處於「穩步攀升的光明期」的後期，並即將邁入「實質生產的高峯期」。這一現狀也將爲行業將來的技術研發、產品投入和技術選型提供了重要的決策參考。