AppHost：大前端融合下的 Hybrid 開發解決方案

目前移動端開發還處於一個高速發展的階段，爲了應對快速增加業務需求，移動開發須要更高迭代響應速度，從前期涌現出了以 React Native、Weex 爲表明的 web 技術棧，到如今的 flutter 爲表明的容器棧，這些跨度開發框架試圖提升開發效率的同時，也擁有優秀的運行效率，目前看起來正在接近這個目標。
這些技術，加上 native 開發技術，在不一樣應用場景下，咱們能夠選擇最合適的技術棧，而最古老的跨端技術方案 - Hybrid， 在中小型項目和不復雜的需求中，依然是最合適的選擇，目前在網易嚴選主站，商品詳情、促銷活動、第三方頁面展現仍是用 Hybrid 實現的。 AppHost 提供的就是傳統意義上用 web 技術爲 native 開發業務功能的能力。

AppHost 是一套解決 H5 和 native 協做開發的總體框架和服務。試圖解決 native 和 H5 目前迭代頻繁、時間倉促形成質量不高，業務膨脹後代碼混亂，兩端聯調困難，多端協做彼此割裂等痛點。
做爲一種 JSBridge 的實現方法，AppHost 像一座橋，將 native 和 H5 開發打通；
一邊是提供設計良好的 native framework 和相關 protocol ，提升 native 接口的交付能力和開發質量；
一邊是爲 H5 開發的頁面和 native 聯調，提供輔助調試工具和性能調優工具，讓前端開發者對 H5 in App 的調試體驗像調試原生瀏覽器同樣，從而提升質量和提高開發效率。

Hybrid 的接口開發生命週期

這是實際工做中 JSBridge 面對的工做，不少是重複、乏味，又容易出錯的。常見場景——「新需求裏須要增長新的接口」的流程是這樣的：

1. 新增一個文件或者在舊文件上編寫代碼，新開接口和屬性
2. 在 Android、native 和 H5 共有的接口文檔上補充 API 接口。若是有須要，須要升級 JSBridge 接口的版本號
3. 將改動通知 Android、H5 等相關方
4. 增長測試用例（testcase 應該 iOS 、Android、 QA、前端，共建測試用例）
5. 若是有必要須要告知，QA 增長自動化測試用例
6. 前端須要考慮版本號升級以後，需不須要對新舊 native App 作兼容實現

AppHost 處理負責 JSBridge 接口從 0 到 N 個、1歲到 5歲、出生到死亡週期，以及 JSBridge 之間的關係管理、對外提供數據支持等工做，因此它是解決方案，而不是個技術方案（如WebViewJavascriptBridge只是技術方案）。

AppHost 的功能總覽

分兩部分，AppHost Core 爲 native 開發提供基礎模塊和基本功能封裝；AppHost Debug Service 爲 native、H5 前端、QA 等人員提供調試服務。下面詳細介紹功能。

AppHostCore

1. webview 核心，包含常見需求的實現邏輯，包括

• native 和 H5 的通信協議，封裝了 native 端解析、H5 端發送邏輯。native 開發人員只須要面向業務編碼，而後通知 H5； H5 開發面向業務開發，只需關心兩個接口。
• 新增接口用繼承 AppHostResponse 的方式實現，解決業務需求增加、代碼無序膨脹的問題。特別的，支持業務接口的延遲加載，不使用的接口，不會初始化。
• Cookie管理，最煩人的 Cookie 丟失和 Cookie 同步問題，已經內部妥善處理
• 一些人性化的小優化。更合理的進度條、瀏覽歷史滾動記憶、加強的 native 執行 js 代碼能力、基本的 API 接口調用鑑權等等。

1. JSBridge 接口管理

• 獨立於 App 的版本號，H5 使用特性嗅探實現新舊 App 的兼容，簡單直觀。
• API 接口簽名，可實現 API 參數粒度的接口升級和開關管理。

1. 資源加載

• 加載遠程 URL，單向同步 Cookie 到 WKWebView。
• 本地文件夾資源，可實現用離線包渲染動態頁面。
• 某些業務場景下，可實現 HTML 裏的 xhr、js、css 資源請求攔截，不須要動用私有 webkit API。

1. API 接口文檔一體化和 testcase 自動化

對於「native 爲 H5 提供接口」 這件事情，如前述，須要多方的協調同步，很容易出現：接口文檔過期、文檔缺失、接口查找麻煩、接入新 API 不直觀、測試不方便，QA 迴歸不充分，或者是多個環節重複寫測試用例等壞狀況。
AppHost 的 API 文檔模塊，將這些環節須要的文檔和測試用例，所有集中到開發階段完成，後續 H5 查詢的 API 文檔、QA 走查用例、自動化測試，所有自動生成。保證接口文檔的最新，省去多個環節的重複建設，內置的自動化測試支持，方便 QA 使用腳本回歸測試。

AppHost Debug Service

1. Remote Debugger 經過電腦瀏覽器提供 Debug Service

電腦瀏覽器具備訪問方便、可展現區域大、輸入快捷方便、易於集成第三方調試工具的特色。相同的調試功能，理論上也能夠集成在手機 App端，可是體驗會大打折扣，是個低效的調試方案。

1. 幫助系統和文檔。

在瀏覽器端 Console ，實現了一個小型命令行程序，指導用戶如何使用本 Remote Debugger；同時還提供 即時查詢 API 接口 名稱、參數解釋、示例代碼等功能，讓你的工做流不須要切換到打開的API 文檔文件或者瀏覽器，保持操做上下文。

1. REPL（Read-Eval-Print Loop）環境

Console 裏實現了完整 webview 執行環境，將傳統語言的探索、調試新特性的體驗帶到 Remote Debugger，如同 Bash 的 shell prompt和 ruby 的irb 那樣。在這裏輸入的全部命令如同在遠端 webview 的 console 裏執行同樣。固然還有Off mobile 和On mobile 來切換當前命令是本地執行仍是遠端 webview 執行。

1. 輔助功能

Console 提供了左側快捷命令；內置了命令的歷史記憶，實現上下箭頭遍歷；支持 :clear ，清除當前界面等功能

1. 擴展性

• 和 Safari 的 Develop 工具配合

咱們知道 Safari Develop 工具是在頁面打開後纔會出現。若是咱們有個頁面由 302 跳轉，咱們想抓到想要的請求是作不到的。接入 AppHost 以後，咱們保持Safari Develop 工具打開的狀態，在 Remote Debugger 輸入命令 ，讓當前 webview 加載初始 URL，這樣咱們就能夠抓到從 302 跳轉開始後的網絡請求了。

• 集成 weinre。

經過:weinre -- 命令，不須要改動被調試頁面的源碼，便可提供 weinre 調試服務，並且一次注入當前 App 啓動後全程有效，後續頁面無需再注入。用這個特性，甚至能夠調試第三方頁面。

• 支持 console.log。這個無需贅言，曾經的` https://jsconsole.com/ 是首選的遠程調試服務。AppHost 內置此功能。

1. 演示
   6.1 基本操做演示

6.2 **查看嚴選首頁的 onload 事件時間**

6.3 **使用 weinre 調試嚴選頁面**

AppHost 願景目標

AppHost 來自做者近年 webview 開發實踐總結，真切的感覺到這套設計在面對業務快速發展、技術重構需求、多端協做等方面的優越性，特整理分享出來，不只面向咱們之後的業務開發，也但願拋磚引玉，和各位同行共享知識，以

1. 指導 native 端業務成長、保持 App 可擴展、可維護
2. 輔助 H5 快速開發、性能調優，提升產品體驗

在此，但願 AppHost 能幫你解決在 webview 相關開發過程當中遇到的常見問題，讓你更多的時間花在如何完善業務邏輯，加快 App 成長上面，爲你的開發工做帶來切實的幫助，避免 996，享受工做和生活樂趣。

採用AppHost 的 App 有哪些？

目前 AppHost 只有 iOS 端。其中 AppHost Core 在網易有錢上使用了 3 年多，支持了網易有錢的不斷增加的業務需求，期間解決了不少 WKWebView 遇到的通有的問題。 AppHost Debug Service 目前尚未在線上系統中使用，目前正逐步將 AppHost 總體接入網易嚴選和網易推手。

使用指南

詳細的技術方案和接入方式見如下連接

1. AppHostExample 項目，https://github.com/hite/AppHo...
2. AppHost 項目，https://github.com/hite/AppHost

但願各位同行也能分享各自解決方案，共同提升行業 Hybrid 開發體驗。