OS X 的合計時器聚合技術 Timer Coalescing 和 MIUI 的 對齊喚醒 機制有什麼區別?

時間 2021-06-01 20:16:02

1樓:Hank Bao

兩種技術的目的都是為了節能,使用的策略也很類似。但是兩者的粒度卻是完全不同的。前者對在CPU上執行的指令進行管理,後者對在系統中執行的程序進行管理。

從技術上說,計時器聚合要更底層,更複雜,實現難度更大。

2樓:

當理解成裝置休眠時,盡可能減少處理器喚醒次數,從而節省能量(喚醒處理器需要付出很多能源開銷)的角度來說,它們是一回事。

但是小公尺的實現對一些需要持續記錄感測器資料的應用程式產生了負面影響,它們不能正常工作了。

對於這種任務,傳統的辦法是讓AP保持上線。因為任務少,排程器只需要開啟CPU0並讓其工作在最低頻率,就算這樣的耗電量依然顯得奢侈,只要AP上線,功耗就要多出一兩百毫瓦(這個數字猜測於anandtech利用trepn profiler對Qualcomm MDP8960的評測,msm8960的乙個krait工作在最低384mhz時,有150毫瓦的功耗)。

(android的玩家也會注意到,有的應用程式沒有釋放好wakelock鎖,導致系統持續喚醒,雖然這種狀態下螢幕關閉,CPU只執行乙個且在最低頻率。即便是這樣的狀態也能在十個小時裡用光電池)

所以蘋果和Google都給出了新的方法,即利用sensor hub負責記錄,而記錄期間基本不需要AP上線,除了每隔一段時間需要調取一下打包好的記錄。

蘋果需要的sensorHub硬體是NXP(?)生產的M7。

魅族和Motorola都在新聞稿中強調了自己的SensorHub,但這些SensorHub只是為廠商的專有功能提供支援,而缺乏了Android的原生支援,開發者能從中獲得的好處有限。

Google在kitkat新增了打包感測器記錄的API便能改善目前的狀況,當然這個API也需要符合某種條件的硬體才能使用(目前只有Nexus5可使用該功能)。

如何使倒計時計時器的效能達到最優?

HumJ 迭代的會不斷累積誤差,但是直接計算可以保證絕對準確,剩下的就是看要怎麼實時的顯示出來 記錄開始的時刻 用當前時刻減去開始時刻得到逝去時間 用預設時間減去逝去時間,就是剩餘時間 然後用setTimeout setInterval requestAnimationFrame輪,延遲越小越精確,...

計時器的具體誤差是如何獲得的?

計量問題說來話長。就你舉的例子,原子鐘那個不叫誤差,準確的叫法是不確定度。每2000萬年才誤差1秒的說法是為了讓普通人容易理解。實際上應該說不確定度為1 10 15 因為原子時已經是定義了,沒有乙個可以作為參比的物件,所以沒法談誤差。而普通石英鐘與基準原子鐘進行比較,可以測出乙個差值,這個就稱作石英...

你們烹飪的時候會用計時器嗎?

門三 記性不如忘性好的人怎麼可能不用定時器呢?鍋裡煮上食物,轉身幹其他事情忘了的機率比較大,於是隨身攜帶定時器訂上時間,鈴聲響去關火,破費科特! 藏在烤箱裡的貓 中餐基本不用,一般中餐是現燒現吃。當用到烤箱時,看計時器的作用不大。還是要根據食物的情況改變烤製時間。所以用計時器的情況很少,我們也不是煮...