WebView中Video的缓冲爬坑志

背景

在自己研发的手机APP上（Android tbs x5webview/iOS wkwebview）打开H5页面，页面上使用了video播放视频，当进入其它页面或返回上级页面，又或者暂停播放的时候，视频的缓冲并未停止，还在持续下载。

初级解决方案

我们在页面退出的时候，把video节点的src属性设置为""，或者根据[MDN官方文档](!https://developer.mozilla.org/en-US/docs/Web/Guide/Audio_and_video_delivery) `Stopping the download of media`这一小节的描述，使用removeAttribute移除src属性。

此时在电脑的浏览器devtool里面inspect手机上的页面，看network栏，确实是停止下载视频数据了，万事大吉！

然后悲剧发生了，某人测试突然发现访问了几个页面之后，数据流量消耗了5.4G，于是问题爆发了。

使用抓包工具，发现确实无论在Android还是在iOS上，视频缓冲的下载都没有停止。

 爬坑

然后开始了爬坑之旅，折腾了近两天，被残酷的现实打败了，只能使用最初想到的一个弱弱的方案解决问题，这里记录一下以共勉

iOS

在H5层面折腾了很久，排除了各种vue组件的影响之后，仍然没有解决问题，只能回归到native去找原因。用纯净的wkwebview发现没有这种问题，然后逐步定位发现是拦截器造成的。

对于http服务器上的视频资源(mp4，m3u8等)

只要使用了

[NSURLProtocol wk_registerScheme:@"http"];

无论你

(BOOL)canInitWithRequest:(NSURLRequest *)request

中返回的是YES还是NO，缓冲视频的下载都不会终止，会一直持续到下载完整个视频。
如果上述函数返回YES，在startLoading/stopLoading中还需要做相应的处理，亦没有终止下载。（由于时间关系并没有在这一块深挖，或许有机会完美的实现渐进式缓存机制）

Android

只要使用了X5内核的webview，无论你怎么设置参数，它都是一口气把整个视频给缓存下来。可以直接使用QQ浏览器对页面进行访问，用抓包工具进行测试。

如果是用Chrome的话，抓包工具中的现象是虽然数据连接还处于接受数据的状态，但是下载的字节数却是不会增长了，个人猜测应该是没有断开连接，只是没有继续处理连接上收到的数据了而已。

最后只能绝望的放弃。

终极武器

从H5到Native再绝望的回归到H5，上面寥寥数语，确是我们经历了进两天的被折磨之后得出的结论，在H5上寻找解决方案的时候，我不得不拿出我的最初的一个想法来尝试，结果，嘿，好了～～尼玛……

这个终极武器是怎样的呢？其实很简单，直接将player.currentTime设置为player.duration，意思就是相当于seek到最后一秒。考虑到可能会有循环播放的情况存在，在设置之前先调用pause()暂停播放。

这个方案只能说是目前没有办法的办法，并不安全，更不完美，在我严重它简直丑陋至极，但是没办法，从H5到Native转了一大圈也没有什么能够对视频下载有所控制的方案，只能先凑活用它了。