不够灵活,更新一丢丢东西得从新上架,还得同时开发两个端,麻烦。可是性能好啊,动画顺畅啊。前端
性能差,可是兼容两端,足够灵活,不须要请这么多人(省钱啊)web
保证性能的同时,常常性更改的页面改用web开发,保证必定程度的灵活性,能够减小新包上架的频率浏览器
其实如今不少App都是采用这种模式进行开发了,那么咱们日常能够怎么与客户端进行数据上的交互呢?服务器
这个其实很简单,客户端在生成一个webview的时候(至关于浏览器),进行url跳转,在跳转时,将数据以query的方式带上,这样咱们就能够用js进行获取使用了。app
这种方式,须要Android和iOS端统一一下规范,好让咱们前端小弟可以根据协商的方式进行数据的获取函数
这里提出一个场景,就是token的获取,在咱们页面请求服务器的时候,可能须要客户端登陆时存储的token,这种东西在url上带上就不太好了,毕竟比较容易暴露嘛,因此通常咱们会选择放在header中。post
在通过咱们团队讨论以后,咱们的客户端大佬就决定制定一份协议吧,用于客户端两端与js的交互,这里主要是基于函数进行传值。性能
两端都往webview中注入一个全局方法吧动画
安卓:window.nativeBridge.appHandlerurl
iOS:window.webkit.messageHandlers.appHandler.postMessage
那咱们前端就能够经过window对象分别去调用对应的方法,传入一个config用于客户端判断须要获取什么数据
这里统一传入的是序列化的配置对象,含有method,以及params,给客户端进行判断使用。
以后客户端要把数据传入给咱们,也是经过咱们前端提早挂载在window对象上的h5Handler方法进行传值
客户端调用了window.h5Handler后,将传入一个序列化的配置对象dataString(这个参数就是客户端传过来的数据),一样也是含有method和params(这个固然是和客户端协议好的),途中有个resolve方法,是外层函数传入的。
固然这里为了更好地进行业务的匹配,须要将一些业务的代码抽离出来。
将获取token这个业务单独抽离出来。
以后咱们就能够直接调用getToken,在resolve中获取到客户端传给咱们的token了
若是还有什么好的方法,但愿能够分享一下。哈哈哈