問(wèn)題: 用戶掃碼二維碼A,小程序onload中傳遞q參數(shù)為二維碼地址B,且該二維碼地址為用戶歷史使用二維碼地址。 原因: 微信側(cè)掃碼啟動(dòng)參數(shù)錯(cuò)亂。 用戶使用微信“掃一掃”掃描二維碼A,微信通過(guò)系統(tǒng)事件啟動(dòng)小程序,用 ...
用戶掃碼二維碼A,小程序onload中傳遞q參數(shù)為二維碼地址B,且該二維碼地址為用戶歷史使用二維碼地址。
微信側(cè)掃碼啟動(dòng)參數(shù)錯(cuò)亂。
用戶使用微信“掃一掃”掃描二維碼A,微信通過(guò)系統(tǒng)事件啟動(dòng)小程序,用戶使用完之后,
將小程序退到后臺(tái),一段時(shí)間后小程序被系統(tǒng)回收。用戶再次掃描二維碼B,
微信仍然通過(guò)系統(tǒng)事件啟動(dòng)小程序,但是實(shí)際上,系統(tǒng)先發(fā)出A二維碼的啟動(dòng)事件,
再發(fā)出B二維碼的啟動(dòng)事件,導(dǎo)致小程序啟動(dòng)參數(shù)錯(cuò)亂。
理論上,用戶第二次掃碼的時(shí)候,系統(tǒng)不應(yīng)該連續(xù)發(fā)出兩次事件。
方案1 (覆蓋7-8成用戶):
微信側(cè)目前上線了熱修復(fù)方案,糾正該問(wèn)題,保證通過(guò)系統(tǒng)事件啟動(dòng)時(shí)傳遞正確的碼地址。但目前該方案僅能覆蓋最近兩個(gè)版本,即6.5.20以后的,覆蓋人群不會(huì)很高,活躍用戶的七八成。所以仍然存在該bug.
方案2 (解決剩下的2-3成用戶):
目前掃碼啟動(dòng)小程序的場(chǎng)景,微信會(huì)將原始URL通過(guò)參數(shù)的方式傳給小程序,key為"q"。 后臺(tái)改動(dòng)上線后,會(huì)多出一個(gè)key為"scancode_time"的UNIX時(shí)間戳參數(shù),是用戶掃碼的時(shí)間。 用戶掃碼時(shí)間和執(zhí)行onlaod的時(shí)間相對(duì)比如果在30s以內(nèi),可以認(rèn)為傳遞給我們的碼地址是30s以內(nèi)剛掃過(guò)的碼,可以認(rèn)為傳遞的非歷史地址。從這個(gè)邏輯出發(fā),做了以下校驗(yàn):

ps:第二次將掃碼時(shí)間與服務(wù)器端時(shí)間再次進(jìn)行校驗(yàn)的目的:避免部分用戶手動(dòng)更改手機(jī)時(shí)間或者本地手機(jī)時(shí)間差距較大,導(dǎo)致問(wèn)題出現(xiàn),故再進(jìn)行一次服務(wù)端時(shí)間校驗(yàn)。
問(wèn)題雖小,記錄意義更大。