《寫一個易於維護使用方便效能可靠的Hybrid框架（一）—— 思路構建》
《寫一個易於維護使用方便效能可靠的Hybrid框架（二）—— 外掛化》
《寫一個易於維護使用方便效能可靠的Hybrid框架（三）—— 配置外掛》
《寫一個易於維護使用方便效能可靠的Hybrid框架（四）—— 框架構建》
前言
本來上一篇博文寫完，我就告訴自己，這是最後一篇，之後不再總結和Cordova相關和web容器相關的內容，但是，很不巧，我昨天總結完《關於Cordova框架對URL攔截導致通訊丟失問題的處理》之後，我又按耐不住自己了（PS：我本來是沒想研究這麼深的，但是，停不下來了），那我就問自己，如果是我呢，因為我一直在總結Cordova的思想，那麼如果是我設計一個Hybrid框架，我要怎麼做？於是我又陷入了沉思...因為我本來是想在後續著重研究weex,RN等動態UI方面的實現的，講真的通過味精大佬的分析，我現在也不確定到底是我們的web容器更好還是基於weex等的動態UI更好，於是我又陷入了沉思...經過深思之後，個人覺得後者是大前端的趨勢，什麼是大前端，就是各種的各種前端客戶端糅合在了一起，四處交叉延伸，不分你我。
不扯那麼多了，還是基於這個想法，我決定給自己總結一個自己的Hybird框架，一方面屬於知識的總結，年紀大了不總結就忘是真的，另一方面算是對自己知識的擴充套件延伸，希望多像大神學習...另外，味精大佬的思想是框架內並不自己構建webView，而是開發人員完全使用自己的webView即可，那麼我也在糾結，到底要不要開發者自己控制webView還是說框架內控制？那麼我先在大佬的基礎上做下延伸擴充套件，決定框架內不提供webView，webView的建立由開發者自己控制。
那麼現在就有了兩個前提：一是webView使用WKWebView，二是框架內不提供webView，webView需要開發者自己建立。下面進入正題：
一個好的Hybrid框架應該具有哪有特點：
1.外掛化，這個是必須的，解耦沒毛病，什麼叫外掛化，就是可插拔，用的時候拽進來，不用的時候拖出去，其餘什麼都不用幹。說實話這很符合Cordova（優點太多離不開了），外掛化又可以細分：
- 1.webView的代理方法具體實現外掛化，這樣不管哪個webView的代理方法都可以隨意設定而不會影響業務。
- 2.js與native互動外掛化，就是我們所謂的js外掛，native外掛，它們統一叫外掛（比如fetch,io等），配對插配對拔，具體看業務需求。
2.可配置性，就是說一切皆可配置，所有的外掛，都是被一個配置檔案搞定的，也就是說一個配置檔案即可搞定上面提到的一切外掛。配置又可以細分：
- 1.外掛可配置，外掛的可配置又細分為native端的外掛可配置和js端的外掛可配置。
- 2.外掛是否在載入webView時就載入到快取裡面還是說在呼叫的時候在載入，這個要看具體業務，個人覺得常用的外掛，例如fetch外掛，js的網路請求都使用native來做，這種外掛是完全有必要提前載入的，像地圖這類外掛，可能偶爾會用一次或者使用者一時半會用不到，這類外掛就完全可以在呼叫的時候再例項化放入快取。
3.對於前端開發者來說介面統一，並且框架內怎麼變也不需要js做改動，對於前端來說，始終是一套介面，他不需要關心webView具體是啥。
- 需要提供出一套前端介面給前端開發者。
4.通訊上必須用WKWebView，因為它對效能的提升是顯而易見的，而且不得不用，webView這一塊打算參考味精大佬所選擇的通訊方式。具體可以參考
《從零收拾一個hybrid框架（一）-- 從選擇JS通訊方案開始》
5.js與native外掛互動的效能優化。這一塊又可以細分三部分：
- 1.js呼叫native是否需要搞個佇列，像我上一篇所提到的，是不是不需要每次呼叫都要經過webView？那麼同樣native端是否一樣也需要搞個佇列出來（Cordova思想，別問我為什麼，我也不知道）。
- 2.外掛回撥一旦耗時，是否需要將其放入後臺執行緒執行？
- 3.我在《iOS 原始碼解讀 -- cordova-ios》裡面提到過一點，如果外掛執行時間過長造成卡頓，向runloop中新增了一個timer來喚醒runloop繼續幹活，防止休眠，那麼我們是不是也可以將它帶過來。
我就想到了上面的五點，不過感覺有這五點也差不多了，就這些吧，那接下來要做的事情就是，一步一步的解決上面的五個問題，主題思想還是抽離前兩篇文章外加Cordova框架思想，畢竟Cordova有點重量級有些是我們平時開發用不到的，而且整合起來也比較麻煩，基於此，打算造一個效能可靠，使用方便，易於維護且輕量級的Hybrid框架出來。目前構建了思路，具體實現準備放在下一篇（PS：因為我現在也沒想好，太晚了，就到這吧）來寫。