国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

頁面跳轉(zhuǎn)時(shí)，點(diǎn)擊上報(bào)丟失問題解析

Bmob / 1020人閱讀

摘要：背景最近在工作中，遇到了頁面跳轉(zhuǎn)時(shí)點(diǎn)擊上報(bào)丟失的問題，突出表現(xiàn)在微信的上，上報(bào)后直接跳轉(zhuǎn)的失敗率達(dá)到了驚人的。對(duì)這三種失效的方案有興趣的可以看頁面跳轉(zhuǎn)時(shí)，統(tǒng)計(jì)數(shù)據(jù)丟失問題探討把要跳轉(zhuǎn)的放到中，然后在下一個(gè)頁面上上報(bào)點(diǎn)擊。

背景

最近在工作中，遇到了頁面跳轉(zhuǎn)時(shí)點(diǎn)擊上報(bào)丟失的問題，突出表現(xiàn)在微信ios的webview上，上報(bào)后直接跳轉(zhuǎn)的失敗率達(dá)到了驚人的93%。喝口水壓壓驚，開始逐步分析問題的發(fā)生。

原理

現(xiàn)代瀏覽器越來越快，尤其是Chrome的v8內(nèi)核，跑的那叫一個(gè)迅速。但是必須看到的是，在不同的平臺(tái)上，瀏覽器之間的實(shí)現(xiàn)還是略有不同的。就拿頁面跳轉(zhuǎn)時(shí)點(diǎn)擊上報(bào)丟失的問題來看，PC chrome瀏覽器模擬和微信 Android的Webview, 均不存在這個(gè)問題，但是在IOS端的表現(xiàn)卻如此的嚴(yán)重。

現(xiàn)在我們跨域上報(bào)的方式主要有三種，image src, jsonp和fetch。不管是哪種上報(bào)方式，在瀏覽器點(diǎn)擊跳轉(zhuǎn)時(shí)，跳轉(zhuǎn)前的點(diǎn)擊上報(bào)請(qǐng)求都會(huì)進(jìn)行一個(gè)三次握手，如果此時(shí)，網(wǎng)絡(luò)較慢、服務(wù)器運(yùn)行緩慢或者上報(bào)請(qǐng)求還在處理階段，這時(shí)，如果頁面被卸載了，瀏覽器都會(huì)自動(dòng)對(duì)當(dāng)前的請(qǐng)求進(jìn)行abort。這樣，這個(gè)http的請(qǐng)求就沒有建立，導(dǎo)致上報(bào)沒有真正發(fā)出。

這部分我還有個(gè)疑問，按理說只要fetch請(qǐng)求發(fā)出，即使是abort也是假的abort，因?yàn)楝F(xiàn)在根本就沒有fetch的abort API，但是從我統(tǒng)計(jì)的數(shù)據(jù)上來看，確實(shí)有一部分曝光上報(bào)消失了（在fiddler截單看到發(fā)出了請(qǐng)求），非常的詭異。我會(huì)繼續(xù)關(guān)注這個(gè)問題。
解決方案

說到解決方案，那就海了去了，但是能打的其實(shí)一個(gè)也沒有。下面我會(huì)把我認(rèn)為還OK的方法加粗。

加一個(gè)delay

這應(yīng)該是最簡(jiǎn)單的方案了吧，沒有什么是setTimeout 1s不能解決的，如果有，那就2s……但是這種方案不管是對(duì)用戶的體驗(yàn)，還是對(duì)代碼的優(yōu)雅，都損害特別大。除非真的是對(duì)性能不太在意，不然這招是用不出來的。

之前類似的方案還有：
1. 阻塞式的 Ajax 請(qǐng)求
2. 暴力的死循環(huán)
3. 發(fā)一個(gè)圖片請(qǐng)求阻塞

當(dāng)然這些方案在chrome瀏覽器上都應(yīng)該失效了，但是他們與delay的原理和優(yōu)缺點(diǎn)都是類似的。對(duì)這三種失效的方案有興趣的可以看《頁面跳轉(zhuǎn)時(shí)，統(tǒng)計(jì)數(shù)據(jù)丟失問題探討》

window.name

把要跳轉(zhuǎn)的url放到window.name中，然后在下一個(gè)頁面上上報(bào)點(diǎn)擊。window.name的含義是獲得/設(shè)置窗口的名稱，這個(gè)屬性是跨域的，當(dāng)窗口存在的時(shí)候，window.name就存在；每個(gè)窗口的名稱都可以是不一樣的。
在這個(gè)方案中，window.name被當(dāng)做了一個(gè)存儲(chǔ)上報(bào)點(diǎn)擊地址的介質(zhì)。

雖然這個(gè)方案解決了體驗(yàn)差的問題，但是要實(shí)現(xiàn)這個(gè)方案，就要在所有的頁面上都部署處理window.name的代碼。舉一個(gè)簡(jiǎn)單的例子，你是一個(gè)網(wǎng)站主，點(diǎn)擊一個(gè)廣告跳轉(zhuǎn)廣告落地頁，總不能要求在這個(gè)廣告落地頁上也部署你的代碼，所以這種方案也有很大的局限性。

cookie和localStorage

這種方案與window.name的方案類似，但是因?yàn)閏ookie和localStorage的生命周期比window.name的生命周期更長(zhǎng)。我們就可以將延時(shí)上報(bào)的代碼放到我們之前的頁面上去：每當(dāng)用戶在跳轉(zhuǎn)頁面時(shí)出現(xiàn)了上報(bào)丟失的情況，就將這個(gè)上報(bào)地址寫入cookie或者localStorage中，然后等用戶再次回到我們的頁面上時(shí)，判斷下這兩個(gè)存儲(chǔ)介質(zhì)中是否有值，有值則上報(bào)即可。

這種方案無需對(duì)所有的頁面都加監(jiān)控代碼，但是若是某些極端情況，用戶去了別的頁面一去不返，或者間隔了一個(gè)很長(zhǎng)的時(shí)間（諸如2天），那對(duì)我們整體統(tǒng)計(jì)數(shù)據(jù)上都會(huì)有個(gè)偏差。

Beacon API

這是W3C委員會(huì)給的瀏覽器異步請(qǐng)求發(fā)送API。它可以保證即使頁面在unload狀態(tài)下，也會(huì)異步發(fā)送統(tǒng)計(jì)，不影響頁面過渡/跳轉(zhuǎn)到下跳頁。但是，它的瀏覽器支持率一直是個(gè)問題。

截止本文發(fā)稿時(shí)（2018年02月04日），支持率如下：

可以看到至關(guān)重要的ios safari終于在11.3版本支持了這一特性，但是，我更新了IOS的最新版本：11.2.5！估計(jì)還需要兩個(gè)月這個(gè)特性才能被使用。而IOS最近爆出的升級(jí)變慢門又會(huì)進(jìn)一步拖慢新版本的覆蓋時(shí)間，難受了呀，老哥！

后臺(tái)上報(bào)

說過來覆過去，無非是前端瀏覽器abort了請(qǐng)求，如果后臺(tái)同學(xué)給給力，問題不就解決了嗎？一種解決方案是前端把所有需要上報(bào)的內(nèi)容扔給后臺(tái)，讓后臺(tái)去進(jìn)行上報(bào)并進(jìn)行302跳轉(zhuǎn)。這是最完美的方案嗎？

前臺(tái)Yes, 后臺(tái)No。

總結(jié)

盡管現(xiàn)在我們還是沒有一個(gè)完美的解決方案，但是在不久的將來，我們就能使用到Beacon API。你問我現(xiàn)在怎么辦？先使用cookie/localStorage的方案頂一頂吧。

過兩天我會(huì)給出詳細(xì)代碼實(shí)現(xiàn)。

文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址：http://m.specialneedsforspecialkids.com/yun/107226.html

相關(guān)文章

  • 頁面跳轉(zhuǎn)時(shí)，點(diǎn)擊上報(bào)丟失問題解析

    摘要：背景最近在工作中，遇到了頁面跳轉(zhuǎn)時(shí)點(diǎn)擊上報(bào)丟失的問題，突出表現(xiàn)在微信的上，上報(bào)后直接跳轉(zhuǎn)的失敗率達(dá)到了驚人的。對(duì)這三種失效的方案有興趣的可以看頁面跳轉(zhuǎn)時(shí)，統(tǒng)計(jì)數(shù)據(jù)丟失問題探討把要跳轉(zhuǎn)的放到中，然后在下一個(gè)頁面上上報(bào)點(diǎn)擊。 背景 最近在工作中，遇到了頁面跳轉(zhuǎn)時(shí)點(diǎn)擊上報(bào)丟失的問題，突出表現(xiàn)在微信ios的webview上，上報(bào)后直接跳轉(zhuǎn)的失敗率達(dá)到了驚人的93%。喝口水壓壓驚，開始逐步分析問...

    gclove 評(píng)論0 收藏0

  • JS魔法堂:定義頁面的Dispose方法——[before]unload事件啟示錄

    摘要：坑無視和是十分特殊的事件，要求事件處理函數(shù)內(nèi)部不能阻塞當(dāng)前線程，而卻恰恰就會(huì)阻塞當(dāng)前線程，因此規(guī)范中以明確在和中直接無視這幾個(gè)方法的調(diào)用。 前言 ?最近實(shí)施的同事報(bào)障，說用戶審批流程后直接關(guān)閉瀏覽器，操作十余次后系統(tǒng)就報(bào)用戶會(huì)話數(shù)超過上限，咨詢4A同事后得知登陸后需要顯式調(diào)用登出API才能清理4A端，否則必然會(huì)超出會(huì)話上限。?即使在頁面上增添一個(gè)登出按鈕也無法保證用戶不會(huì)直接關(guān)掉瀏覽器...

    Chiclaim 評(píng)論0 收藏0

  • 讓前端監(jiān)控?cái)?shù)據(jù)采集更高效

    摘要：如何在新的技術(shù)背景下讓前端數(shù)據(jù)采集工作更加完善高效，是本文討論的重點(diǎn)。具體來說，我們對(duì)前端的數(shù)據(jù)采集具體主要分為路由切換性能資源錯(cuò)誤日志上報(bào)路由切換等前端技術(shù)的快速發(fā)展使單頁面應(yīng)用盛行。 隨著業(yè)務(wù)的快速發(fā)展，我們對(duì)生產(chǎn)環(huán)境下的問題感知能力越來越關(guān)注。作為距離用戶最近的一層，前端的表現(xiàn)是否可靠、穩(wěn)定、好用，很大程度上決定著用戶對(duì)整個(gè)產(chǎn)品的體驗(yàn)和感受。因此，對(duì)于前端的監(jiān)控不容忽視。 搭建一...

    Half 評(píng)論0 收藏0

  • 前端監(jiān)控和前端埋點(diǎn)方案設(shè)計(jì)

    摘要：異常監(jiān)控包括前端腳本執(zhí)行報(bào)錯(cuò)等。本文針對(duì)整個(gè)前端監(jiān)控，設(shè)計(jì)適用的方案。前端埋點(diǎn)系統(tǒng)的前后端通信加密在上報(bào)數(shù)據(jù)的前后端通信中，需要和端協(xié)商加密機(jī)制，利用庫來實(shí)現(xiàn)的加密，已經(jīng)是一個(gè)廣泛被采用的加密算法。 在線上項(xiàng)目中,需要統(tǒng)計(jì)產(chǎn)品中用戶行為和使用情況，從而可以從用戶和產(chǎn)品的角度去了解用戶群體，從而升級(jí)和迭代產(chǎn)品，使其更加貼近用戶。用戶行為數(shù)據(jù)可以通過前端數(shù)據(jù)監(jiān)控的方式獲得，除此之外，前端還...

    April 評(píng)論0 收藏0

  • 前端監(jiān)控和前端埋點(diǎn)方案設(shè)計(jì)

    摘要：異常監(jiān)控包括前端腳本執(zhí)行報(bào)錯(cuò)等。本文針對(duì)整個(gè)前端監(jiān)控，設(shè)計(jì)適用的方案。前端埋點(diǎn)系統(tǒng)的前后端通信加密在上報(bào)數(shù)據(jù)的前后端通信中，需要和端協(xié)商加密機(jī)制，利用庫來實(shí)現(xiàn)的加密，已經(jīng)是一個(gè)廣泛被采用的加密算法。 在線上項(xiàng)目中,需要統(tǒng)計(jì)產(chǎn)品中用戶行為和使用情況，從而可以從用戶和產(chǎn)品的角度去了解用戶群體，從而升級(jí)和迭代產(chǎn)品，使其更加貼近用戶。用戶行為數(shù)據(jù)可以通過前端數(shù)據(jù)監(jiān)控的方式獲得，除此之外，前端還...

    Hwg 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

最新活動(dòng)
閱讀需要支付1元查看
<