一種基于用戶交互歷史信息的cpu動態(tài)調(diào)頻方法
【技術(shù)領域】
[0001] 本發(fā)明涉及CPU動態(tài)調(diào)頻領域，尤其涉及一種基于用戶交互歷史信息的CPU動態(tài) 調(diào)頻方法。
【背景技術(shù)】
[0002] Android系統(tǒng)是基于Linux內(nèi)核的，Linux中支持CPU變頻技術(shù)，并且提供多種調(diào) 頻模式。變頻技術(shù)是指CPU本身支持在多種不同的頻率下運行，系統(tǒng)在運行過程中可以根 據(jù)隨時可能發(fā)生變化的系統(tǒng)負載情況動態(tài)在這些不同的運行頻率之間切換，從而達到對性 能和能耗的權(quán)衡。Linux -般支持這幾種常見的CPU調(diào)節(jié)模式：Performance, Ondemand, P owersave, Conservative, Userspace, Interactive0Performance :高性會泛模式，以最高步頁率 運行，即使系統(tǒng)負載非常低，CPU也運行在最高頻率。性能很好，功耗高。Ondemand :按需模 式，按需調(diào)節(jié)CPU頻率，手機一般默認使用的是Ondemand governor即按需調(diào)節(jié)，在該模式 下，系統(tǒng)會定期檢查CPU使用率，當CPU使用率超過某個閾值up_threShold的時候就跳到 手機的最高頻率去執(zhí)行。不操作手機時控制在較低頻率，滑屏或進入應用時會迅速提升至 最高頻率，當空閑時又會迅速降低頻率，性能較穩(wěn)定，但因頻率變化幅度過大，省電方面只 有一般水平。是一種電池和性能之間趨向平衡的默認模式。Powersave:省電模式，以最低 頻率運行，日常極少使用，除非配合setCPU情景模式，關(guān)屏睡眠時使用此模式，省電但系統(tǒng) 響應速度慢。Conservative :保守模式，類似于Ondemand，但調(diào)整相對較緩，規(guī)則是"慢升快 降"，注重省電，當有高需求時逐漸提高頻率。Userspace :用戶模式，系統(tǒng)將變頻策略的決 策權(quán)交給了用戶態(tài)應用程序，并提供了相應的接口供用戶態(tài)應用程序調(diào)節(jié)CPU運行頻率使 用。Interactive :交互模式，和Ondemand模式相似，規(guī)則是"快升慢降"，注重響應速度、性 能，當有高需求時迅速跳到高頻率，當?shù)托枨髸r逐漸降低頻率，相比Ondemand費電，性能略 好。
[0003] 現(xiàn)在的Android智能手機默認的調(diào)節(jié)模式是Ondemand或者Interactive模式，這 兩種調(diào)頻模式都偏向于高頻執(zhí)行，在用戶交互過程中點擊或者滑動，執(zhí)行應用過程都會觸 發(fā)CPU迅速跳到最高頻率執(zhí)行，這種高頻往往會導致高能耗，但許多場景并不是需要最高 頻率去執(zhí)行，這樣會導致能耗的浪費；另外Ondemand governor只考慮了 CPU的使用率，而 300MHz下40 %的CPU使用率與600MHz下的40 %的CPU使用率代表完全不一樣的計算量。 在用戶交互場景中，用戶操作通常是間歇性的，點擊或者滑屏后，瀏覽一會然后再進行下一 次交互動作。在現(xiàn)有的Ondemand模式下，一旦用戶開始與手機交互CPU會變得繁忙從而跳 到最高頻率執(zhí)行，沒有考慮到交互場景的情況，并不是每一次交互都需要最高頻率來滿足 性能需求，不同的交互場景對CPU資源的消耗需求也不同。Ondemand governor這種CPU 調(diào)控模式在能耗方面表現(xiàn)不理想。

【發(fā)明內(nèi)容】

[0004] 為解決現(xiàn)有技術(shù)中存在高性能伴隨高能耗的問題，本發(fā)明提供一種基于用戶交互 歷史信息的CPU動態(tài)調(diào)頻方法。
[0005] 本發(fā)明基于用戶交互歷史信息的CPU動態(tài)調(diào)頻方法包括以下步驟：S11 :開始； S12 :監(jiān)聽當前應用的交互狀態(tài)；S13 :查找歷史交互信息表，確認此次交互是否發(fā)生過，如 果是，執(zhí)行步驟S14,如果否，執(zhí)行步驟S15 ;S14 :獲取歷史交互信息表中同樣的交互最大歸 一化CPU使用率，根據(jù)最大歸一化CPU使用率計算目標頻率，并根據(jù)目標頻率調(diào)節(jié)CPU頻 率，然后執(zhí)行獲取此次交互歸一化CPU使用率并保存步驟S16,所述調(diào)節(jié)CPU頻率是指CPU 在最低頻率與目標頻率之間進行動態(tài)調(diào)頻；S15 :設置CPU頻率調(diào)節(jié)模式為系統(tǒng)默認情況， 然后同時執(zhí)行獲取此次交互歸一化CPU使用率并保存步驟S16和步驟S17 ;步驟S16的執(zhí) 行順序為：S161 :采集CPU信息，計算CPU使用率和權(quán)重頻率；S162 :CPU歸一化負載計算； S163 :將計算出來的歸一化CPU使用率最大值存入歷史交互信息表，然后執(zhí)行步驟S18 ; S17:采集用戶交互信息，包括交互動作信息和該動作所在應用界面系信息，將所述用戶交 互信息存入歷史交互信息表，然后執(zhí)行步驟S18 ;S18 :結(jié)束。本方法采用動態(tài)調(diào)頻的方式， 既滿足性能需求同時降低能量的消耗。
[0006] 本發(fā)明作進一步改進，所述交互由用戶輸入動作開始，至該動作引起的屏幕刷新 完成結(jié)束。
[0007] 本發(fā)明作進一步改進，步驟S14中，所述歷史交互信息表中最大歸一化CPU使用率 為u，此次交互適用頻率f。= f _Xu，其中f_為設備支持的最高頻率，目標頻率值f為設 備CPU所支持的一系列可用頻率中不小于且最接近f。的頻率值，然后將最大調(diào)節(jié)頻率設為 目標頻率值f，通過調(diào)節(jié)最大調(diào)節(jié)頻率，CPU只能在最低頻率和最大調(diào)節(jié)頻率之間執(zhí)行，綜 合考慮用戶交互的場景及歷史CPU資源使用情況，以相對低的可接受的頻率運行而不犧牲 用戶體驗。
[0008] 本發(fā)明作進一步改進，步驟S15中，CPU頻率調(diào)節(jié)模式為系統(tǒng)默認情況下，CPU最大 調(diào)節(jié)頻率為設備CPU支持的最高頻率，第一次執(zhí)行時采用默認情況，但是執(zhí)行過程中采集 CHJ信息和用戶交互信息作為下次CPU頻率調(diào)節(jié)的基礎。
[0009] 本發(fā)明作進一步改進，步驟S16中，交互過程中每隔時間t采集一次CPU信息，計 算該時間段CPU使用率和權(quán)重頻率，然后進行歸一化負載計算，算出該時間段歸一化CPU使 用率。一個交互采集多次數(shù)據(jù)，使計算出的CPU數(shù)據(jù)更加準確和穩(wěn)定。
[0010] 本發(fā)明作進一步改進，步驟S161中，在時間點1讀取內(nèi)核系統(tǒng)文件獲取CPU運 行時間及頻率，記錄總的CPU時間totall和空閑時間idlel及各個頻率的運行時間，間 隔時間t，在時間點2再次讀取內(nèi)核系統(tǒng)文件獲取CPU運行時間及頻率，記錄總的CPU時 間total2、空閑時間idle2及各個頻率運行時間，CPU使用率0?1]1183 86=1-(丨(1162-idlel)/(total2 - totall)，權(quán)重頻率的計算方法為：時間點2米集各個頻率運行時間減去 時間點1采集的相應頻率的運行時間，得出各個頻率在時間t內(nèi)的運行時間，算出各個頻率 在時間t內(nèi)占的時間比，各個頻率乘以相應的時間比，然后相加得出權(quán)重頻率。權(quán)重頻率和 CPU使用率是計算歸一化CPU使用率的兩個重要參數(shù)。
[0011] 本發(fā)明作進一步改進，步驟S17中，采集用戶交互信息是通過實時監(jiān)控并收集用 戶交互信息模塊來完成，所述交互動作信息包括點擊、長按和滑動，所述應用界面信息為 Activity 信息。
[0012] 本發(fā)明作進一步改進，實時監(jiān)控并收集用戶交互信息模塊通過動態(tài)插粧方法來獲 取用戶交互信息。
[0013] 本發(fā)明作進一步改進，所述動態(tài)插粧方法是通過插粧框架xposed和插粧代碼實 現(xiàn)。
[0014] 本發(fā)明作進一步改進，所述動態(tài)插粧方法包括以下步驟：前臺應用執(zhí)行，等待用戶 輸入動作；用戶的操作動作觸發(fā)系統(tǒng)框架層的API執(zhí)行；插粧框架xposed對系統(tǒng)框架層進 行動態(tài)插粧攔截相應API并在該API執(zhí)行前或者執(zhí)行后插入插粧代碼；獲取交互動作信息 及應用界面信息。通過插粧框架xposed對相應API插入插粧代碼，即時獲取用戶交互信息。
[0015] 與現(xiàn)有技術(shù)相比，本發(fā)明的有益效果是：利用Android設備默認Ondemand governor模式，通過調(diào)整CPU最大調(diào)節(jié)頻率來限制用戶交互過程中不必要的最高頻率執(zhí) 行；借助用戶交互的歷史信息記錄能夠滿足用戶交互過程的性能需求同時降低能量的消 耗；另外，將采集的CPU使用率轉(zhuǎn)換為歸一化的使用率能更好的衡量任務的繁重程度。通過 綜合