前言 雖然說本系列中架構篇是第一章，但實際過程中是在慢慢演化的第二版中才有這個概念， 經過不斷的迭代，演化才逐步穩定 明確目標 首先明確需要做成一個什麼樣的框架？ 大致就是： 一套API規範（統一 與`iOS`），所有API非同步調用（防止阻塞） 提供大部分原生功能的API（包括很多常用的功能給 使用 ...
前言
雖然說本系列中架構篇是第一章，但實際過程中是在慢慢演化的第二版中才有這個概念，
經過不斷的迭代，演化才逐步穩定
明確目標
首先明確需要做成一個什麼樣的框架？
大致就是：
一套API規範（統一
Android與iOS），所有API非同步調用（防止阻塞）提供大部分原生功能的API（包括很多常用的功能給
H5使用）原生需要能調用到
H5中註冊的方法（用關於原生主動通知）部分API需要支持
H5環境（譬如alert需要在Android、iOS、瀏覽器中同時運行）API類別需要包括事件監聽（如網路變化），頁面跳轉（如打開頁面，關閉通過回調回傳值），UI顯示（調用後立即執行）等
整體架構
其中：
quick API指的就是quick hybrid框架提供給H5調用的JS API最外層的統一
JSAPI規範就是quick API多平臺支持的意思是-譬如調用了
quick.ui.alert，在quick hybrid容器中會有響應（原生的彈窗），
同時在瀏覽器中也會有響應（H5實現的彈窗），或者在其它容器中（如DD）也會有響應（其它容器實現的彈窗）多平臺支持並不是所有API都會支持，而是指一些常用的API在多個平臺下都有實現（比如
UI類API一般都會支持，但是原生設備相關就不會在瀏覽器支持）
【目標分析】需要哪些工作
根據quick hybrid的整體架構與目標，我們需要先分析需要實現哪一些內容：
【核心工作】制定
quick平臺下前端和原生容器的交互規則（JSBridge）【核心工作】前端和原生（
Android/iOS）分別實現JSBridge交互（包括互相調用，回調等機制）【核心工作】完成前端調用多平臺的支撐（API在不同平臺下有不同實現，並會根據不同環境自動轉換）
【重要工作】規劃功能API（需要提供哪些功能，並且每一個功能應該在哪些平臺下有實現）
【重要工作】前端和原生（
Android/iOS）分別實現這些功能API（第一步根據二八原則實現重點API即可）【重要工作】處理好短期API（即調即用，立即回收），長期API（一個頁面中能被多次觸發，如導航了按鈕監聽），事件監聽API（整個應用生命周期內監聽，如網路變化）等不同類型
【優化完善】原生API實現的優化，前端代碼的優化，許可權認證，本地資源等等
然後就可以基於這些目標，逐步完成每一個規劃的內容
【分解目標】總體規劃
【quick hybrid】JSBridge的實現
【quick hybrid】H5和原生的職責劃分
【quick hybrid】API的分類：短期API、長期API
【quick hybrid】API規劃
拓展：
- 【quick hybrid】H5和Native交互原理
【分解目標】API的實現
【quick hybrid】API多平臺支撐的實現
【quick hybrid】組件（自定義）API的實現
【quick hybrid】JS端的項目實現
【quick hybrid】Android端的項目實現
【quick hybrid】iOS端的項目實現
【分解目標】優化與完善
賬號體系、Cookie還是Token？
hybrid容器的優化與完善
返回根目錄
源碼
github上這個框架的實現
