【quickhybrid】如何實現一個Hybrid框架

時間 2019-12-08

標籤 quickhybrid 如何實現一個 hybrid 框架欄目 Hybrid 简体版

原文原文鏈接

章節目錄

一些感慨

踏入前端領域滿打滿算也兩年多了。到如今，主要方向已是由Android原生轉到了偏前端領域。

期間，不提本身的技術進步、視野拓寬，最大的產出之一應該就是從0開始構建了一個Hybrid框架了。

正值最近開始進行技術梳理，所以就準備寫一系列文章沉澱起來。

本系列包含的內容清單

Hybrid框架的原理以及架構系列
JavaScript部分的原理以及源碼系列（包括部分API的多容器的兼容）
Android部分的原理以及源碼系列（僅覆蓋核心實現以及API部分，不包含實際業務代碼）
iOS部分的部分原理（一些坑會特別提出，理論上根據原理應該能夠還原出）
- 因爲本人沒寫過iOS應用，所以目前沒有直接提供源碼，後續有時間能夠考慮進一步提供

什麼樣的`Hybrid`框架？

核心宗旨：H5頁面基於該框架能夠替代80%以上的原生業務頁面。

更詳細一點：

適用於須要開發大量項目級APP的場景
不是用於徹底替代原生開發，而是替代裏面的80%原生業務頁面（模式是：原生部分 + H5部分）
框架人員至少須要一名Android原生，一名iOS原生，一名前端架構（若是全棧，能夠考慮合一）
部分API（如UI顯示類）考慮到了H5的兼容
並無作到產品級別的優化（需求優先級別較低）

之因此不基於第三方框架而是本身從新實現，是由具體的環境與需求決定的。譬如要求本身必須徹底掌握源碼，某些功能必須經過特定安全檢測等。

另外，本系列不與任何市面上的其餘框架進行比較，僅是本身的經驗總結。

此框架是否有實踐經驗？

此框架不是平地起高樓而來的，而是在接近兩年的項目實戰中慢慢演化出的，內部已經迭代過多個版本

另外，它已經在一個項目型公司全面推廣使用了。（N+級別）

這裏要說明下：

實際項目中，Hybrid框架僅僅是其中的一部分，還會包括一些原生通用組件，業務模塊等
可是本系列僅止步於Hybrid框架（處於諸多因素考慮，包括核心實現以及API實現）

如何應用與本身的項目中？

最後的源碼部分僅提供核心實現以及API部分，對於一些簡單項目來講，其實也就夠用了，
可是若是功能較複雜的，確定須要進一步封裝本身的原生功能。

實際上推薦使用如下人員配置：

一名資深Android原生（負責Android容器）
一名資深iOS原生（負責iOS容器）
一名資深前端（前端部分不要小覷，要配合排查問題的）
總架構（推薦是以上三人中的一人擔任，譬如本系列是由前端來統一架構的-但前提是必須懂點原生原理，不然抓瞎）

由於每個人精力有限，因此除非特別厲害和全能，不然不建議一人擔任兩職
（譬如像我轉入前端後，之前的Android就遺忘的很快，可是若是重點兼顧Android，前端水準確定沒法快速提高）

在N+項目時的模式大體以下：

三名框架人員負責核心框架容器部分(框架還須要提供一些通用模塊與組件)
各個業務線的APP中能夠專門分配不一樣的原生人員負責打包APP（1對N，協助排查各自可能的業務問題）
每個APP中能夠有若干H5業務開發人員(由不一樣的複雜度而定，主要業務都是線上的H5形式)
三名對於的框架人員負責處理過濾後的真正框架BUG（由業務負責人過濾）

注意，以上是最小配置。（譬如能夠分配更多的框架人員，優化提高等）

最後，以上是實際的經驗總結，僅作參考。

框架更新與迭代

實際上不一樣框架的更新迭代方式都是不同的，好比本系列中就是基於需求迭代

也就是說遇到問題才修復，優化，累積一段時間後開始考慮下一代的優化提高（迫於投入的窘迫性）

通常來講，總體的交互架構以及API是由對於的負責人規劃的，而後安排給對於的容器實現

版本號的化仍然是如下經典形式：

大版本.小版本.修正版

譬如本框架在兩年內迭代了多個大版本（涉及到底層），
使用起來變化較大就會變更小版本，
平時個別API新增和修復是修正版

這裏因人而異，好比有的喜歡將API新增也變爲小版本更新

借鑑與不足

本框架中在實現是吸收了很多市面上已有框架的經驗，譬如：

釘釘（API設計上，惋惜沒法看到它底層實現...）
phonegap,html5+,apicloud,appcan等都有接觸過（但參考的很少）
一些github開源庫，譬如marcuswestin/WebViewJavascriptBridge等

另外，在文章總結時，參考了一些博文，包括我之前寫的文章（會在參考來源中）

源碼

github上這個框架的實現

quickhybrid/quickhybrid

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。