寫一個易于維護使用方便性能可靠的Hybrid框架（二）—— 插件化
寫一個易于維護使用方便性能可靠的Hybrid框架（三）—— 配置插件
前言
本來上一篇博文寫完，我就告訴自己，這是最后一篇，之后不再總結和Cordova相關和web容器相關的內容，但是，很不巧，我昨天總結完關于Cordova框架對URL攔截導致通信丟失問題的處理之后，又看了味精大佬的從零收拾一個hybrid框架（二）-- WebView容器基礎功能設計思路（別問我3月份的文章為何才看到，因為我才路轉的掘金）之后，我又按耐不住自己了（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這一塊打算參考味精大佬所選擇的通信方式。具體可以參考
- 1.從零收拾一個hybrid框架（一）-- 從選擇JS通信方案開始
- 2.從零收拾一個hybrid框架（二）-- WebView容器基礎功能設計思路
5.js與native插件交互的性能優化。這一塊又可以細分三部分：
- 1.js調用native是否需要搞個隊列，像我上一篇所提到的，是不是不需要每次調用都要經過webView？那么同樣native端是否一樣也需要搞個隊列出來（Cordova思想，別問我為什么，我也不知道）。
- 2.插件回調一旦耗時，是否需要將其放入后臺線程執行？
- 3.我在淺析iOS-Cordova里面提到過一點，如果插件執行時間過長造成卡頓，向runloop中添加了一個timer來喚醒runloop繼續干活，防止休眠，那么我們是不是也可以將它帶過來。
我就想到了上面的五點，不過感覺有這五點也差不多了，就這些吧，那接下來要做的事情就是，一步一步的解決上面的五個問題，主題思想還是抽離前兩篇文章外加Cordova框架思想，畢竟Cordova有點重量級有些是我們平時開發用不到的，而且集成起來也比較麻煩，基于此，打算造一個性能可靠，使用方便，易于維護且輕量級的Hybrid框架出來。目前構建了思路，具體實現準備放在下一篇（PS：因為我現在也沒想好，太晚了，就到這吧）來寫。
