章節目錄 "【quickhybrid】如何實現一個跨平臺Hybrid框架" "【quick hybrid】架構一個Hybrid框架" "【quick hybrid】H5和Native交互原理" "【quick hybrid】JSBridge的實現" "【quick hybrid】H5和原生的職責劃分 ...
章節目錄
一些感慨
踏入前端領域滿打滿算也兩年多了。到現在，主要方向已經是由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上這個框架的實現
