發(fā)現(xiàn)問題到解決問題的經(jīng)過是這樣的。
距離下班還剩一個小時了...
突然來了一個新需求蕴侧，客戶因為場地售賣火爆需要排隊搶購禽最，所以客戶約定每天早上七點開始預訂下一周當天的場地。這就涉及到整點預訂的問題泳赋，為了優(yōu)化用戶體驗，我們約定提前十分鐘開始倒計時喇喉，讓顧客能感受運動產(chǎn)品的動感祖今，也讓產(chǎn)品朝著“好玩”進發(fā)。
一接到這個需求拣技，這個簡單呀千诬，應該可以趕上下班時間，頓時思路如涌泉：
顧客一打開頁面膏斤，立馬請求接口獲取場地售賣時間徐绑，拿到時間后結(jié)合手機時間做比較，是否到了可售賣時間莫辨，是否過了可售賣的截至時間傲茄；如果未到可售賣時間那是否到了10分鐘的倒計時時間毅访。
假設到了倒計時時間，我們開始倒數(shù)盘榨，到了可售賣時間再次調(diào)用接口刷新頁面即可實現(xiàn)倒計時搶場地效果喻粹。
至此，一頓猛虎操作草巡，開發(fā)守呜、上測試，沒問題剛好到點山憨，下班走起查乒。
剛走到地鐵站，測試發(fā)來一條信息：“你這也叫做完了沒問題郁竟，趕緊給我回來侣颂。”
內(nèi)心一驚枪孩，測試過的會有問題憔晒，趕緊往回走？
回到公司測試說正常流程是沒有問題蔑舞，但是一旦息屏了一會或者切換到其它應用去了一段時間返回應用拒担，就會出現(xiàn)倒計時不準確問題。這就納悶了攻询，都是常規(guī)代碼問題肯定是出現(xiàn)在倒計時上了从撼。細細回想了一下倒計時的機制，倒計時本身是沒有問題的钧栖，通過事件循環(huán) + 觀察者實現(xiàn)低零，同時切換應用后倒計時頁面也不存在CPU被別的I/O占用的情況；誒拯杠，不對掏婶，js在一個單線程上執(zhí)行，切換應用一段時間后這個線程雖然沒被銷毀潭陪，但是會不會被掛起來了呢雄妥，一但掛起那倒計時肯定是要走不準的了。
這就是問題的關鍵所在了依溯，不能繼續(xù)沿用倒計時自減的方案了老厌。腦子靈光一閃，那就每次倒計時都去讀取手機時間黎炉，這樣就能確保倒計時準確無誤了枝秤。哈哈，聰明慷嗜。
一頓操作...回家淀弹。
上線運行了一天丹壕，第二天得到反饋，有的倒計時不準確（快或者慢的都有）垦页，有的倒計時結(jié)束后場地狀態(tài)沒有刷新雀费。居然還有問題干奢，啟動bug分析模式...針對問題一倒計時不準確痊焊，倒計時來自于手機事件計算出啦的，那就是手機時間存在誤差了忿峻；問題二場地狀態(tài)為更新薄啥，有可能是前端倒計時結(jié)束，但是后端并未到達臨界時間逛尚，這時場地狀態(tài)肯定是不會更新的垄惧。針對這兩個問題，該怎么解決呢绰寞；
哦到逊，手機時間一般來自網(wǎng)絡時間，但是手機時間是可以手動更改的滤钱，也就是說手機的時間是不可靠的觉壶，那時間就必須來自于服務器了。但是倒計時來自于服務器件缸，那是不是每過一秒都要去請求一次服務器接口呢铜靶，這顯然是不可取的，寧愿時間不準也不能讓服務器崩潰了他炊。既要確保到點能刷出新的場地狀態(tài)（這個時間一定來自于服務器）又要確保第一次的問題不會出現(xiàn)争剿，那只能想辦法結(jié)合兩種時間了。
又一個初步的想法出來了痊末，一打開頁面即請求服務器時間蚕苇，然后通過某種映射讓它和手機時間綁定，這樣就可以解決這兩個問題了凿叠。這個映射是什么呢捆蜀？腦子有點想不清楚了。
那就筆墨伺候幔嫂。
紙上畫著邏輯關系圖辆它，一個條件一個條件的羅列出來，咦履恩，好像有那么點感覺了锰茉。
倒計時的截止時間是手機當前時間、倒計時剩余時間共同決定的切心，手機時間好辦飒筑，倒計時剩余時間 = 到點售賣時間 - 獲取的服務器時間片吊。咦，好像問題難點解決了协屡，后面的就是條件判斷 + 循環(huán)了俏脊。
截止，問題好像改完了肤晓，基本能滿足倒計時結(jié)束場地狀態(tài)會更新也不會出現(xiàn)息屏后倒計時不準確的問題爷贫。
又繼續(xù)想了一下會不會還存在什么隱藏的bug呢，這個需求好像沒有看到的這么簡單补憾。
后面百度了一下漫萄，看到很多類似的文章，大意了大意了。還有服務器的響應時間，setTimeout的精度問題岳链。
這時我腦海里想到了搶茅臺和12306搶票。
