1. 程式人生 > >【quickhybrid】如何實現一個Hybrid框架

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

釘釘 都是 不足 快速 view 環境 視野 swe 開發

章節目錄

  • 【quickhybrid】如何實現一個跨平臺Hybrid框架

  • 【quick hybrid】架構一個Hybrid框架

  • 【quick hybrid】H5和Native交互原理

  • 【quick hybrid】JSBridge的實現

  • 【quick hybrid】H5和原生的職責劃分

  • 【quick hybrid】API的分類:短期API、長期API

  • 【quick hybrid】API規劃

  • 【quick hybrid】API多平臺支撐的實現

  • 【quick hybrid】組件(自定義)API的實現

  • 【quick hybrid】JS端的項目實現

  • 【quick hybrid】Android端的項目實現

  • 【quick hybrid】iOS端的項目實現

一些感慨

踏入前端領域滿打滿算也兩年多了。到現在,主要方向已經是由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

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