眾所周知，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技術成熟度曲線的每個階段的定義，我們可以清晰的看到，今天的混合開發技術正處於“穩步攀升的光明期”的後期，並即將邁入“實質生產的高峰期”。這一現狀也將為行業未來的技術研發、產品投入和技術選型提供了重要的決策參考。