写一个易于维护使用方便性能可靠的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：因为我现在也没想好，太晚了，就到这吧）来写。

写一个易于维护使用方便性能可靠的Hybrid框架（一）—— 思路构建