背景

近来在工作中，遇到了页面跳转时点击上报丧失的题目，突出表如今微信ios的webview上，上报后直接跳转的失败率达到了惊人的93%。喝口水压压惊，最先逐渐剖析题目的发作。

道理

当代浏览器越来越快，尤其是Chrome的v8内核，跑的那叫一个敏捷。然则必需看到的是，在差别的平台上，浏览器之间的完成照样略有差别的。就拿页面跳转时点击上报丧失的题目来看，PC chrome浏览器模仿和微信 Android的Webview, 均不存在这个题目，然则在IOS端的表现却云云的严峻。

如今我们跨域上报的体式格局主要有三种，image src, jsonp和fetch。不管是哪一种上报体式格局，在浏览器点击跳转时，跳转前的点击上报请求都邑举行一个三次握手，假如此时，收集较慢、服务器运转迟缓或许上报请求还在处置惩罚阶段，这时刻，假如页面被卸载了，浏览器都邑自动对当前的请求举行abort。如许，这个http的请求就没有竖立，致使上报没有真正发出。

这部份我另有个疑问，按理说只需fetch请求发出，纵然是abort也是假的abort，由于如今根本就没有fetch的abort API，然则从我统计的数据上来看，确切有一部份暴光上报消逝了（在fiddler截单看到发出了请求），异常的诡异。我会继承关注这个题目。

处理计划

说到处理计划，那就海了去了，然则能打的实在一个也没有。下面我会把我以为还OK的要领加粗。

• 加一个delay

这应该是最简朴的计划了吧，没有什么是setTimeout 1s不能处理的，假如有，那就2s……然则这类计划不管是对用户的体验，照样对代码的文雅，都损伤迥殊大。除非真的是对机能不太在乎，不然这招是用不出来的。

之前相似的计划另有：
1. 壅塞式的 Ajax 请求
2. 暴力的死循环
3. 发一个图片请求壅塞

固然这些计划在chrome浏览器上都应该失效了，然则他们与delay的道理和优缺点都是相似的。对这三种失效的计划有兴致的能够看《页面跳转时，统计数据丧失题目讨论》

• window.name

把要跳转的url放到window.name中，然后鄙人一个页面上上报点击。window.name的寄义是取得/设置窗口的称号，这个属性是跨域的，当窗口存在的时刻，window.name就存在；每一个窗口的称号都能够是不一样的。
在这个计划中，window.name被当做了一个存储上报点击地点的介质。

虽然这个计划处理了体验差的题目，然则要完成这个计划，就要在一切的页面上都布置处置惩罚window.name的代码。举一个简朴的例子，你是一个网站主，点击一个广告跳转广告落地页，总不能请求在这个广告落地页上也布置你的代码，所以这类计划也有很大的局限性。

• cookie和localStorage

这类计划与window.name的计划相似，然则由于cookie和localStorage的生命周期比window.name的生命周期更长。我们就可以够将延时上报的代码放到我们之前的页面上去：每当用户在跳转页面时涌现了上报丧失的状况，就将这个上报地点写入cookie或许localStorage中，然后等用户再次回到我们的页面上时，推断下这两个存储介质中是不是有值，有值则上报即可。

这类计划无需对一切的页面都加监控代码，然则如果某些极度状况，用户去了别的页面一去不返，或许间隔了一个很长的时候（诸如2天），那对我们团体统计数据上都邑有个误差。

• Beacon API

这是W3C委员会给的浏览器异步请求发送API。它能够保证纵然页面在unload状态下，也会异步发送统计，不影响页面过渡/跳转到下跳页。然则，它的浏览器支撑率一直是个题目。

停止本文发稿时（2018年02月04日），支撑率以下：

能够看到至关重要的ios safari终究在11.3版本支撑了这一特征，然则，我更新了IOS的最新版本：11.2.5！预计还须要两个月这个特征才被运用。而IOS近来爆出的晋级变慢门又会进一步拖慢新版本的掩盖时候，难熬痛苦了呀，老哥！

• 背景上报

说过来覆过去，无非是前端浏览器abort了请求，假如背景同砚给给力，题目不就处理了吗？一种处理计划是前端把一切须要上报的内容扔给背景，让背景去举行上报并举行302跳转。这是最圆满的计划吗？

前台Yes, 背景No。

总结

只管如今我们照样没有一个圆满的处理计划，然则在不久的未来，我们就可以运用到Beacon API。你问我如今怎么办？先运用cookie/localStorage的计划顶一顶吧。

过两天我会给出细致代码完成。