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