計算剩餘時間的方法
近日做一個軟體，需要計算剩餘時間。
演算法原理就是： 已經耗時*剩餘大小/已經處理的大小。
但發現了計算的速度一直抖動， 發現是因為UI在沒有進度回撥時，也在重新整理剩餘時間，這樣導致了誤差。
比如處理1G大小的資料 已經處理了100M 耗時100S， 那麼剩餘時間就是900S。
如果耗時100.3S時又計算速度，而此時還是隻處理了100M（底層沒有回撥）， 那麼剩餘時間就是902.7S。
假如在100.5時回調了進度100.5M，那麼剩餘時間就又是900S，這樣就有了抖動。
所以正確方法是，只有在底層回撥進度時進行計算剩餘時間，抖動就少了很多。
現在計算一下正常速度變化， 會不會造成抖動。 假設平均速度時1M/1S
但突然在5秒內速度變成了0.5M/S. 總大小1000M。
100S 100M 剩餘時間900S
100.5S 100.25M 剩餘時間901.99S 正常情況是899秒
101S 100.5M 剩餘時間903.975 正常情況是898秒
....
....
....
但這些是正常結果，就是因為速度變慢了，但可以很大程度解決上面提到的抖動BUG。
假如回撥的速度時一次0.95 一次1.05 看看抖動如何，以秒為單位：
總大小1000M。
100S 100M 剩餘時間900S
101S 100.95M 剩餘時間899.49 大約期望的值
102S 102M 剩餘時間898 和正常一樣
103S 102.95M 剩餘時間897.48 大約期望的值
在這樣的誤差情況下，剩餘時間基本還是遞減的，不會抖動。
現在計算一下抖動的臨界狀態：
t1 = 已經耗時*剩餘大小/已經處理的大小。
t2= ( 已經耗時+dt) * (剩餘大小-dm) / (已經處理的大小+dm)。
dt 是時間間隔， dm是當前處理的大小。 要抖動 就得t2<=t1
也就是速度突然滿到一定程度（比如0），那麼t2就會比t1還大。 以一個比值，這裡就不計算了。
但如果把前面當成整體，承認這個公式的正確性，那麼結果也是值得信賴的， 因為速度的不可預知， 剩餘時間肯定也是變化的。