一種CPU資源分配方法和終端與流程
2023-05-20 13:34:16 3

本發明涉及終端技術領域,尤其涉及一種cpu資源分配方法和終端。
背景技術:
目前,隨著網際網路的發展和終端技術的發展,人們越來越依賴於終端,尤其是移動終端來完成衣食住行等方方面面的事情。各種功能、各種類型的應用應運而生,為用戶提供服務。隨之而來的是用戶終端上裝載的應用越來越多,所以移動終端需要同時運行的程序、進程的數量也越來越大。
為了終端能夠運行流暢,帶給用戶良好的體驗,終端上的cpu核在短短幾年之間從兩核到四核再到八核。雖然如今的終端廠商極力增加cpu的數量和提高cpu的頻率,但是隨著應用提供的功能類型的增多以及功能的逐漸強大和全面,用戶終端上裝載的應用也越來越多,終端需要運行的進程也越來越多,單單依靠在終端上提高cpu數量和頻率的方式已經不能滿足用戶的需要了,而且cpu數量和頻率的提高對終端廠商而言意味著終端成本的增加,此外更多的cpu意味著更多的功耗,這對終端的續航能力也提出了新的要求。因此,現有技術中急需一種既能保證用戶體驗流暢度,又能合理分配cpu資源,在不影響終端性能的同時,又能夠降低終端功耗的方案。
技術實現要素:
本發明的主要目的在於提出一種cpu資源分配方法和終端,旨在解決現有技術中缺乏既能保證用戶體驗流暢度,又能合理分配cpu資源,在不影響終端性能的同時降低終端功耗的方案的問題。
為實現上述目的,本發明提供的一種終端,包括:
設置模塊,用於確定終端內處於非終止狀態的進程,根據進程對用戶與終端的交互體驗的重要程度,將進程劃分為預設的不同等級的cpu設置節點;
監測模塊,用於監測終端內各個cpu核心的狀態,確定當前在線的cpu核心的信息;
分配模塊,用於根據各個cpu設置節點的等級的高低,為各個cpu設置節點分配運行進程的在線cpu核心的資源。
進一步的,監測模塊,用於為每個cpu核心設置監視器,利用監視器監聽對應的各cpu核心的系統文件變化;當系統文件發生變化,讀取變化後的內容,根據內容確定各cpu核心是否在線。
進一步的,分配模塊,用於若在線cpu核心的頻率相同,則按照cpu設置節點的等級高低為各等級cpu設置節點設置在線cpu核心的分配數量;其中,同一cpu核心可同時分配給不同等級的cpu設置節點;否則,則優先將高頻率的在線cpu核心分配給等級高的cpu設置節點,以及為等級高的cpu設置節點分配更多數量的cpu核心。
進一步的,設置模塊,用於根據進程當前所需的cpu核心資源的高低,將進程劃分為等級不同的cpu設置節點;cpu設置節點等級越高,對應的進程所需的cpu核心資源越高;或者,根據進程是否與用戶直接交互,將進程劃分為不同類型,將不同類型的進程劃分為不同等級的cpu設置節點。
進一步的,設置模塊,用於將終端內處於非終止狀態的進程按照前臺進程、後臺進程、系統進程分為三類,分別對應於前臺進程節點、後臺進程節點、系統進程節點;前臺進程節點等級最高,後臺進程節點等級最低。
為實現上述目的,本發明還提供的一種cpu資源分配方法,包括:
確定終端內處於非終止狀態的進程,根據進程對用戶與終端的交互體驗的重要程度,將進程劃分為預設的不同等級的cpu設置節點;
監測終端內各個cpu核心的狀態,獲取當前在線的cpu核心的信息;
根據各個cpu設置節點的等級的高低,為各個cpu設置節點分配運行進程的在線cpu核心的資源。
進一步的,監測終端內各個cpu核心的狀態,確定當前在線的cpu核心的信息包括:
為每個cpu核心設置監視器,利用監視器監聽對應的各cpu核心的系統文件變化;
當系統文件發生變化,讀取變化後的內容,根據內容確定各cpu核心是否在線。
進一步的,根據各個cpu設置節點的等級的高低,為各個cpu設置節點分配運行進程的在線cpu核心的資源包括:
若在線cpu核心的頻率相同,則按照cpu設置節點的等級高低為各等級cpu設置節點設置在線cpu核心的分配數量;其中,同一cpu核心可同時分配給不同等級的cpu設置節點;
否則,則優先將高頻率的在線cpu核心分配給等級高的cpu設置節點,以及為等級高的cpu設置節點分配更多數量的cpu核心。
進一步的,根據進程對用戶與終端的交互體驗的重要程度,將進程劃分為預設的不同等級的cpu設置節點包括:
根據進程當前所需的cpu核心資源的高低,將進程劃分為等級不同的cpu設置節點;cpu設置節點等級越高,對應的進程所需的cpu核心資源越高;
或者,根據進程是否與用戶直接交互,將進程劃分為不同類型,將不同類型的進程劃分為不同等級的cpu設置節點。
進一步的,根據進程是否與用戶直接交互,將進程劃分為不同類型,將不同類型的進程劃分為不同等級的cpu設置節點包括包括:
將終端內處於非終止狀態的進程按照前臺進程、後臺進程、系統進程分為三類,分別對應於前臺進程節點、後臺進程節點、系統進程節點;前臺進程節點等級最高,後臺進程節點等級最低。
採用本發明,終端可以確定自身處於非終止狀態的進程,根據這些進程對用戶與終端的交互體驗的重要程度,將進程劃分為預設的不同等級的cpu設置節點;並監測終端內各個cpu核心的狀態,獲取當前在線的cpu核心的信息;根據各個cpu設置節點的等級的高低,為各個cpu設置節點分配運行進程的在線cpu核心的資源。由於本發明中是根據各cpu核心在線情況以及處於非終止狀態的進程的重要性,動態地為處於非終止狀態的進程分配運行該進程的cpu核心資源,可以保證重要進程的運行,提高了android整體性能,保證用戶體驗的流暢,並且在此基礎上儘可能降低終端功耗,從而達到性能與功耗的平衡。在終端使用過程中,進程分類、cpu核心資源分配策略,都可以二次微調,進一步保證終端的性能與功耗的平衡。
附圖說明
圖1為實現本發明各個實施例的移動終端的硬體結構示意圖;
圖2是本發明的一種終端的模塊示意圖;
圖3是本發明的圖2中的終端識別前臺進程、後臺進程的方法的流程圖;
圖4是本發明的圖2中的終端動態監測cpu核心狀態的方法的流程圖;
圖5是本發明一種終端的硬體結構示意圖;
圖6是本發明的一種cpu資源分配方法的流程圖;
圖7是本發明的一種識別前臺進程、後臺進程的方法的流程圖。
本發明目的的實現、功能特點及優點將結合實施例,參照附圖做進一步說明。
具體實施方式
應當理解,此處所描述的具體實施例僅僅用以解釋本發明,並不用於限定本發明。
現在將參考附圖描述實現本發明各個實施例的移動終端。在後續的描述中,使用用於表示元件的諸如「模塊」、「部件」或「單元」的後綴僅為了有利於本發明的說明,其本身並沒有特定的意義。因此,"模塊"與"部件"可以混合地使用。
移動終端可以以各種形式來實施。例如,本發明中描述的終端可以包括諸如行動電話、智慧型電話、筆記本電腦、數字廣播接收器、pda(個人數字助理)、pad(平板電腦)、pmp(可攜式多媒體播放器)、導航裝置等等的移動終端以及諸如數字tv、臺式計算機等等的固定終端。下面,假設終端是移動終端,然而,本領域技術人員將理解的是,除了特別用於移動目的的元件之外,根據本發明的實施方式的構造也能夠應用於固定類型的終端。
圖1為實現本發明各個實施例一個可選的移動終端的硬體結構示意圖。
移動終端100可以包括無線通信單元110、a/v(音頻/視頻)輸入單元120、用戶輸入單元130、感測單元140、輸出單元150、存儲器160、接口單元170、控制器180和電源單元190等等。圖1示出了具有各種組件的移動終端,但是應理解的是,並不要求實施所有示出的組件,可以替代地實施更多或更少的組件,將在下面詳細描述移動終端的元件。
無線通信單元110通常包括一個或多個組件,其允許移動終端100與無線通信系統或網絡之間的無線電通信。例如,無線通信單元可以包括廣播接收模塊111、移動通信模塊112、無線網際網路模塊113、短程通信模塊114和位置信息模塊115中的至少一個。
廣播接收模塊111經由廣播信道從外部廣播管理伺服器接收廣播信號和/或廣播相關信息。廣播信道可以包括衛星信道和/或地面信道。廣播管理伺服器可以是生成並發送廣播信號和/或廣播相關信息的伺服器或者接收之前生成的廣播信號和/或廣播相關信息並且將其發送給終端的伺服器。廣播信號可以包括tv廣播信號、無線電廣播信號、數據廣播信號等等。而且,廣播信號可以進一步包括與tv或無線電廣播信號組合的廣播信號。廣播相關信息也可以經由移動通信網絡提供,並且在該情況下,廣播相關信息可以由移動通信模塊112來接收。廣播信號可以以各種形式存在,例如,其可以以數字多媒體廣播(dmb)的電子節目指南(epg)、數字視頻廣播手持(dvb-h)的電子服務指南(esg)等等的形式而存在。廣播接收模塊111可以通過使用各種類型的廣播系統接收信號廣播。特別地,廣播接收模塊111可以通過使用諸如多媒體廣播-地面(dmb-t)、數字多媒體廣播-衛星(dmb-s)、數字視頻廣播-手持(dvb-h),前向鏈路媒體(mediaflo@)的數據廣播系統、地面數字廣播綜合服務(isdb-t)等等的數字廣播系統接收數字廣播。廣播接收模塊111可以被構造為適合提供廣播信號的各種廣播系統以及上述數字廣播系統。經由廣播接收模塊111接收的廣播信號和/或廣播相關信息可以存儲在存儲器160(或者其它類型的存儲介質)中。
移動通信模塊112將無線電信號發送到基站(例如,接入點等等)、外部終端以及伺服器中的至少一個和/或從其接收無線電信號。這樣的無線電信號可以包括語音通話信號、視頻通話信號、或者根據文本和/或多媒體消息發送和/或接收的各種類型的數據。
無線網際網路模塊113支持移動終端的無線網際網路接入。該模塊可以內部或外部地耦接到終端。該模塊所涉及的無線網際網路接入技術可以包括wlan(無線lan)(wi-fi)、wibro(無線寬帶)、wimax(全球微波互聯接入)、hsdpa(高速下行鏈路分組接入)等等。
短程通信模塊114是用於支持短程通信的模塊。短程通信技術的一些示例包括藍牙tm、射頻識別(rfid)、紅外數據協會(irda)、超寬帶(uwb)、紫蜂tm等等。
位置信息模塊115是用於檢查或獲取移動終端的位置信息的模塊。位置信息模塊的典型示例是gps(全球定位系統)。根據當前的技術,gps模塊115計算來自三個或更多衛星的距離信息和準確的時間信息並且對於計算的信息應用三角測量法,從而根據經度、緯度和高度準確地計算三維當前位置信息。當前,用於計算位置和時間信息的方法使用三顆衛星並且通過使用另外的一顆衛星校正計算出的位置和時間信息的誤差。此外,gps模塊115能夠通過實時地連續計算當前位置信息來計算速度信息。
a/v輸入單元120用於接收音頻或視頻信號。a/v輸入單元120可以包括相機121和麥克風1220,相機121對在視頻捕獲模式或圖像捕獲模式中由圖像捕獲裝置獲得的靜態圖片或視頻的圖像數據進行處理。處理後的圖像幀可以顯示在顯示模塊151上。經相機121處理後的圖像幀可以存儲在存儲器160(或其它存儲介質)中或者經由無線通信單元110進行發送,可以根據移動終端的構造提供兩個或更多相機121。麥克風122可以在電話通話模式、記錄模式、語音識別模式等等運行模式中經由麥克風接收聲音(音頻數據),並且能夠將這樣的聲音處理為音頻數據。處理後的音頻(語音)數據可以在電話通話模式的情況下轉換為可經由移動通信模塊112發送到移動通信基站的格式輸出。麥克風122可以實施各種類型的噪聲消除(或抑制)算法以消除(或抑制)在接收和發送音頻信號的過程中產生的噪聲或者幹擾。
用戶輸入單元130可以根據用戶輸入的命令生成鍵輸入數據以控制移動終端的各種操作。用戶輸入單元130允許用戶輸入各種類型的信息,並且可以包括鍵盤、鍋仔片、觸摸板(例如,檢測由於被接觸而導致的電阻、壓力、電容等等的變化的觸敏組件)、滾輪、搖杆等等。特別地,當觸摸板以層的形式疊加在顯示模塊151上時,可以形成觸控螢幕。該觸控螢幕可以作為本發明中的觸屏,該觸控螢幕可以在用戶點擊操作屏幕時,檢測到用戶觸摸觸控螢幕的位置,並將該觸摸位置上報給移動終端的終端系統進行處理。
感測單元140檢測移動終端100的當前狀態,(例如,移動終端100的打開或關閉狀態)、移動終端100的位置、用戶對於移動終端100的接觸(即,觸摸輸入)的有無、移動終端100的取向、移動終端100的加速或減速移動和方向等等,並且生成用於控制移動終端100的操作的命令或信號。例如,當移動終端100實施為滑動型行動電話時,感測單元140可以感測該滑動型電話是打開還是關閉。另外,感測單元140能夠檢測電源單元190是否提供電力或者接口單元170是否與外部裝置耦接。感測單元140可以包括接近傳感器141。
接口單元170用作至少一個外部裝置與移動終端100連接可以通過的接口。例如,外部裝置可以包括有線或無線頭戴式耳機埠、外部電源(或電池充電器)埠、有線或無線數據埠、存儲卡埠、用於連接具有識別模塊的裝置的埠、音頻輸入/輸出(i/o)埠、視頻i/o埠、耳機埠等等。識別模塊可以是存儲用於驗證用戶使用移動終端100的各種信息並且可以包括用戶識別模塊(uim)、客戶識別模塊(sim)、通用客戶識別模塊(usim)等等。另外,具有識別模塊的裝置(下面稱為"識別裝置")可以採取智慧卡的形式,因此,識別裝置可以經由埠或其它連接裝置與移動終端100連接。接口單元170可以用於接收來自外部裝置的輸入(例如,數據信息、電力等等)並且將接收到的輸入傳輸到移動終端100內的一個或多個元件或者可以用於在移動終端和外部裝置之間傳輸數據。
另外,當移動終端100與外部底座連接時,接口單元170可以用作允許通過其將電力從底座提供到移動終端100的路徑或者可以用作允許從底座輸入的各種命令信號通過其傳輸到移動終端的路徑。從底座輸入的各種命令信號或電力可以用作用於識別移動終端是否準確地安裝在底座上的信號。輸出單元150被構造為以視覺、音頻和/或觸覺方式提供輸出信號(例如,音頻信號、視頻信號、警報信號、振動信號等等)。
輸出單元150可以包括顯示模塊151、音頻輸出模塊152、警報模塊153等等。
顯示模塊151可以顯示在移動終端100中處理的信息。例如,當移動終端100處於電話通話模式時,顯示模塊151可以顯示與通話或其它通信(例如,文本消息收發、多媒體文件下載等等)相關的用戶界面(ui)或圖形用戶界面(gui)。當移動終端100處於視頻通話模式或者圖像捕獲模式時,顯示模塊151可以顯示捕獲的圖像和/或接收的圖像、示出視頻或圖像以及相關功能的ui或gui等等。
同時,當顯示模塊151和觸摸板以層的形式彼此疊加以形成觸控螢幕時,顯示模塊151可以用作輸入裝置和輸出裝置。顯示模塊151可以包括液晶顯示器(lcd)、薄膜電晶體lcd(tft-lcd)、有機發光二極體(oled)顯示器、柔性顯示器、三維(3d)顯示器等等中的至少一種。這些顯示器中的一些可以被構造為透明狀以允許用戶從外部觀看,這可以稱為透明顯示器,典型的透明顯示器可以例如為toled(透明有機發光二極體)顯示器等等。根據特定想要的實施方式,移動終端100可以包括兩個或更多顯示模塊(或其它顯示裝置),例如,移動終端可以包括外部顯示模塊(未示出)和內部顯示模塊(未示出)。觸控螢幕可用於檢測觸摸輸入壓力以及觸摸輸入位置和觸摸輸入面積。
音頻輸出模塊152可以在移動終端處於呼叫信號接收模式、通話模式、記錄模式、語音識別模式、廣播接收模式等等模式下時,將無線通信單元110接收的或者在存儲器160中存儲的音頻數據轉換音頻信號並且輸出為聲音。而且,音頻輸出模塊152可以提供與移動終端100執行的特定功能相關的音頻輸出(例如,呼叫信號接收聲音、消息接收聲音等等)。音頻輸出模塊152可以包括揚聲器、蜂鳴器等等。
警報模塊153可以提供輸出以將事件的發生通知給移動終端100。典型的事件可以包括呼叫接收、消息接收、鍵信號輸入、觸摸輸入等等。除了音頻或視頻輸出之外,警報模塊153可以以不同的方式提供輸出以通知事件的發生。例如,警報模塊153可以以振動的形式提供輸出,當接收到呼叫、消息或一些其它進入通信(incomingcommunication)時,警報模塊153可以提供觸覺輸出(即,振動)以將其通知給用戶。通過提供這樣的觸覺輸出,即使在用戶的行動電話處於用戶的口袋中時,用戶也能夠識別出各種事件的發生。警報模塊153也可以經由顯示模塊151或音頻輸出模塊152提供通知事件的發生的輸出。
存儲器160可以存儲由控制器180執行的處理和控制操作的軟體程序等等,或者可以暫時地存儲己經輸出或將要輸出的數據(例如,電話簿、消息、靜態圖像、視頻等等)。而且,存儲器160可以存儲關於當觸摸施加到觸控螢幕時輸出的各種方式的振動和音頻信號的數據。本發明中,存儲器160可以用來存儲cpu設置節點的信息,cpu設置節點對應的進程情況,為各個進程分配的cpu資源等等。
存儲器160可以包括至少一種類型的存儲介質,存儲介質包括快閃記憶體、硬碟、多媒體卡、卡型存儲器(例如,sd或dx存儲器等等)、隨機訪問存儲器(ram)、靜態隨機訪問存儲器(sram)、只讀存儲器(rom)、電可擦除可編程只讀存儲器(eeprom)、可編程只讀存儲器(prom)、磁性存儲器、磁碟、光碟等等。而且,移動終端100可以與通過網絡連接執行存儲器160的存儲功能的網絡存儲裝置協作。
控制器180通常控制移動終端的總體操作。例如,控制器180執行與語音通話、數據通信、視頻通話等等相關的控制和處理。另外,控制器180可以包括用於再現(或回放)多媒體數據的多媒體模塊181,多媒體模塊181可以構造在控制器180內,或者可以構造為與控制器180分離。控制器180可以執行模式識別處理,以將在觸控螢幕上執行的手寫輸入或者圖片繪製輸入識別為字符或圖像。
電源單元190在控制器180的控制下接收外部電力或內部電力並且提供操作各元件和組件所需的適當的電力。
這裡描述的各種實施方式可以以使用例如計算機軟體、硬體或其任何組合的計算機可讀介質來實施。對於硬體實施,這裡描述的實施方式可以通過使用特定用途集成電路(asic)、數位訊號處理器(dsp)、數位訊號處理裝置(dspd)、可編程邏輯裝置(pld)、現場可編程門陣列(fpga)、處理器、控制器、微控制器、微處理器、被設計為執行這裡描述的功能的電子單元中的至少一種來實施,在一些情況下,這樣的實施方式可以在控制器180中實施。對於軟體實施,諸如過程或功能的實施方式可以與允許執行至少一種功能或操作的單獨的軟體模塊來實施。軟體代碼可以由以任何適當的程式語言編寫的軟體應用程式(或程序)來實施,軟體代碼可以存儲在存儲器160中並且由控制器180執行。
至此,己經按照其功能描述了移動終端。下面,為了簡要起見,將描述諸如摺疊型、直板型、擺動型、滑動型移動終端等等的各種類型的移動終端中的滑動型移動終端作為示例。因此,本發明能夠應用於任何類型的移動終端,並且不限於滑動型移動終端。
如圖1中所示的移動終端100可以被構造為利用經由幀或分組發送數據的諸如有線和無線通信系統以及基於衛星的通信系統來操作。
基於上述移動終端的硬體結構,提出本發明的終端的各個實施例,cpu資源分配方法的各個實施例。本發明的終端,包括:設置模塊,用於確定終端內處於非終止狀態的進程,根據各進程的重要程度,將進程劃分為預設的不同等級的cpu設置節點;監測模塊,用於監測終端內各個cpu核心的狀態,獲取當前在線的cpu核心的信息;分配模塊,用於根據各個cpu設置節點的等級的高低,為各個cpu設置節點分配運行進程的在線cpu核心的資源。
實施例一:
終端的進程一般有四個狀態,運行,等待,睡眠,終止,而本實施例處理的對象為終端非終止狀態的進程。參見圖2,本實施例中示出了一種終端,該終端能參考linux內核中的一種cgroups機制,對終端內處於非終止狀態的進程按照進程的重要程度分為至少兩個不同等級的cpu設置節點(cpuset節點),然後動態獲取終端內在線的cpu信息,根據cpuset節點的重要程度,為各個節點分配在線cpu資源。以便終端能夠自動限制單個或多個進程所能使用的資源,使得重要的進程可能分配到多的cpu資源,通過對cpu資源的分配保證終端的流暢度,並且在不影響性能的同事,避免新增在線cpu以便降低終端的功耗。
其中,cgroups是linux內核提供的一種機制,可以用來限制單個進程或者多個進程所能使用的資源。資源包括cpu核心、cpu時間片、內存、io、網絡數據等。其中cpuset子系統可以限制進程能夠運行的cpu核以及能夠使用的內存節點。參考上述的機制,對於當前的多核終端如當前主流的8核終端,可以利用cpuset方案來限制進程運行在哪個或哪幾個cpu核上,從而達到性能與功耗的平衡。
本實施例的終端包括:設置模塊21,用於確定終端內處於非終止狀態的進程,根據這些進程對用戶與終端的交互體驗的重要程度,將進程劃分為預設的不同等級的cpu設置節點;監測模塊22,用於監測終端內各個cpu核心的狀態,獲取當前在線的cpu核心的信息;分配模塊23,用於根據各個cpu設置節點的等級的高低,為各個cpu設置節點分配運行進程的在線cpu核心的資源。
其中,本實施例的終端一般為多核終端,終端cpu核的數量不限,可以是八核,也可以是其他核數。該終端可以是手機、平板、筆記本電腦等移動終端,也可以是桌上型電腦等固定終端,本實施例對此沒有限定。
我們知道,android提出了組件的概念,組件是搭建應用程式的「積木」;進程的概念被弱化了,它們作為進程的載體而存在。因此,進程的重要程度由它所承載的組件狀態決定的。在android中,進程(這裡主要指java進程)的管理工作由activitymanagerservice(活動管理服務,後文簡稱ams)來承擔。在ams中有一個成員變量mlruprocesses,保存著系統中所有處於非終止狀態的進程(可以理解為活著的進程,包括處於運行狀態的進程,處於等待狀態的進程,處於睡眠狀態的進程)的信息。我們對進程劃分為不同等級的cpuset節點,也是基於mlruprocesses進行的。在一個實施例中,設置模塊21,用於根據ams的成員變量保存的系統中所有活著的進程的信息,確定終端內處於非終止狀態的進程。
進一步的,設置模塊21根據處於非終止狀態的各進程對用戶與終端的交互體驗的重要程度,將進程劃分為預設的不同等級的cpu設置節點的過程中,是需要確定進程的重要程度的。關於進程對用戶與終端交互體驗的重要程度可以根據該進程對當前終端流暢度的影響確定,對應終端當前流暢度的影響高的進程(處於非終止狀態的進程)則重要程度高。
ams的成員變量mlruprocesses,根據進程重要性由低到高的順序,保存著系統中所有處於非終止狀態的進程的信息。在一個實施例中,終端對於處於非終止狀態的進程劃分cpuset節點可以直接根據mlruprocesses保存的進程的順序來進行,mlruprocesses保存的重要性高的進程劃分為等級較高的cpu設置節點。cpu設置節點的等級數量可以任意設置,但是考慮到cpu核數的限制,等級數量的設置以不超過cpu核數為宜,例如分為2-4個等級。其中,各個等級的cpu設置節點對應的進程可以根據cpu設置節點的數量和mlruprocesses保存的處於非終止狀態的進程的數量決定。例如,處於非終止狀態的進程數量為n(n為正整數)個,第一等級(等級最高)cpu設置節點對應的進程的為重要性排在前1/2n個,第二等cpu設置節點對應的進程為在第一等級cpu設置節點中進程的後1/3n個,剩下的進程劃分為第三等級cpu設置節點。
在一實施例中,設置模塊21可以根據處於非終止狀態的各進程當前所需的cpu資源的高低,將進程劃分為等級不同的cpu設置節點,例如,分別為不同等級的cpu設置節點設置對應的預設cpu資源範圍,若處於非終止狀態的進程所需的cpu資源在哪一個預設cpu資源範圍內,則將該處於非終止狀態的進程劃分為對應等級的cpuset節點,其中cpu設置節點等級的數量沒有限定。
考慮到在實際應用的時候,考慮到在終端中,需要面對用戶、與用戶交互的進程是帶給用戶直接使用體驗的進程,若是這些進程運行的cpu資源充足,則終端運行流暢,用戶體驗度好,反之終端容易出現卡頓、反應慢等問題,降低用戶體驗,所以這些進程的重要程度較高。而不需要和用戶直接交互的進程對終端流暢的體驗度影響較小,所以可以認為這些進程的重要程度稍微低一些。所以在一個實施例中,設置模塊21,用於根據處於非終止狀態的的各進程是否與用戶直接交互,將處於非終止狀態的的各進程劃分為不同類型,將不同類型的進程劃分為不同等級的cpu設置節點。其中,進程的類型包括但不限於系統進程,能與用戶直接交互的進程、不能與用戶直接交互的進程等等。其中,設置模塊21可以根據處於非終止狀態的的各進程是否屬於與用戶直接交互的進程類型,將處於非終止狀態的進程劃分為不同等級的cpu設置節點。例如,將與用戶直接交互的進程設置為第一等級(等級最高)cpu設置節點,將不能與用戶直接交互的進程設置為第二等級cpu設置節點。
進一步的,考慮到系統進程是維繫整個系統的進程,也比較重要,在對進程進行不同等級cpuset節點劃分時,可以將進程按照前臺進程、後臺進程和系統進程劃分為三類。設置模塊21,用於將終端內處於非終止狀態的進程按照前臺進程、後臺進程、系統進程分為三類,分別對應於前臺進程節點、後臺進程節點、系統進程節點,其中,前臺進程等級最高,後臺進程等級最低。
對於設置模塊21而言,其需要完成前臺、後臺、系統進程的識別。其中,系統進程systemserver的識別比較簡單,因為系統就一個systemserver進程。但一個進程為前臺進程foreground,還是後臺進程background,是一個動態的概念,foreground進程可能被推到後臺成為background進程,反之background進程也可能推到前臺成為foreground進程。終端需要找到對應的轉換點,在轉換點將進程移入恰當的分類,使得進程受到對應cpuset節點的控制。
進一步的,設置模塊21,用於將系統服務進程systemserver劃分為系統進程;獲取當前正處於前臺的活動,將活動的關聯進程記為疑似前臺進程;獲取當前處於非終止狀態的進程,若處於非終止狀態的進程為疑似前臺進程,則判斷該進程為前臺進程,否則為後臺進程。其中,上述活動的關聯進程包括活動所在的進程,活動所在進程綁定的服務所在的進程,活動所在進程綁定的內容提供者所在的進程;
根據android內存管理框架,在打開程序或者有程序進入後臺時都會執行updateoomadjlocked函數,所以這個函數就是一個絕佳的分析位置,我們在該函數裡面進行foreground/background的識別與轉換,
參見圖3,該圖示出了設置模塊21識別前臺進程和後臺進程的過程,其中,可以理解的是,下列過程中的進程不包括上述的systemserver進程。其中,假設cpuset節點設置為前臺進程節點、後臺進程節點、系統進程節點,其中系統服務進程systemserver劃分為系統進程節點。本實施例下述的方案是建立在已經存在前臺進程節點、後臺進程節點、系統進程節點的基礎上進行的。
根據圖3,識別前臺進程和後臺進程,並劃分cpuset節點的方法包括:
s301、執行第一獲取指令,該第一獲取指令用於從系統對應的存儲位置中獲取當前處於前臺的活動activity;
在系統中,一般updateoomadjlocked函數中存儲有當前正處於前臺的活動,所以在s301中,可以進入updateoomadjlocked函數中獲取當前處於前臺的活動。
s302、確定當前正處於前臺的活動activity,記為top-act;
s303、確定top-act所在的進程,記為top-app;
s304、獲取foreground集合,該集合包括:1、top-app;2、top-app綁定的service所在的進程;3、top-app綁定的contentprovider所在的進程;
該上述的foreground集合為前述方案中的疑似前臺進程的集合。
s305、判斷當前處於前臺的活動top-act是否處理完畢,若是,則結束,否則進入s306;
s306、從當前處於前臺的活動top-act中取出下一個需要處理的進程app;
s307、判斷該進程app是否在foreground集合內,若是,則進入s308a,否則進入s308b;
若是在第一次識別前臺進程和後臺進程的時候,例如開機的時候,手機從關機狀態啟動,只要識別出進程app在foreground集合內,就判斷是前臺進程,加入前臺進程節點,否則為後臺進程,加入後臺進程節點。下面的步驟是已經存在前臺進程節點和後臺進程節點後,對各節點對應的進程情況的更新過程。
s308a、判斷該進程app之前是否為後臺進程,若是,則進入s309a1,否則進入s309a2;
在s308a中,在判斷該進程app之前是否為後臺進程前,還可以先判斷該進程app之前是否處於被殺死的狀態,若是,則進入s309a1,直接將該進程app設置為前臺進程節點;而不用再判斷該進程app之前是否為前臺進程。
s309a1、將進程app加入前臺進程節點(cpuset-foreground);
s309a2、說明進程app一直是前臺進程,沒有發生前臺進程和後臺進程的切換,前臺進程節點對應的進程中已經存在該進程app,所以不用處理;
s308b、判斷該進程app之前是否為前臺進程,若是,則進入s309b1,否則進入s309b2;
在s308b中,在判斷該進程app之前是否為前臺進程前,還可以先判斷該進程app之前是否處於被殺死的狀態,若是,則進入s309b1,直接將該進程app設置為後臺進程節點;而不用再判斷該進程app之前是否為後臺進程。
s309a1、將進程app加入後臺進程節點(cpuset-foreground);
s309a2、說明進程app一直是後臺進程,沒有發生前臺進程/後臺進程的切換,後臺進程節點對應的進程中已經存在該進程app,所以不用處理。
實際中,為了降功耗,當前cpu都支持dvfs(dynamicvoltageandfrequencyscaling,簡稱dvfs,動態電壓頻率調整),對於多核如8核的cpu來說,在負載很高時,8核會同時在線,但在負載較低時,只會有1-2個核在線,這也被稱作cpuhotplug。因此,為cpuset節點設置的cpu核心不能是固定的,假若是固定的,當對應的核心下線時,cpuset子節點所管轄的進程將得不到調度!極大影響了系統的性能。所以終端需要監測cpu核心在線狀態,根據當前在線的cpu核心,動態設置cpuset節點對應的cpu核心的資源。
其中,監測終端內cpu的狀態可以利用現有的安卓系統中的方案實現,也可以根據inux設備模型實現。根據linux設備模型,當第x(對於8核cpu,x的取值為集合[0,7])個cpu核心在線時,sys文件(系統文件)/sys/devices/system/cpu/cpux/online的內容為1,否則sys文件的內容為0。對於8核cpu,一共有8個對應的sys文件。所以我們可以通過設置監視器監視各個cpu的系統文件變化來實現對各cpu的在線狀態的確定。
本實施例中的監測模塊22,用於為每個cpu核心的設置監視器,利用監視器監聽對應的各cpu核心的系統文件變化;當系統文件發生變化,讀取變化後的內容,根據內容確定各個cpu核心是否在線。本實施例中每個cpu核心都有各自對應的監視器實現系統文件的監控。該監視器的設置位置可以是在系統文件中,也可以是在系統文件外,監視路徑為sys文件路徑,監視的事件包括in_modify,即sys文件中被改動,則說明cpu核心的狀態發生了改變。
進一步的,監測模塊22可以利用linux文件系統變化通知機制—inotify來監測cpu核心在線狀態,使得分配模塊23完成動態調整cpuset節點對應的cpu核心。
參見圖4,示出了監測模塊22利用inotify機制+poll系統調用來監測cpu核心在線狀態的方法,該方法是在上述圖3示出的方法之後進行。該方法的流程包括:
s401、分別為每個cpu核心的sys文件添加一個監視器inotify_watch:監視的路徑為sys文件路徑;監視的事件為in_modify,代表sys文件被改動;
若終端的cpu是8核cpu,共有8個監視器inotify_watch。
s402、利用監視器inotify_watch獲取對應的各cpu核心的狀態,加入預設的集合中;
例如將監視器inotify_watch對應inotify_device的文件描述符fd加入到pollfd集合uds中,一共8個fd;這些文件描述符可以實時反映當前的cpu核心狀態,所以在s402之後可以直接根據這些描述符fd得到在線的cpu核心信息,然後進入s405進行cpu核心資源的分配。之後,若是cpu核心的狀態發生變化,可以利用下面的步驟動態更新cpu在線信息,進而根據實際情況重新分配cpu核心資源。
s403、調用poll監聽sys文件變化,其中,如果sys文件沒有變化則一直阻塞下去,若是發生變化,則阻塞解除;
s404、判斷預設的集合是否遍歷完畢,若是,則進入s405,否則進入s406;
s405、根據當前在線cpu集合,為各個cpuset節點設置cpu核心資源;
s406、當前監視器是否監測到了系統文件變化?若是,則進入s407,否則進入s408;
s407、讀取系統文件變化後的內容,獲得對應的cpu核心在線狀態;
s408、更新當前在線cpu集合,更新方式包括:
①如果之前在線而本次下線,則從在線cpu集合中刪除對應的cpu核心;
②如果之前下線而本次上線,則將對應的cpu核心加入在線cpu集合。
更新在線cpu集合之後,可以根據當前在線cpu集合,為各個cpuset節點設置cpu核心資源。
當在線cpu核心的信息確定後,分配模塊23可以實現cpu資源的分配。其中,考慮到cpu核心的頻率可能不同,分配模塊23有以下的兩種分配方案:
第一:若在線cpu核心的頻率相同,則按照cpu設置節點的等級高低為各等級cpu設置節點設置cpu核心的分配數量;例如等級高的cpuset節點分配的cpu核心多,等級低的cpuset節點分配的cpu核心少。
其中,為了提高終端性能,同一cpu可同時分配給不同等級的cpu設置節點。
第二:若cpu核心的頻率不完全相同,則優先將高頻率的cpu分配給等級高的cpuset節點,以及為等級高的cpuset節點分配更多數量的cpu。例如假如終端上的cpu有四個大核心,四個小核心,則優先將更多的大核心分配給等級高的cpuset節點,例如上文中的前臺進程節點,第一等級cpu設置節點。
下面以cpuset節點為前臺進程節點、後臺進程節點、系統進程節點為例,說明如何合理地為cpuset節點分配核心。以下的示例僅供參考,並不對本實施例中的實際核心的分配有任何限制。
假如本實施例的終端是八核終端,cpu分為大核(對應cpu核心[4-7])、小核(對應cpu核心[0-3]),大核的頻率比小核高,當然也更耗電。所以cpuset節點的設置也要考慮大核/小核的在線狀態,這裡給出一種思路:
①大核與小核都在線時,將1個小核分給cpuset-background,1-2個小核給cpuset-systemserver,其他的小核與大核都分給cpuset-foreground;
②只有小核在線時,將1個小核分給cpuset-background,1-2個小核給cpuset-systemserver,所有小核分給cpuset-foreground,這種情況下,cpuset-background與cpuset-systemserver以及cpuset-foreground可以共用某些小核;
③只有大核在線時,將1個大核分給cpuset-background,1個大核分給cpuset-systemserver,所有大核分給cpuset-foreground。這種情況下,cpuset-background與cpuset-systemserver以及cpuset-foreground可以共用某些大核。
採用本實施例,將linux中先進的機制落地到android系統中,本技術方案掃除了在android上實施cpuset機制的障礙,使得android可以享用linux中cpuset機制的成果,提高了android整體性能。在具體實施階段,進程分類、cpu核心資源分配策略,都可以二次微調,能有效地保證終端的性能,並且在此基礎上儘可能降低終端功耗,從而達到性能與功耗的平衡,保證用戶體驗的流暢。
實施例二:
參見圖5,本實施例示出了一種終端,包括控制器51,存儲器52。控制器51用於確定終端內處於非終止狀態的進程,根據處於非終止狀態的的各進程對用戶與終端的交互體驗的重要程度,將進程劃分為預設的不同等級的cpu設置節點;監測終端內各個cpu核心的狀態,獲取當前在線的cpu核心的信息;根據各個cpu設置節點的等級的高低,為各個cpu設置節點分配運行進程的在線cpu核心的資源。其中,關於不同等級的cpu設置節點的信息以及為各個cpu設置節點分配運行進程的在線cpu核心資源的信息可以保存在存儲器52中。
其中,本實施例的終端一般為多核終端,終端cpu核的數量不限,可以是八核,也可以是其他核數。該終端可以是手機、平板、筆記本電腦等移動終端,也可以是桌上型電腦等固定終端,本實施例對此沒有限定。
我們知道,android提出了組件的概念,組件是搭建應用程式的「積木」;進程的概念被弱化了,它們作為進程的載體而存在。因此,進程的重要程度由它所承載的組件狀態決定的。在android中,進程(這裡主要指java進程)的管理工作由activitymanagerservice(活動管理服務,後文簡稱ams)來承擔。在ams中有一個成員變量mlruprocesses,保存著系統中所有處於非終止狀態的進程的信息。我們對進程劃分為不同等級的cpuset節點,也是基於mlruprocesses進行的。在一個實施例中,控制器51用於根據ams的成員變量保存的系統中所有處於非終止狀態的進程的信息,確定終端內處於非終止狀態的進程。
進一步的,控制器51根據處於非終止狀態的的各進程對用戶與終端的交互體驗的重要程度,將進程劃分為預設的不同等級的cpu設置節點的過程中,需要確定進程對用戶與終端的交互體驗的重要程度。關於該重要程度可以根據該進程對當前終端流暢度的影響確定,對應終端當前流暢度的影響高的進程則重要程度高。
ams的成員變量mlruprocesses,根據進程重要性由低到高的順序,保存著系統中所有活著的進程的信息。在一個實施例中,終端對於處於非終止狀態的進程劃分cpuset節點可以直接根據mlruprocesses保存的進程的順序來進行,mlruprocesses保存的重要性高的進程劃分為等級較高的cpu設置節點。cpu設置節點的等級數量可以任意設置,但是考慮到cpu核數的限制,等級數量的設置以不超過cpu核數為宜,例如分為2-4個等級。其中,各個等級的cpu設置節點對應的進程可以根據cpu設置節點的數量和mlruprocesses保存的處於非終止狀態的進程的數量決定。例如,處於非終止狀態的進程數量為n(n為正整數)個,第一等級(等級最高)cpu設置節點對應的進程的為重要性排在前1/2n個,第二等cpu設置節點對應的進程為在第一等級cpu設置節點中進程的後1/3n個,剩下的進程劃分為第三等級cpu設置節點。
在一實施例中,控制器51可以根據處於非終止狀態的的各進程當前所需的cpu資源的高低,將進程劃分為等級不同的cpu設置節點,例如,分別為不同等級的cpu設置節點設置對應的預設cpu資源範圍,若處於非終止狀態的進程所需的cpu資源在哪一個預設cpu資源範圍內,則將該處於非終止狀態的進程劃分為對應等級的cpuset節點,其中cpu設置節點等級的數量沒有限定。
考慮到在實際應用的時候,考慮到在終端中,需要面對用戶、與用戶交互的進程是帶給用戶直接使用體驗的進程,若是這些進程運行的cpu資源充足,則終端運行流暢,用戶體驗度好,反之終端容易出現卡頓、反應慢等問題,降低用戶體驗,所以這些進程的重要程度較高。而不需要和用戶直接交互的進程對終端流暢的體驗度影響較小,所以可以認為這些進程的重要程度稍微低一些。所以在一個實施例中,控制器51用於根據處於非終止狀態的的各進程是否與用戶直接交互,將處於非終止狀態的的各進程劃分為不同類型,將不同類型的進程劃分為不同等級的cpu設置節點。其中,進程的類型包括但不限於系統進程,能與用戶直接交互的進程、不能與用戶直接交互的進程等等。其中,控制器51可以根據處於非終止狀態的的各進程是否屬於與用戶直接交互的進程類型,將處於非終止狀態的進程劃分為不同等級的cpu設置節點。例如,將與用戶直接交互的進程設置為第一等級(等級最高)cpu設置節點,將不能與用戶直接交互的進程設置為第二等級cpu設置節點。
進一步的,考慮到系統進程是維繫整個系統的進程,也比較重要,在對進程進行不同等級cpuset節點劃分時,可以將進程按照前臺進程、後臺進程和系統進程劃分為三類。控制器51用於將終端內處於非終止狀態的進程按照前臺進程、後臺進程、系統進程分為三類,分別對應於前臺進程節點、後臺進程節點、系統進程節點,其中,前臺進程等級最高,後臺進程等級最低。
對於控制器51而言,其需要完成前臺、後臺、系統進程的識別。其中,系統進程systemserver的識別比較簡單,因為系統就一個systemserver進程。但一個進程為前臺進程foreground,還是後臺進程background,是一個動態的概念,foreground進程可能被推到後臺成為background進程,反之background進程也可能推到前臺成為foreground進程。終端需要找到對應的轉換點,在轉換點將進程移入恰當的分類,使得進程受到對應cpuset節點的控制。
進一步的,控制器51用於將系統服務進程systemserver劃分為系統進程;獲取當前正處於前臺的活動,將活動的關聯進程記為疑似前臺進程;獲取當前處於非終止狀態的進程,若處於非終止狀態的進程為疑似前臺進程,則判斷該進程為前臺進程,否則為後臺進程。其中,上述活動的關聯進程包括活動所在的進程,活動所在進程綁定的服務所在的進程,活動所在進程綁定的內容提供者所在的進程;
根據android內存管理框架,在打開程序或者有程序進入後臺時都會執行updateoomadjlocked函數,所以這個函數就是一個絕佳的分析位置,我們在該函數裡面進行foreground/background的識別與轉換,
對於控制器51識別前臺進程和後臺進程,並劃分cpuset節點的方法可以參考實施例一中的圖3以及上文關於圖3的相關說明。本實施例在此不再贅述。
實際中,為了降功耗,當前cpu都支持dvfs(dynamicvoltageandfrequencyscaling,簡稱dvfs,動態電壓頻率調整),對於多核如8核的cpu來說,在負載很高時,8核會同時在線,但在負載較低時,只會有1-2個核在線,這也被稱作cpuhotplug。因此,為cpuset節點設置的cpu核心不能是固定的,假若是固定的,當對應的核心下線時,cpuset子節點所管轄的進程將得不到調度!極大影響了系統的性能。所以終端需要監測cpu核心在線狀態,根據當前在線的cpu核心,動態設置cpuset節點對應的cpu核心的資源。
其中,控制器51監測終端內cpu的狀態可以利用現有的安卓系統中的方案實現,也可以根據inux設備模型實現。根據linux設備模型,當第x(對於8核cpu,x的取值為集合[0,7])個cpu核心在線時,sys文件(系統文件)/sys/devices/system/cpu/cpux/online的內容為1,否則sys文件的內容為0。對於8核cpu,一共有8個對應的sys文件。所以控制器51可以通過設置監視器監視各個cpu的系統文件變化來實現對各cpu的在線狀態的確定。
進一步的,本實施例中的控制器51用於為每個cpu核心的設置監視器,利用監視器監聽對應的各cpu核心的系統文件變化;當系統文件發生變化,讀取變化後的內容,根據內容確定各個cpu核心是否在線。本實施例中每個cpu核心都有各自對應的監視器實現系統文件的監控。該監視器的設置位置可以是在系統文件中,也可以是在系統文件外,監視路徑為sys文件路徑,監視的事件包括in_modify,即sys文件中被改動,則說明cpu核心的狀態發生了改變。
進一步的,控制器51可以利用linux文件系統變化通知機制—inotify來監測cpu核心在線狀態,完成動態調整cpuset節點對應的cpu核心。
對於控制器51利用inotify機制+poll系統調用來監測cpu核心在線狀態的實例,可以參見實施例一中的圖4以及相關說明。本實施例在此不再贅述。
當在線cpu核心的信息確定後,控制器51可以實現cpu資源的分配。其中,考慮到cpu核心的頻率可能不同,分配模塊23有以下的兩種分配方案:
第一:若在線cpu核心的頻率相同,則按照cpu設置節點的等級高低為各等級cpu設置節點設置cpu核心的分配數量;例如等級高的cpuset節點分配的cpu核心多,等級低的cpuset節點分配的cpu核心少。
其中,為了提高終端性能,同一cpu可同時分配給不同等級的cpu設置節點。
第二:若cpu核心的頻率不完全相同,則優先將高頻率的cpu分配給等級高的cpuset節點,以及為等級高的cpuset節點分配更多數量的cpu。例如假如終端上的cpu有四個大核心,四個小核心,則優先將更多的大核心分配給等級高的cpuset節點,例如上文中的前臺進程節點,第一等級cpu設置節點。
下面以cpuset節點為前臺進程節點、後臺進程節點、系統進程節點為例,說明控制器51如何合理地為cpuset節點分配核心。以下的示例僅供參考,並不對本實施例中的實際核心的分配有任何限制。
假如本實施例的終端是八核終端,cpu分為大核(對應cpu核心[4-7])、小核(對應cpu核心[0-3]),大核的頻率比小核高,當然也更耗電。所以cpuset節點的設置也要考慮大核/小核的在線狀態,這裡給出一種思路:
①大核與小核都在線時,控制器51將1個小核分給cpuset-background,1-2個小核給cpuset-systemserver,其他的小核與大核都分給cpuset-foreground;
②只有小核在線時,控制器51將1個小核分給cpuset-background,1-2個小核給cpuset-systemserver,所有小核分給cpuset-foreground,這種情況下,cpuset-background與cpuset-systemserver以及cpuset-foreground可以共用某些小核;
③只有大核在線時,控制器51將1個大核分給cpuset-background,1個大核分給cpuset-systemserver,所有大核分給cpuset-foreground。這種情況下,cpuset-background與cpuset-systemserver以及cpuset-foreground可以共用某些大核。
採用本實施例,android系統中可以享用linux中cpuset機制的成果,根據cpu核心在線情況以及處於非終止狀態的進程的重要性,動態地為處於非終止狀態的進程分配運行該進程的cpu核心。在具體實施階段,進程分類、cpu核心資源分配策略,都可以二次微調,能有效地保證終端的性能,並且在此基礎上儘可能降低終端功耗,從而達到性能與功耗的平衡,保證用戶體驗的流暢。
實施例三:
參見圖6,本實施例示出一種cpu資源分配方法,包括:
s601、確定終端內處於非終止狀態的進程,根據處於非終止狀態的的各進程對用戶與終端的交互體驗的重要程度,將進程劃分為預設的不同等級的cpu設置節點;
s602、監測終端內各個cpu核心的狀態,獲取當前在線的cpu核心的信息;
s603、根據各個cpu設置節點的等級的高低,為各個cpu設置節點分配運行進程的在線cpu核心的資源。
其中,本實施例的終端一般為多核終端,終端cpu核的數量不限,可以是八核,也可以是其他核數。該終端可以是手機、平板、筆記本電腦等移動終端,也可以是桌上型電腦等固定終端,本實施例對此沒有限定。
我們知道,android提出了組件的概念,組件是搭建應用程式的「積木」;進程的概念被弱化了,它們作為進程的載體而存在。因此,進程的重要程度由它所承載的組件狀態決定的。在android中,進程(這裡主要指java進程)的管理工作由activitymanagerservice(活動管理服務,後文簡稱ams)來承擔。在ams中有一個成員變量mlruprocesses,保存著系統中所有處於非終止狀態的進程的信息。我們對進程劃分為不同等級的cpuset節點,也是基於mlruprocesses進行的。在一個實施例中,s601中可以根據ams的成員變量保存的系統中所有處於非終止狀態的進程的信息,確定終端內處於非終止狀態的進程。
進一步的,s601中根據各進程的重要程度,將進程劃分為預設的不同等級的cpu設置節點的過程中,是需要確定進程的重要程度的。關於進程的重要程度可以根據該進程對當前終端流暢度的影響確定,對應終端當前流暢度的影響高的進程(處於非終止狀態的進程)則重要程度高。
ams的成員變量mlruprocesses,根據進程重要性由低到高的順序,保存著系統中所有處於非終止狀態的進程的信息。在一個實施例中,終端對於處於非終止狀態的進程劃分cpuset節點可以直接根據mlruprocesses保存的進程的順序來進行,mlruprocesses保存的重要性高的進程劃分為等級較高的cpu設置節點。cpu設置節點的等級數量可以任意設置,但是考慮到cpu核數的限制,等級數量的設置以不超過cpu核數為宜,例如分為2-4個等級。其中,各個等級的cpu設置節點對應的進程可以根據cpu設置節點的數量和mlruprocesses保存的處於非終止狀態的進程的數量決定。例如,處於非終止狀態的進程數量為n(n為正整數)個,第一等級(等級最高)cpu設置節點對應的進程的為重要性排在前1/2n個,第二等cpu設置節點對應的進程為在第一等級cpu設置節點中進程的後1/3n個,剩下的進程劃分為第三等級cpu設置節點。
在一實施例中,s601中的根據處於非終止狀態的的各進程對用戶與終端的交互體驗的重要程度,將進程劃分為預設的不同等級的cpu設置節點包括:根據處於非終止狀態的的各進程當前所需的cpu資源的高低,將進程劃分為等級不同的cpu設置節點,例如,分別為不同等級的cpu設置節點設置對應的預設cpu資源範圍,若處於非終止狀態的進程所需的cpu資源在哪一個預設cpu資源範圍內,則將該處於非終止狀態的進程劃分為對應等級的cpuset節點,其中cpu設置節點等級的數量沒有限定。
考慮到在實際應用的時候,考慮到在終端中,需要面對用戶、與用戶交互的進程是帶給用戶直接使用體驗的進程,若是這些進程運行的cpu資源充足,則終端運行流暢,用戶體驗度好,反之終端容易出現卡頓、反應慢等問題,降低用戶體驗,所以這些進程的重要程度較高。而不需要和用戶直接交互的進程對終端流暢的體驗度影響較小,所以可以認為這些進程的重要程度稍微低一些。
所以在一個實施例中,s601中的根據處於非終止狀態的的各進程對用戶與終端的交互體驗的重要程度,將進程劃分為預設的不同等級的cpu設置節點包括:根據處於非終止狀態的的各進程是否與用戶直接交互,將處於非終止狀態的的各進程劃分為不同類型,將不同類型的進程劃分為不同等級的cpu設置節點。其中,進程的類型包括但不限於系統進程,能與用戶直接交互的進程、不能與用戶直接交互的進程等等。其中,s601中可以根據處於非終止狀態的的各進程是否屬於與用戶直接交互的進程類型,將處於非終止狀態的進程劃分為不同等級的cpu設置節點。例如,將與用戶直接交互的進程設置為第一等級(等級最高)cpu設置節點,將不能與用戶直接交互的進程設置為第二等級cpu設置節點。
進一步的,考慮到系統進程是維繫整個系統的進程,也比較重要,在對進程進行不同等級cpuset節點劃分時,可以將進程按照前臺進程、後臺進程和系統進程劃分為三類。根據處於非終止狀態的的各進程的類型,將不同類型的進程劃分為不同等級的cpu設置節點包括:將終端內處於非終止狀態的進程按照前臺進程、後臺進程、系統進程分為三類,分別對應於前臺進程節點、後臺進程節點、系統進程節點,其中,前臺進程等級最高,後臺進程等級最低。
在s601中需要完成前臺、後臺、系統進程的識別。其中,系統進程systemserver的識別比較簡單,因為系統就一個systemserver進程。但一個進程為前臺進程foreground,還是後臺進程background,是一個動態的概念,foreground進程可能被推到後臺成為background進程,反之background進程也可能推到前臺成為foreground進程。終端需要找到對應的轉換點,在轉換點將進程移入恰當的分類,使得進程受到對應cpuset節點的控制。
進一步的將終端內處於非終止狀態的進程按照前臺進程、後臺進程、系統進程分為三類包括:將系統服務進程systemserver劃分為系統進程;獲取當前正處於前臺的活動,將活動的關聯進程記為疑似前臺進程;獲取當前處於非終止狀態的進程,若處於非終止狀態的進程為疑似前臺進程,則判斷該進程為前臺進程,否則為後臺進程。其中,上述活動的關聯進程包括活動所在的進程,活動所在進程綁定的服務所在的進程,活動所在進程綁定的內容提供者所在的進程;
根據android內存管理框架,在打開程序或者有程序進入後臺時都會執行updateoomadjlocked函數,所以這個函數就是一個絕佳的分析位置,我們在該函數裡面進行foreground/background的識別與轉換,
參見圖7,該圖示出了將終端內處於非終止狀態的進程按照前臺進程、後臺進程、系統進程分為三類的具體方法,該方法包括:
s701、預先設置三種cpuset節點-前臺進程節點、後臺進程節點、系統進程節點;
s702、將系統服務進程systemserver劃分為系統進程節點;
s703、執行第一獲取指令,該第一獲取指令用於從系統對應的存儲位置中獲取當前處於前臺的活動activity;
在系統中,一般updateoomadjlocked函數中存儲有當前正處於前臺的活動,所以在s703中,可以進入updateoomadjlocked函數中獲取當前處於前臺的活動。
s704、確定當前正處於前臺的活動activity,記為top-act;
s705、確定top-act所在的進程,記為top-app;
s706、獲取foreground集合,該集合包括:1、top-app;2、top-app綁定的service所在的進程;3、top-app綁定的contentprovider所在的進程;
該上述的foreground集合為前述方案中的疑似前臺進程的集合。
s707、判斷當前處於前臺的活動top-act是否處理完畢,若是,則結束,否則進入s708;
s708、從當前處於前臺的活動top-act中取出下一個需要處理的進程app;
s709、判斷該進程app是否在foreground集合內,若是,則進入s710,否則進入s711;
s710、將該進程app為前臺進程,劃分為前臺進程節點,
s711、將該進程app為後臺進程,劃分為後臺進程節點。
實際中,為了降功耗,當前cpu都支持dvfs(dynamicvoltageandfrequencyscaling,簡稱dvfs,動態電壓頻率調整),對於多核如8核的cpu來說,在負載很高時,8核會同時在線,但在負載較低時,只會有1-2個核在線,這也被稱作cpuhotplug。因此,為cpuset節點設置的cpu核心不能是固定的,假若是固定的,當對應的核心下線時,cpuset子節點所管轄的進程將得不到調度!極大影響了系統的性能。所以終端需要監測cpu核心在線狀態,根據當前在線的cpu核心,動態設置cpuset節點對應的cpu核心的資源。
其中,監測終端內cpu的狀態可以利用現有的安卓系統中的方案實現,也可以根據inux設備模型實現。根據linux設備模型,當第x(對於8核cpu,x的取值為集合[0,7])個cpu核心在線時,sys文件(系統文件)/sys/devices/system/cpu/cpux/online的內容為1,否則sys文件的內容為0。對於8核cpu,一共有8個對應的sys文件。所以我們可以通過設置監視器監視各個cpu的系統文件變化來實現對各cpu的在線狀態的確定。
本實施例中的s602中的監測終端內各個cpu核心的狀態,確定當前在線的cpu核心包括:為每個cpu核心的設置監視器,利用監視器監聽對應的各cpu核心的系統文件變化;當系統文件發生變化,讀取變化後的內容,根據內容確定各個cpu核心是否在線。本實施例中每個cpu核心都有各自對應的監視器實現系統文件的監控。該監視器的設置位置可以是在系統文件中,也可以是在系統文件外,監視路徑為sys文件路徑,監視的事件包括in_modify,即sys文件中被改動,則說明cpu核心的狀態發生了改變。
進一步的,在s602中可以利用linux文件系統變化通知機制—inotify來監測以及poll系統調用來監測cpu核心在線狀態。對於利用inotify機制+poll系統調用來監測cpu核心在線狀態的方法,參考實施例一中的圖4以及相關的敘述。本實施例在此不再贅述。
當在線cpu核心的信息確定後,可以實現cpu資源的分配。其中,考慮到cpu核心的頻率可能不同,s603根據各個cpu設置節點的等級的高低,為各個cpu設置節點分配運行進程的在線cpu核心的資源有以下的兩種分配方案:
第一:若在線cpu核心的頻率相同,則按照cpu設置節點的等級高低為各等級cpu設置節點設置cpu核心的分配數量;例如等級高的cpuset節點分配的cpu核心多,等級低的cpuset節點分配的cpu核心少。
其中,為了提高終端性能,同一cpu可同時分配給不同等級的cpu設置節點。
第二:若cpu核心的頻率不完全相同,則優先將高頻率的cpu分配給等級高的cpuset節點,以及為等級高的cpuset節點分配更多數量的cpu。例如假如終端上的cpu有四個大核心,四個小核心,則優先將更多的大核心分配給等級高的cpuset節點,例如上文中的前臺進程節點,第一等級cpu設置節點。其中,為了提高終端性能,同一cpu可同時分配給不同等級的cpu設置節點。
對於cpuset節點為前臺進程節點、後臺進程節點、系統進程節點的情況下,cpu核心資源的分配參考前兩個實施例的相關敘述,本實施例對此不再贅述。
採用本實施例,將linux中先進的機制落地到android系統中,本技術方案掃除了在android上實施cpuset機制的障礙,使得android可以享用linux中cpuset機制的成果,提高了android整體性能。在具體實施階段,進程分類、cpu核心資源分配策略,都可以二次微調,能有效地保證終端的性能,並且在此基礎上儘可能降低終端功耗,從而達到性能與功耗的平衡,保證用戶體驗的流暢。
需要說明的是,在本文中,術語「包括」、「包含」或者其任何其他變體意在涵蓋非排他性的包含,從而使得包括一系列要素的過程、方法、物品或者裝置不僅包括那些要素,而且還包括沒有明確列出的其他要素,或者是還包括為這種過程、方法、物品或者裝置所固有的要素。在沒有更多限制的情況下,由語句「包括一個……」限定的要素,並不排除在包括該要素的過程、方法、物品或者裝置中還存在另外的相同要素。
上述本發明實施例序號僅僅為了描述,不代表實施例的優劣。
通過以上的實施方式的描述,本領域的技術人員可以清楚地了解到上述實施例方法可藉助軟體加必需的通用硬體平臺的方式來實現,當然也可以通過硬體,但很多情況下前者是更佳的實施方式。基於這樣的理解,本發明的技術方案本質上或者說對現有技術做出貢獻的部分可以以軟體產品的形式體現出來,該計算機軟體產品存儲在一個存儲介質(如rom/ram、磁碟、光碟)中,包括若干指令用以使得一臺終端設備(可以是手機,計算機,伺服器,空調器,或者網絡設備等)執行本發明各個實施例的方法。
以上僅為本發明的優選實施例,並非因此限制本發明的專利範圍,凡是利用本發明說明書及附圖內容所作的等效結構或等效流程變換,或直接或間接運用在其他相關的技術領域,均同理包括在本發明的專利保護範圍內。