之前的工作笔记在公司电脑上,因此这里就先来浅谈下NSURLProtocol做web缓存时令人印象深刻的坑吧!
1、使用的是UIWeb和WKWeb的区别:
UIWeb就比较简单了,随便网上搜下就能找到NSURLProtol使用方法,按上边的做就行;
WKWeb就有点麻烦了,因为和UIWeb不一样,wk需要做些特殊的设置,才能拦截到https和http请求(待完善);
2、对于post请求的处理:
nsurprotocol能拦截到post和get请求,但是拦截到的post请求的请求体httpbody会丢失(ui和wk都有此毛病;拦截原生请求是否会丢失呢? 曾经在公司电脑上尝试过,待完善)(httpbody被苹果优化掉了);这就会出现很多问题
例如问题一:所有我们要想对post请求重定向就比较麻烦了:(注:post请求参数是设置在httpbody中的,protocol拦截拿不到参数)
例如问题二:即拦截到post请求不做处理,只处理get请求也会影响post请求的发送:
在canonoirequet方法返回no也会影响post请求的发送,可能也是因为httpbody的问题,我用我们的app亲测过,加上nsurlprotol拦截后(即使不处理post请求)和不加nsurlprotol拦截,发现h5页面的展示的内容不同(拦截展示的敬请期待,而不拦截展示的是正常白领好物页,在网络通畅情况下多次测试均能复现)。
我最进做的一个需求就是拦截神策的请求(js神策都是get请求)统一distictid为原生的,将其js参数distictid转换成原生的distictid值,想用拦截的方式处理,这样会影响其他js的post请求发送。最终我们选择用交互的方式处理这个需求。
解决方法:
1》将httpbody的内容放到httphead中,在我们用protocol拦截到post请求时,将httphead的相关参数添加的httpbody中,将请求发出去,需要h5的同学设置httphead。
2》与h5的同学约定其他非http或https的自定义协议(也就是原生和js交互的原理了),用交互的方式将js的post请求放在原生端去发送,再将请求数据返回给原生。
所以,如果真想用protol拦截js请求的话,那就选择交互的方式,将所有post请求让原生端发送吧。
3、多次网页请求不执行protocol相关的代理方法:
如果代码没问题的情况下,在该执行相关方法时没有执行,也是正常的情况,这时候就要考虑request时设置的是否是默认的cachepolicy了,如果设置的的默认cachepolicy则会有强制缓存和对比缓存了(详见上一篇博客),所以有时候即使是返回200接口也不会发出去(对比缓存),请求都没有真正发出去,自然是还没走到protol拦截的过程了,所以方法就不会执行;
以上是protol拦截web请求,当然拦截到这些请求我能就能缓存数据了,下载方法不在此赘述了。
另外protocol拦截原生请求也是有坑的,且看下一篇博客