前言 有一個問題, 給定一個物體的運動軌跡, 包含時間和坐標的數組, 如何使用這個數據來預測物體未來的運動走勢?? 本文提供了一個很簡單的方式去實現這個演算法. 效果夠用, 又簡單, 有一定的準確程度. 緣由 以前做過的一些手機應用, 沒有做動畫的 , 也沒做手勢. 這個做起來挺麻煩的. 最近開始了新 ...
前言
有一個問題, 給定一個物體的運動軌跡, 包含時間和坐標的數組, 如何使用這個數據來預測物體未來的運動走勢??
本文提供了一個很簡單的方式去實現這個演算法. 效果夠用, 又簡單, 有一定的準確程度.
緣由
以前做過的一些手機應用, 沒有做動畫的 , 也沒做手勢. 這個做起來挺麻煩的.
最近開始了新的手機項目 (微信項目模板) , 基於 Blazor server side , 其組件化的方式可以很方便地把各種常用的通用的東西封裝成 組件/控制項
於是, 就打算讓這段時間辛苦一些, 一次過把動畫的部分補上, 讓以後的項目更加牛逼, 意思是讓客戶更加樂意地掏錢.
問題
手勢的一個問題是力度/速度判斷, 劃得快, 劃得慢, 先快後慢, 先慢後快, 都得有一個合適的演算法來得到一個最後速度.
這個演算法一定要滿足基本的需求後, 要儘量簡單, 要目測, 理論上沒有bug .
這個時候, 半衰期演算法就派上用場了. (不知道有沒有半衰期演算法這玩意, 應該說是使用半衰期的原理)
原理
這是一個很簡單的權重計算, 有很多個不同時間點的坐標, 每個相鄰時間的兩個數據, 有距離差, 有時間差
關鍵是解決先慢後快, 先快後慢的數據的處理問題, 那麼我們只需要
把新的數據, 乘以更大的權重, 把老的數據, 乘以更小的權重 , 最後得到這個距離權重的合成值, 就OK了.
預覽效果:
註意, 因為gif的幀數不夠, 要更好效果還是複製代碼運行一遍.
測試代碼:
<!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <title>Half Life</title> <style> html, body, canvas {width: 100%;height: 100%;margin: 0;padding: 0;box-sizing: border-box;overflow: hidden;} </style> </head> <body> <canvas></canvas> <script type="text/javascript"> var CONST_HALF_LIFE_SPAN = 50; //半衰期 , 設置得越小 , 就越看淡以前的速度 var CONST_MAX_SAMPLES = 15; //保留最後15個點的數據 減少無意義的運算量, 主要看瀏覽器觸發 onmousemove 的頻率來調整. var pts = []; document.onmousemove = function (e) { //儲存數據 pts.push({ time: Date.now(), x: e.clientX, y: e.clientY }); if (pts.length > CONST_MAX_SAMPLES) pts.shift(); //計算 var xs = 0, ys = 0; //走過的路的長度. var previtem = pts[0]; for (var index = 1; index < pts.length; index++) { var newitem = pts[index]; var t = newitem.time - previtem.time; //讓這個數據衰減一次, 衰減程度由時間差決定. var halflifefactor = Math.pow(0.5, t / CONST_HALF_LIFE_SPAN); //註意, 這裡沒有計算速度, 而是直接用距離來預測將來要走過的距離. // 走過的距離每一次都要衰減, 每一段的路程都多次乘以各時間差的factor, // 原理是, 0.5 ^ (t1 + t2 + t3...) 等於 0.5 ^ t1 * 0.5 ^ t2 * 0.5 ^ t3 * ... xs = xs * halflifefactor + newitem.x - previtem.x; ys = ys * halflifefactor + newitem.y - previtem.y; previtem = newitem; } //畫圖 var CONST_EFFECT_FACTOR = 2; //乘以一個因素來畫圖用, 這裡數值可以充當'摩擦繫數'大小的效果. xs = Math.floor(xs * CONST_EFFECT_FACTOR); ys = Math.floor(ys * CONST_EFFECT_FACTOR); var x0 = e.clientX, y0 = e.clientY; var canvas = document.querySelector("canvas"); var ctx = canvas.getContext("2d"); var w = canvas.width = canvas.offsetWidth; var h = canvas.height = canvas.offsetHeight; ctx.clearRect(0, 0, w, h); ctx.lineWidth = 5; ctx.strokeStyle = "blue"; ctx.beginPath(); ctx.moveTo(x0, y0); ctx.lineTo(x0 + xs, y0 + ys); ctx.closePath(); ctx.stroke(); console.log(xs, ys) } </script> </body> </html>
簡單講解
可以看出 , 代碼量非常少. 與其說這是一種"演算法" , 不然說是一種"思路"
代碼先是記錄每一點的數據, 然後放進 pts 數組
在滑鼠移動後, 使用 pts 數組, 計算出每一點的 x , y 的移動量, 讓每一段的移動量都使用 半衰期 的方式進行調整.
最後得出的 xs , ys , 是理論上 "最近移動的距離."
使用這個數值, 作為 "參考值" , 就可以用於更多的判斷.
例如我最近做的一個簡單的 swipe 組件 ,
手指滑動了 1/4 個屏幕, 然後再加上理論的參考值, 一共超過了 1/2 個屏幕, 就切換到下一個panel
這個參考值很重要. 如果手指只是很慢地滑動, 那麼參考值就很小, 就不應該切換. 如果手指很快地滑動, 那麼就應該切換panel
可改良的方案
上面方案, 是計算 '移動距離' 的, 它有一個弊端, 無論劃得多快, 移動的總數是有上限的.
這段代碼完全可以 除以 t , 得到一個 速度值,
這更加合理, 但是註意速度的合成方式不能普通地累加.
這就留給有興趣的網友自己嘗試了. 也不難. 畢竟本文傳播的是 半衰期 的思路. 不宜說太細.
擴展思路
其實這種演算法 , 一直都有人用. 很奇怪的就是, 沒有看到什麼人專門寫文章介紹?
半衰期除了計算運動軌跡, 還可以很好地去統計熱度.
例如一篇文章 , 一個視頻, 有不同時段的點擊數量. 每一天都不一樣.
怎樣使用最少的儲存方式, 去儲存一個合理的熱度參考值?
可行的方法是 , 儲存兩個數值 (就夠了) :
articleRateValue 用於儲存熱度值
articleRateTime 用於儲存熱度時間
每一次點擊, 都使用這個公式儲存 :
articleRateValue = newclickcount + articleRateValue * POW(0.5, (NOW - articleRateTime) / HALF_LIFE_SPAN )
articleRateTime = NOW
排序的時候麻煩點, 要實時的計算 articleRateValue * POW(0.5, (NOW - articleRateTime) / HALF_LIFE_SPAN ) 來得到每個文章的熱度值.
(對於排序的問題, 還有兩個變通的做法, 如果以後有時間寫一篇文章細說這個熱度方案, 再詳細解說)
(最簡單的變通方法是, 每晚找伺服器空閑的時候, 把表裡的數值都重新計算一次, 平時排序的時候不計算)
註意這裡有一個 HALF_LIFE_SPAN 的概念. 如果 HALF_LIFE_SPAN 是一天, 那麼昨天的熱度就占 1/2 權重, 前天的就占 1/4 權重 , 大前天的占 1/8
這樣按天算也有個弊端 , 我想按周, 按月算那怎麼辦 ?
再存兩組數值 :
weeklyRateValue
weeklyRateTime
monthlyRateValue
monthlyRateTime
如此類推.
這樣做的最大好處是 , 無需詳細地紀錄每一次的點擊數據. 非常節省空間.
缺點是 , 每一組數據, 只適合一個半衰期時段的數值, 要儲存多個參考值得準備多組數據.
最後
時間過得真快. 這段時間挖的坑太多, 在業餘時間內根本沒有時間填坑..
5月初的時候實現了BlazorCefApp , 到現在開了幾個有意義的坑, Blazor微信項目模板 算是一個.
但是由於沒有時間寫博客, 有時只是偶爾把測試的視頻放到 B站 : https://space.bilibili.com/540073960
有興趣用 Blazor 來做微信項目或手機網頁項目的, 可以去瞭解一下. 當項目成熟後, 會發佈到github上.
----
