有關 Hybrid 開發模式實踐總結

前言

隨着公司業務不斷發展，移動開發項目越來越多，項目任務時間緊，我們內部開發流程是以項目為導向，有別於一般公司對產品不斷迭代的做法，但移動端開發人員資源有限，需要在不同項目之間做業務場景切換開發，就會經常出現項目完成時間 Delay。面對這樣的問題，我們該如何去解決呢？現在了解到的現狀是每個業務組都有配備 Web 前端開發人員，那么是否能把涉及到業務模塊分發給具體業務組 Web 前端開發人員去開發，剝離業務模塊，我們移動端開發人員則專注於框架的開發或者手機端設備能力開發，比如可支持調用攝像頭，監聽網絡狀態變化，提供地理位置信息等等，有沒有這樣一套適合的解決方案呢，答案當然是有的。我們引入了可利用 Web 前端能力和移動端操作系統原生能力相結合開發模式，叫做 Hybrid 混合開發。

目錄

• 為何選擇 Hybrid 開發模式
• 在實踐過程中碰到什么問題和解決
• 經驗總結

為何選擇 Hybrid 開發模式

1，目前工作中碰到的問題

隨着公司業務飛速發展，移動端定制的項目越來越多，同時每個項目的業務邏輯呈現出復雜化和差異化特點，每個項目都需要提供 Android 版本和 IOS 版本，增加開發成本，開發周期往往又會被拖長。同時近年來前端技術蓬勃發展，HTML5 大行其道，很多主流 APP 廠商都利用 HTML5 前端能力來編寫業務模塊並結合原生設備能力進行混合開發，常見的比如淘寶、京東、微信、攜程等等。雖然目前業務項目多，但是用戶交互體驗要求不高，常見頁面也是列表，表單居多，適合充分利用HTML 5能力，因此引入Hybrid 混合開發模式，這樣只需要 Web 前端開發人員寫一遍前端業務代碼，卻能同時在Android 系統和 IOS 系統中執行。

2，Web APP、Hybrid APP、Native APP 對比

目前主流應用程序大體分為三類：Web App、Hybrid App、 Native App，如圖：

Web APP

Web App 指采用Html5 語言寫出的 App，不需要下載安裝。類似於現在所說的輕應用。生存在瀏覽器中的應用，基本上可以說是觸屏版的網頁應用。

優點

（1）開發成本低，更新快
（2）更新無需通知用戶，不需要手動升級
（3）能夠跨多個平台和終端

缺點：

（1）臨時性的入口
（2）無法獲取系統級別的通知，提醒，動效等等
（3）用戶留存率低
（4）設計受限制諸多
（5）體驗較差

**Hybrid App **

Hybrid App 從外觀上來看是一個Native App ，實則只有一個UIWebView，里面訪問的是一個Web App ，如新聞類和視頻類的應用普遍采取該策略：Native 的框架加上Web 的內容。不同於Native App 需要針對不同的平台使用不同的開發語言（如使用Objective-C、Swift開發iOS應用，使用Java等開發Android應用），Hybrid App 允許開發者僅使用一套網頁語言代碼（HTML5+CSS+JavaScript），即可開發能夠在不同平台上部署的類原生應用 。由於Hybrid App 結合了Native app良好用戶交互體驗和Web App 跨平台開發的優勢，能夠顯著節省移動應用開發的時間和成本，Hybrid App 得到越來越多公司的青睞。

按照網頁語言和程序語言的混合，Hybrid App 通常可以分為三種類型：

1. 多View混合型：Native View 和 Web View 獨立展示，交替出現。 其應用主體通常是Native App，Web技術作為補充。即在需要的時候，將 Web View作為獨立的 View 運行，在 Web View內完成相關的展示操作。開發難度與Native App相當.比如：微信里的公眾號文章使用的是Web View 。
2. 單View混合型：在同一個View 內，Native View 和Web View 為層疊關系，同時出現。開發成本較高，難度較大，但是體驗較好。比如：百度搜索同時實現充分的靈活性和較好的用戶體驗。
3. Web主體型：應用主體是Web View ，穿插 Native 功能，主要以網頁語言編寫。整體開發難度低，基本可以實現跨平台，而用戶體驗好壞，主要取決於底層中間件的交互與跨平台能力。比如：項目管理工具 Basecamp 使用Web view呈現內容，調用系統原生 API 實現界面導航等功能來提高用戶體驗。

Hybrid App 也並非是完美的解決方案。由於其使用 HTML5，某些依賴於復雜的原生功能或者繁重的過渡動畫的應用會出現卡頓。同時，為了模擬Native App 的UI和感官，需要投入額外的時間和精力；盡管可以跨平台，但是並不能完全支持所有的設備和操作系統。最后，如果應用的體驗不夠原生化，如一個簡單的網站，則還有被Apple App Store拒絕的風險。

Native App

Native APP 指的是原生程序，一般依托於操作系統，有很強的交互，是一個完整的 App，可拓展性強。需要用戶下載安裝使用。

優點：

（1）打造完美的用戶體驗，性能穩定
（2）操作速度快，上手流暢
（3）訪問本地資源（通訊錄，相冊）
（4）設計出色的動效，轉場，
（5）擁有系統級別的貼心通知或提醒，用戶留存率高

缺點：

（1）分發成本高（不同平台有不同的開發語言和界面適配）
（2）維護成本高（例如一款App已更新至V5版本，但仍有用戶在使用V2， V3， V4版本，需要更多的開發人員維護之前的版本）
（3）更新緩慢，根據不同平台，提交–審核–上線 等等不同的流程，需要經過的流程較復雜

三者技術特性

如下圖表中對比了Native App、 Hybrid App、Web App在不同方面的表現，可以根據實際情況選擇最佳的解決方案。

3，主流 APP Hybrid 應用比例

那么在實際應用場景中，有哪些選擇了Hybrid app呢？實際上，我們很可能使用過很多Hybrid app，卻並沒有意識到它們是借了Native台子唱戲的Web app。根據Appcelerator的官網，目前單是運行基於它的平台搭建的Hybrid app的設備就有近2.86億台。國外常見的有LinkedIn、Yelp、Netflix、Wunderlist ，國內主流的大廠基本也是采用了Hybrid 模式，應該是應用很廣泛，同時技術上也是成熟穩定。

4，選擇 Hybrid 混合開發的原因

1. Hybrid 開發模式在開發頁面 UI 上有天生的便利，而原生的則如果需要一個比較華麗的界面，就需要花很長的時間去開發。

2. 在業務上，看具體情況，有些簡單業務在 Web上就可以處理，而如果涉及到復雜的業務，則可以用原生來寫。

3. 在基本能力上，原生的強，可以提供手機端獨有的特性，但 Hybrid 則需要依賴 Javascript 中間層進行轉化獲取設備能力。

4. 對於少界面，重業務的可以用原生，對於多界面，重效果的，可以用 Web 方式開發

   ​

在實踐過程中碰到什么問題和解決

項目背景介紹

目前在一個項目實行的開發模式就是 Hybrid 混合開發，Web 技術與 Android 原生能力結合開發，Web 技術負責界面開發和相關業務， Android 原生能力則提供手機端特有設備能力，比如調用攝像頭，網絡狀態監聽，數據庫操作等等。但這個項目的特殊性相關業務與我們提供的 Android 原生插件能力高度耦合，比如為這個項目提供數據庫插件就是專門定制開發的，對於 Excel 插件的能力也是高度依賴一機一檔相關字段，這跟我們選型用Hybrid 混合開發模式 的初心是相背離。我們初心是希望 Web 開發人員只需要專注於業務開發和界面繪制，原生部分則是提供相應的Android 設備能力集即可，每個插件跟業務是完全無關，這樣就可以做到原生開發和Web開發互相解耦，兩者之間通過接口隔離即可。

實踐過程中碰到的問題

無論如何，一機一檔項目是第一個應用 Hybrid 混合開發進行實戰的項目，遇到的問題或者坑都是很正常，積極面對解決，並且不斷進行總結和反思。把之前碰到的問題，簡單羅列總結下：

1. 開發人員調試困難問題。前端人員在開發時候是編寫HTML5頁面，所運行的環境跟 PC 端有很大的不同，因為需要運行在具體手機的環境上，因此需要每次編寫完，需要通過移動端人員集成打包出一個APP 包進行安裝驗證，每新增或修改一個頁面就需要重新打包驗證，每次都需要集成測試，步驟繁瑣，效率低下。
2. 項目集成測試問題。Android 系統 Webview 和 PC 端瀏覽器內核版本差異問題導致加載效果不一致。
3. 前端開發框架兼容問題。前端開發人員技術選型是基於 Vue.js 框架，這是一個漸進式 Javascript 框架，剛開始不支持。
4. 文檔不規范問題。在前期開發階段，文檔提供不詳細，開發人員使用規則不清楚，導致溝通成本增加。
5. Webview 性能問題。

如何解決

1. 關於調試困難問題。提供一個調試工具叫做 Chrome DevTool，通過 Inspect 模式加載手機端里的 HTML5 頁面，為何選擇用 Chrome，因為Chrome 是目前主流前端開發調試利器，不僅能支持 Web 端開發，對於 HTML5 頁面調試開發同樣是能監聽到 Javascript 報錯或 CSS 報錯，對於資源、網絡、日志、內存等等，都是一步到位。同時在 APP 里提供一個在線調試環境，就是 Web 前端開發人員布置一個站點，在手機端通過 IP 地址遠程訪問站點，這樣就可以在手機端實時看到剛剛修改內容是什么。
2. 關於項目集成測試問題。在集成測試階段，對Android 系統 Webview 和 PC 端瀏覽器內核版本區別有進一步認識，在Android 5.0 之前選用的是 Webkit 內核來加載 Web 資源文件，而在 Android 5.0 之后，則選用 Chromium 作為內核來加載，那么在為 PC 端瀏覽器端，如果你選擇的是 Chorme 作為你默認瀏覽器的話，它的內核也是 Chromium 。盡管兩者內核類型一樣，都是 Chromium ，但兩者加載 Javascript 效果上表現也不一樣，比如最新瀏覽器版本可支持 ES 6 特性，但是在最新版的手機上就不一定 ES 6特性，目前通過調查 Android 5.0 之前的系統市場占有率，發現比例為不到20%，暫時適配到 Android 5.0 版本。
3. 關於前端開發框架兼容問題。剛開始選用 Hybrid 開發模式時，對於公司內部 前端開發人員選用何種前端框架不甚了解，我們這邊提供的 Demo 則是最原始的 HTML + Javascript + CSS 寫法，以為前端人員只需要簡單了解下就能上手，但在實踐中發現卻不是這樣的。他們選型的前端技術是基於 Vue.js ，因為 Vue.js 是需要編譯打包，生成發布的內容是混淆過的HTML + Javascript ，里面 Javascript 文件加載順序使得我們開發 Javascript 插件調用引起問題，那樣就會導致前端人員在調用具體插件能力時候，發現這個插件里的某個方法還沒定義，就導致頁面數據出錯。后來通過了解 Vue.js 開發方式，調整項目工程中 Javascript 執行順序， 確保具體插件調用在 Vue.js 執行前觸發。
4. 關於文檔不規范問題。在前期開發階段，前端人員沒有統一查找目前已有插件能力的地方，僅僅根據我們提供的 Javascript 文件里的方法注釋，雖然是針對每個方法的 Demo 用法，但是在實際開發中，前端開發人員也會調用出錯。不是這個方法回調方法寫錯，就是參數類型傳入傳錯，這樣就導致的一個結果，前端開發人員不斷地過來詢問這個方法是如何調用的，我明明已經根據你的 Demo 寫法進行編碼了，為何還是報錯的，前期的溝通成本還是很高。所以需要一個提供統一文檔地方，里面寫明了具體配置如何，寫法如何，怎么是一步一步走，基本上可以避免類似的錯誤，更好的提高工作效率，減少溝通成本，所以一個規范的文檔是很有必要的。
5. 關於 WebView 性能加載問題。這是在解決 WebView 加載 HTML + Javascript + CSS 等資源時發現一個白屏問題，同時用 HTML5 做頁面本身就會比原生加載來的慢。為了提高用戶體驗，在加載等待時，提供一個加載框來提示，等 HTML 資源文件全部渲染完畢后，等待框再消失，這樣就可以避免一定的白屏現象。

經驗總結

整體來說，為何會選擇 Hybrid 混合開發模式是基於當前業務場景需要，技術是服務於業務發展，業務場景變化導致技術解決方案的選型也需要相應變化。面對以項目導向的開發現狀，不能一昧追求最新最酷的技術，也不能對過時的技術方案過分保守，應該需要對當前業務場景進行判斷，選擇合適的解決方案才最佳的策略，沒有一勞永逸的技術手段，只有時刻變化的業務需求和不斷更新迭代技術方案。通過在具體項目中實戰，面對問題，積極解決問題，也正是在解決問題過程中，產生新的想法和嘗試，不斷地完善框架能力，使得框架功能越來越全，進而更好的服務於業務開發問題，提高業務響應能力，降低開發成本，提升工作效率。