By

文章目錄
  1. 1. 起因
  2. 2. 稱不上解法的解法吧？
  3. 3. 結論

好久好久好久以前、歷經過一段 timer 大爆炸時期，當時希望各個 time-ago 的顯示可以隨著時間變化改變。很幸運的、在這件事發生之前，就看過類似的案例。（其實是 google-doole 的案例啦~）當時還蠻有空亂 trace 的，突然想到、所以就來回憶一下。

起因

  • 各種 timeout 亂噴，導致效能不彰（到底是噴了多少 timeout）
  • timer 太多，也無法控制，當元件消失、tick 面臨需要 remove 比較好，但…。

好的、相信大家都可以想像 timeout 一多可能會有什摸樣的大爆炸情形了。 timeout 、 interval ，其實都不能算是正常邏輯的一部份，因為它其實會在執行一段時間的時候，偵測時間到了，插進去做。所以… 尼認為、這 tick 是真的時間嗎？很顯然、當時間內需要執行的事情不多的時候，這個 tick 應該會是貼近我們所認知的時間，但是、當事情多的時候呢？真的、 1 秒都不是 1 秒了。

稱不上解法的解法吧？

真正的解法、我覺得還是不要有 timeout 啦~ 但顯然不太可能，像是我們希望的 time-ago 就一定要設 timeout 。而這種 timeout 氾濫的情況好發於：各種動態訊息的網頁，像是討論區、留言板…。

那那那、那該怎摸辦呢？？？？？

嗯嗯、就是把 timer 集中起來，只有一個 time tick 囉~！這其實也是 event listener 的實作概念。(然後、各種 list 的操作覺得也是換湯不換藥啦~)

1
2
3
4
5
6
7
8
9
10
11
const addEvtListener = function(elm, evt) {
  !elm.evt[evt.type] && elm.evt[evt.type] = [];
  elm.evt[evt.type].push(evt.action);
  const listener = elm.addEventListener || elm.attachEvent;
  const runAction = (e) => {
    elm.evt[e.type].forEach((action) => action.apply(elm, [e]));
  };
  elm.evt.length === 1 && listener.apply(elm, [evt.type, runAction]);
};

好啦、現在的 listener 大概都已經統一變成 addEvtListener 了，比較少直接使用 onXXX 的方式定義 action 了，不過、以前的 listener 大概就是用類似上面的方式實現的。這樣可以綁定一次 event，但實際上有很多的 action 可以接著執行下去。

同理、timetick 也是一樣的。就是有個管理 tick 的地方，但有趣的是，這邊的實作並不是一次性的 timeout ，因為可能會有連續的不停的監聽 timer ，那… 這時候也許會想說、不用 timeout 那就是應該要用 interval 囉？也可以啦，不過、我個人比較不喜歡 interval 啦~ 一般我都還是用 setTimeout ，如果是動畫的話、就是用 requestAnimationFrame 。(不過、為什摸不用 interval 呢？其實原因有點忘了~ 太久以前看到的文章了、也許現在那些原因都不重要了也說不定。)

使用單一 timer 監聽、其實有好有壞啦~。
優點：

  • 單一 timer ，在 timeout 噴得到處的情況下，效能、管理的確是還不錯的。
    • 如果有需要，針對在 viewport 之外，或超出時間範圍內的活動，想要移除應該是沒有問題的。
  • 單位時間固定，特別是拿來實作動畫，做完 A 過 n 秒要做 B。不只 timer 可以寫成一塊、角色劇本也可以寫成一塊。(n 久以前，google doodles 不少動畫都是這樣寫的。誒、對，我就是從他那邊偷學過來的~ w+)

缺點：

  • 因為比較傾向單位時間固定、像是 1 sec ，所以、對於大家希望這個快一點、那個慢一點、這個要比那個快上一點點、那個還要再慢一點點的情況，就不好用了。
  • 單一的 timer ，所以、在時間持續往前跑的情況，進去的時機點，不一定會是那摸剛好從 0 開始，時間可能會有點延遲。但對於長時間來說、我覺得影響不大。

結論

如果說、四散的 timeout 可以很客製化的達到目的，我個人的確比較偏好單一個管理。畢竟、 timeout 我認為他本來就是個破壞秩序的東西，如果還亂噴…。也許、哪天發現或醞釀出很不錯的寫法，我之後再也不會討厭也說不定。

文章目錄
  1. 1. 起因
  2. 2. 稱不上解法的解法吧？
  3. 3. 結論