写一个易于维护使用方便性能可靠的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这一块打算参考味精大佬所选择的通信方式。具体可以参考

5.js与native插件交互的性能优化。这一块又可以细分三部分:

  • 1.js调用native是否需要搞个队列,像我上一篇所提到的,是不是不需要每次调用都要经过webView?那么同样native端是否一样也需要搞个队列出来(Cordova思想,别问我为什么,我也不知道)。
  • 2.插件回调一旦耗时,是否需要将其放入后台线程执行?
  • 3.我在浅析iOS-Cordova里面提到过一点,如果插件执行时间过长造成卡顿,向runloop中添加了一个timer来唤醒runloop继续干活,防止休眠,那么我们是不是也可以将它带过来。

我就想到了上面的五点,不过感觉有这五点也差不多了,就这些吧,那接下来要做的事情就是,一步一步的解决上面的五个问题,主题思想还是抽离前两篇文章外加Cordova框架思想,毕竟Cordova有点重量级有些是我们平时开发用不到的,而且集成起来也比较麻烦,基于此,打算造一个性能可靠,使用方便,易于维护且轻量级的Hybrid框架出来。目前构建了思路,具体实现准备放在下一篇(PS:因为我现在也没想好,太晚了,就到这吧)来写。

猜你喜欢

转载自juejin.im/post/5c07d95ee51d451d930b04c7
0条评论
添加一条新回复