背景最近在工作中遇到页面跳转点击报漏的问题，在微信ios的webview上突出显示。报告后直接跳转的失败率达到了惊人的93%。喝口水压住震惊，一步步开始分析问题的发生。其原理是现代浏览器越来越快，尤其是Chrome的v8内核，运行速度很快。但是必须看到，在不同的平台上，浏览器之间的实现还是略有不同的。就拿页面跳转漏报的问题来说，PCchrome浏览器emulation和微信AndroidWebview没有这个问题，但是在IOS端表现的那么严重。现在我们主要有三种跨域上报的方法，imagesrc，jsonp和fetch。不管是哪种上报方式，当浏览器点击跳转时，跳转前的点击上报请求都会进行三次握手。如果此时网络缓慢，服务器运行缓慢，或者报表请求还在处理阶段，此时，如果页面被卸载，浏览器会自动中止当前请求。这样http请求没有建立，report也没有真正发送。我对这部分还有疑问。按理说只要发出fetch请求，即使abort也是假abort，因为根本就没有fetch的abortAPI，但是据我统计，有些曝光报告确实消失了（很奇怪看到请求已经按照fiddler截止顺序发送了）。我会关注这个问题。解决方案说到解决方案，人山人海，其实没有一个能打的。下面我将我认为还可以的方法加粗。添加延迟应该是最简单的解决方案。没有什么是setTimeout1s解决不了的。如果有，那么2s...但是这种方案有损用户体验和代码的优雅。大的。除非你真的不太关心性能，否则这个技巧不会奏效。之前有类似的解决方案：1.阻塞Ajax请求2.暴力死循环3.发送图片请求阻塞当然，这些方案在chrome浏览器上应该是无效的，但是它们的原理和优缺点是一样的延迟是相似的.对这三种无效解决方案感兴趣的可以看《页面跳转时，统计数据丢失问题探讨》window.name，将要重定向的URL放入window.name，然后在下一页报点击。window.name的含义是获取/设置窗口的名称。这个属性是跨域的。当窗口存在时，window.name存在；每个窗口的名称可以不同。本方案以window.name作为存储和上报点击地址的媒介。该方案虽然解决了用户体验差的问题，但是要实现该方案，必须在所有页面部署处理window.name的代码。举个简单的例子，如果你是一个站长，你点击一个广告跳转到广告的落地页，你不能要求你的代码部署在广告的落地页，所以这个方案也有很好的限制。cookie和localStorage的方案和window.name类似，但是因为cookie和localStorage的生命周期比window.name长。我们可以把延迟上报的代码放在我们之前的页面中：每当用户在跳转页面时报告丢失，把上报地址写入cookie或者localStorage，然后等待用户返回到我们页面的时候，判断这两种存储介质是否有价值，如果有价值就上报。该方案不需要在所有页面都添加监控代码，但是如果在某些极端情况下，用户转到另一个页面再也没有返回，或者间隔时间比较长（比如2天），那么就会影响我们整体的统计数据会有出入。BeaconAPI这是W3C委员会给出的浏览器异步请求发送API。可以保证即使页面处于unload状态，也会异步发送统计信息，不影响页面跳转/跳转到下一页。但是，它的浏览器支持一直是个问题。截止到写这篇文章的时候（2018年02月04日），支持率如下：可以看到至关重要的iossafari终于在11.3版本支持了这个功能，不过我已经更新了最新的ios版本：11.2。5！估计还需要两个月才能使用这个功能。而且最近IOS升级减速门会进一步拖慢新版本的覆盖时间，难受啊兄弟！后台重复报错，无非是前端浏览器中止了请求。如果有背景同学支持，问题就迎刃而解了吗？一种方案是前端把需要上报的内容全部丢给后台，让后台上报并进行302跳转。这是完美的解决方案吗？前台有，后台没有。总结虽然我们还没有一个完美的解决方案，但在不久的将来我们将能够使用BeaconAPI。你问我现在怎么办？首先使用cookie/localStorage解决方案。过两天我会给出详细的代码实现。
