本發(fā)明涉及通信領域，具體而言，涉及一種節(jié)電處理方法及裝置。

背景技術：

在業(yè)內(nèi)，android手機一直有著“越用越慢”的口碑，這個現(xiàn)象甚至超出了硬件范疇——很多中高端android手機在硬件參數(shù)上都優(yōu)于同一代iphone，但是它們?nèi)匀粫谑褂冒肽甑揭荒甑臅r間后進入“欠流暢”的狀態(tài)——這無疑是一件令人困擾的事情。

目前的解決手機卡慢的通常做法是將所有正在運行的進程列出來，然后通過預置的一套黑白名單給出一個缺省是否清理的狀態(tài)，然后由用戶手動選擇哪些應用清理或者按默認狀態(tài)“一鍵節(jié)電”甚至是自動“后臺節(jié)電”。

現(xiàn)有技術中的類似產(chǎn)品也有這樣的功能，但是通過大量用戶長期使用這個功能后，發(fā)現(xiàn)目前的節(jié)電策略不夠“智能”，主要體現(xiàn)在如下方面：

大多用戶不夠“專業(yè)”，不知道如何設置修改省電時的受保護名單，導致一些需要在后臺運行的程序被自動清理掉了，影響用戶使用，或者在需要后臺自啟動時無法啟動，影響其功能的實時性甚至正常使用。

很多時候，需要實施節(jié)電策略的應用是需要根據(jù)用戶的使用情況來變化的，如聽書、音樂、電臺類應用，如果用戶正在聽音樂聽書電臺，這類進程在后臺是不能被清理的；相反，如果用戶沒有在聽書聽音樂聽電臺，這類進程如果還在后臺運行耗進程，耗cpu則需要被清理以減少手機卡慢。類似情況還有很多。

由于現(xiàn)有技術相對“靜態(tài)”的節(jié)電處理，要么過度保護進程導致不能很好的清理進程以節(jié)省cpu及內(nèi)存資源，要么過度處理嚴重影 響用戶的使用體驗，甚至造成一些應用或系統(tǒng)的功能性問題。

目前現(xiàn)有技術中存在的技術方案一般的是先在程序中預置一套受保護名單，這些名單一般包括應用市場上比較流行的軟件，節(jié)電處理后可能影響系統(tǒng)穩(wěn)定或用戶使用的程序功能的正常運行，或者一些手機廠商預置的比較重要的系統(tǒng)級或相對重要的程序。然后將所有正在運行的應用程序按占用內(nèi)存折大小從大到小排序列出來。用戶可以手動修改應用列表的節(jié)電策略，臨時決定哪些應用適用哪些節(jié)電策略；或者可以修改受保護名單，列入受保護名單后，不管是前臺手動處理還是后臺一鍵處理，都不會影響這些受保護名單的應用。

這樣導致的問題就是，如果用戶不會或者不想設置名單，很有可能某些正在使用的應用會被處理，如正在聽書的軟件，正在緩存視頻電影的軟件，或者正在導航的地圖類軟件，這些軟件的特征是使用時不能被清理，清理時會極大的影響用戶使用，但是這些軟件不使用時需要被節(jié)電處理，因為會在后臺運行占用cpu、內(nèi)存甚至消耗流量，而且，即使用戶會設置受保護名單，這些場景是動態(tài)的，用戶如果頻繁的修改受保護狀態(tài)，也會不甚其煩，此外，即使在用戶手動處理應用進程，面對一個進程列表，大多數(shù)用戶不知道哪些進程真正需要運行，哪些進程實際上不需要在后臺運行，可以被處理，以節(jié)省內(nèi)存和處理器資源，這會給用戶帶來極大的不便，用戶體驗度很差。

針對相關技術中，用戶無法正確的結束應用程序的進程，進而導致用戶體驗度差，即終端的節(jié)電技術不夠智能的問題，尚未提出有效的解決方案。

技術實現(xiàn)要素：

本發(fā)明實施例提供了一種節(jié)電處理方法及裝置，以至少解決相關技術中終端的節(jié)電技術無法動態(tài)調(diào)整，不夠智能的問題。

根據(jù)本發(fā)明的一個方面，提供了一種節(jié)電處理方法，包括：

獲取終端中當前正在運行的所有應用程序的標識，其中，該標識用于唯一標記應用程序；根據(jù)所述標記在預先設置的知識庫中查找該 標識對應的節(jié)電策略，其中，所述知識庫中保存有應用程序的標識與節(jié)電策略的對應關系；根據(jù)所述節(jié)點策略對所述應用程序進行節(jié)電處理。

可選地，至少通過以下方式之一確定所述節(jié)電策略：對所述應用程序設置單獨的節(jié)電策略；和/或根據(jù)預設條件對所有應用程序進行分組；針對分組后的每一組，設置與每一組對應的節(jié)電策略。

可選地，所述預設條件包括以下至少之一：應用程序的功能、執(zhí)行應用程序所依賴的硬件元素。

可選地，所述方法還包括：在所述應用程序沒有設置節(jié)電策略時，判斷所述應用程序所在的分組；

根據(jù)所述分組對應的節(jié)電策略對所述應用程序進行節(jié)電處理。

可選地，所述方法還包括：至少采用以下方式之一對所述節(jié)電策略進行更新：接收用戶修改的應用程序所對應的節(jié)電策略、所述終端對應的云端更新的節(jié)電策略。

可選地，所述節(jié)電策略至少包括以下之一：后臺清理進程、限制應用后臺自啟動、禁止應用之間相互喚醒、允許應用進行深度睡眠、允許應用對齊喚醒。

根據(jù)本發(fā)明的另一個方面，還提供了一種節(jié)電處理裝置，包括：獲取模塊，用于獲取終端中當前正在運行的所有應用程序的標識，其中，該標識用于唯一標記應用程序；查找模塊，用于根據(jù)所述標記在預先設置的知識庫中查找該標識對應的節(jié)電策略，其中，所述知識庫中保存有應用程序的標識與節(jié)電策略的對應關系；節(jié)電處理模塊，用于根據(jù)所述節(jié)點策略對所述應用程序進行節(jié)電處理。

可選地，所述裝置還包括：確定模塊，用于至少通過以下方式之一確定所述節(jié)電策略：對所述應用程序設置單獨的節(jié)電策略；和/或根據(jù)預設條件對所有應用程序進行分組；針對分組后的每一組，設置與每一組對應的節(jié)電策略。

可選地，所述確定模塊中的預設條件包括以下至少之一：應用程 序的功能、執(zhí)行應用程序所依賴的硬件元素。

可選地，所述裝置還包括：判斷模塊，用于在所述應用程序沒有設置節(jié)電策略時，判斷所述應用程序所在的分組；所述節(jié)電處理模塊，還用于根據(jù)所述分組對應的節(jié)電策略對所述應用程序進行節(jié)電處理。

通過本發(fā)明，獲取終端中當前正在運行的所有應用程序的標識，根據(jù)所述標記在預先設置的知識庫中查找該標識對應的節(jié)電策略的技術方案，解決了相關技術中，用戶無法正確的結束應用程序的進程，進而導致用戶體驗度差，即終端的節(jié)電技術不夠智能的問題，進而不影響用戶使用終端，提升了用戶體驗度，減少了終端功耗。

附圖說明

此處所說明的附圖用來提供對本發(fā)明的進一步理解，構成本申請的一部分，本發(fā)明的示意性實施例及其說明用于解釋本發(fā)明，并不構成對本發(fā)明的不當限定。在附圖中：

圖1是根據(jù)本發(fā)明實施例的節(jié)電處理方法的流程圖；

圖2是根據(jù)本發(fā)明實施例的節(jié)電處理裝置的結構框圖；

圖3是根據(jù)本發(fā)明實施例的節(jié)電處理裝置的另一結構框圖；

圖4為根據(jù)本發(fā)明優(yōu)選實施例的模塊劃分及裝置結構框圖；

圖5為根據(jù)本發(fā)明優(yōu)選實施例的節(jié)電策略構建流程圖；

圖6為根據(jù)本發(fā)明優(yōu)選實施例的應用分組策略示意圖(一)；

圖7為根據(jù)本發(fā)明優(yōu)選實施例的應用分組策略示意圖(二)；

圖8為根據(jù)本發(fā)明優(yōu)選實施例的節(jié)點處理的流程圖；

圖9為根據(jù)本發(fā)明優(yōu)選實施例的節(jié)點策略進行更新的流程圖。

具體實施方式

下文中將參考附圖并結合實施例來詳細說明本發(fā)明。需要說明的是，在不沖突的情況下，本申請中的實施例及實施例中的特征可以相 互組合。

需要說明的是，本發(fā)明的說明書和權利要求書及上述附圖中的術語“第一”、“第二”等是用于區(qū)別類似的對象，而不必用于描述特定的順序或先后次序。

在本實施例中提供了一種節(jié)電處理方法，圖1是根據(jù)本發(fā)明實施例的節(jié)電處理方法的流程圖，如圖1所示，該流程包括如下步驟：

步驟s102，獲取終端中當前正在運行的所有應用程序的標識，其中，該標識用于唯一標記應用程序；

步驟s104，根據(jù)標記在預先設置的知識庫中查找該標識對應的節(jié)電策略，其中，知識庫中保存有應用程序的標識與節(jié)電策略的對應關系；

步驟s106，根據(jù)節(jié)點策略對應用程序進行節(jié)電處理。

通過上述各個步驟，獲取終端中當前正在運行的所有應用程序的標識，根據(jù)標記在預先設置的知識庫中查找該標識對應的節(jié)電策略的技術方案，解決了相關技術中，用戶無法正確的結束應用程序的進程，進而導致用戶體驗度差，即終端的節(jié)電技術不夠智能的問題，進而不影響用戶使用終端，提升了用戶體驗度，減少了終端功耗。

在實際應用過程中，至少通過以下方式之一確定節(jié)電策略：對應用程序設置單獨的節(jié)電策略；和/或根據(jù)預設條件對所有應用程序進行分組；針對分組后的每一組，設置與每一組對應的節(jié)電策略，即在本發(fā)明實施例中，可以是對應用程序單獨設置節(jié)電策略，也可以先根據(jù)應用程序的功能、執(zhí)行應用程序所依賴的硬件元素對應用程序先進行分組，對于同一組的應用程序分配一個相同的節(jié)電策略，如果應用程序沒有被設置節(jié)電策略，則判斷這個應用程序所在的分組，根據(jù)這個組的節(jié)電策略對應用程序進行處理，在本發(fā)明的一個可選實施例中，對于應用程序的功能相同的或者應用程序所依賴的硬件元素相同的應用程序分配到一個組中。

在一個可選示例中，上述方法還包括：至少采用以下方式之一對 節(jié)電策略進行更新：接收用戶修改的應用程序所對應的節(jié)電策略、終端對應的云端更新的節(jié)電策略。

本發(fā)明實施例中的節(jié)電策略至少包括以下之一：后臺清理進程、限制應用后臺自啟動、禁止應用之間相互喚醒、允許應用進行深度睡眠、允許應用對齊喚醒，其中，后臺清理進程指的是在手機黑屏后對終端后臺運行的進行清理；限制應用后臺自啟動指的是限制指定應用在后臺沒有經(jīng)過用戶允許自啟動；禁止應用之間相互喚醒指的是禁止應用之間，在一個應用被喚醒時，另一個應用自動被喚醒的情況或者一個應用在任何情況下未經(jīng)用戶允許后臺喚醒另一個應用；允許應用進行深度睡眠指的是允許應用不輕易被用戶的操作喚醒，允許應用對齊喚醒指的是兩個或多個應用同時被喚醒。

即本發(fā)明實施例的技術方案依賴一個用戶可以設置或可以通過網(wǎng)絡更新的策略庫，每個應用定義有自己默認的節(jié)電策略，并且同類應用有相同的節(jié)電策略。

通過以上的實施方式的描述，本領域的技術人員可以清楚地了解到根據(jù)上述實施例的方法可借助軟件加必需的通用硬件平臺的方式來實現(xiàn)，當然也可以通過硬件，但很多情況下前者是更佳的實施方式。基于這樣的理解，本發(fā)明的技術方案本質(zhì)上或者說對現(xiàn)有技術做出貢獻的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來，該計算機軟件產(chǎn)品存儲在一個存儲介質(zhì)(如rom/ram、磁碟、光盤)中，包括若干指令用以使得一臺終端設備(可以是手機，計算機，服務器，或者網(wǎng)絡設備等)執(zhí)行本發(fā)明各個實施例的方法。

實施例2

在本實施例中還提供了一種節(jié)電處理裝置，該裝置用于實現(xiàn)上述實施例及優(yōu)選實施方式，已經(jīng)進行過說明的不再贅述。如以下所使用的，術語“模塊”可以實現(xiàn)預定功能的軟件和/或硬件的組合。盡管以下實施例所描述的裝置較佳地以軟件來實現(xiàn)，但是硬件，或者軟件和硬件的組合的實現(xiàn)也是可能并被構想的。

圖2是根據(jù)本發(fā)明實施例的節(jié)電處理裝置的結構框圖，如圖2所示，該裝置包括：

獲取模塊20，用于獲取終端中當前正在運行的所有應用程序的標識，其中，該標識用于唯一標記應用程序；

查找模塊22，用于根據(jù)標記在預先設置的知識庫中查找該標識對應的節(jié)電策略，其中，知識庫中保存有應用程序的標識與節(jié)電策略的對應關系；

節(jié)電處理模塊24，用于根據(jù)節(jié)點策略對應用程序進行節(jié)電處理。

通過上述各個模塊的綜合作用，獲取終端中當前正在運行的所有應用程序的標識，根據(jù)標記在預先設置的知識庫中查找該標識對應的節(jié)電策略的技術方案，解決了相關技術中，用戶無法正確的結束應用程序的進程，進而導致用戶體驗度差，即終端的節(jié)電技術不夠智能的問題，進而不影響用戶使用終端，提供了用戶體驗度，減少了終端功耗。

圖3是根據(jù)本發(fā)明實施例的節(jié)電處理裝置的另一結構框圖，如圖3所示，上述裝置還包括：

確定模塊26，用于至少通過以下方式之一確定節(jié)電策略：對應用程序設置單獨的節(jié)電策略；和/或根據(jù)預設條件對所有應用程序進行分組；針對分組后的每一組，設置與每一組對應的節(jié)電策略。

可選地，確定模塊中的預設條件包括以下至少之一：應用程序的功能、執(zhí)行應用程序所依賴的硬件元素。

如圖3所示，上述裝置還包括：判斷模塊28，用于在應用程序沒有設置節(jié)電策略時，判斷應用程序所在的分組；節(jié)電處理模塊24，還用于根據(jù)分組對應的節(jié)電策略對應用程序進行節(jié)電處理。

需要說明的是，上述各個模塊是可以通過軟件或硬件來實現(xiàn)的，對于后者，可以通過以下方式實現(xiàn)，但不限于此：上述模塊均位于同一處理器中；或者，上述各個模塊以任意組合的形式分別位于不同的處理器中。

以下結合優(yōu)選實施例對上述實施例的技術方案進行詳細說明，但不用于限定本發(fā)明實施例。

本發(fā)明優(yōu)選實施例提出了一種根據(jù)應用程序的主要功能、軟件分類、所依賴的硬件條件等建立一套知識庫，知識庫包括應用的各類節(jié)電策略和各類分組應用的節(jié)電策略。并根據(jù)這個節(jié)電知識庫對手機正在運行的應用程序進行針對性的進行各種節(jié)電策略處理。有效解決過分依賴用戶設置，更加智能的降功耗，提升用戶體驗。

圖4為根據(jù)本發(fā)明優(yōu)選實施例的模塊劃分及裝置結構框圖，如圖4所示，包括：節(jié)電策略實施模塊40(相當于上述實施例的節(jié)電處理模塊24)、節(jié)電知識庫模塊42(相當于上述實施例的查詢模塊22)、節(jié)電策略云端更新模塊44和節(jié)電策略修改模塊46幾部分組成。其中節(jié)電策略實施模塊40主要用于根據(jù)節(jié)電知識庫模塊制定的節(jié)電策略并予以實施；節(jié)電知識庫模塊44包括應用的節(jié)電策略和應用分組節(jié)電策略，如果應用策略無效則采取該應用所在分組的策略；節(jié)電策略云端更新模塊44主要負責通過云端應用策略更新和應用分組節(jié)電策略更新；節(jié)電策略修改模塊46主要是用戶根據(jù)自己的需要針對具體應用來修改節(jié)電策略。通過知識庫的節(jié)電策略方式大大提升用戶體驗，兼顧進程誤清理和降低手機功耗。

在本發(fā)明實施例中，該知識庫的節(jié)電策略的使用不僅可以用作后臺節(jié)電處理，而且可以用作用戶手動節(jié)電處理時參考。

本發(fā)明優(yōu)選實施例還描述了一種手機應用節(jié)電知識庫的構建方法。清理及安全軟件會預置這個應用節(jié)電知識庫，后面可以根據(jù)需要通過云端更新或用戶根據(jù)自己的需求修改。圖5為根據(jù)本發(fā)明優(yōu)選實施例的節(jié)電策略構建流程圖，具體包括如下步驟：

步驟s502：根據(jù)應用的功能或應用所依賴硬件元素定義應用分組；如圖6聊天通訊類是根據(jù)其功能提出的分類，音樂電臺類根據(jù)其所依賴的元素定義的分類，音樂聽書類應用都必須依賴手機的音頻硬件播放聲音。

步驟s504：根據(jù)應用分組庫針對不同的節(jié)電手段制定該分組的節(jié)電策略，不同的功能的應用的節(jié)電策略肯定是不一樣的，所以可以據(jù)此定義不同的節(jié)電策略。如聊天通訊類對消息的實時性要求比較高，所以不允許后臺殺進程，也不能對齊喚醒和深度睡眠，在這類應用退出時還需要能允許應用自啟動，否則可能影響這類應用接收消息的實時性，而音樂電臺類則可以后臺清理進程(在不播放音頻時)，可以限制其自啟動，可以允許深度睡眠等等；

步驟s506：根據(jù)手機的功耗情況制定其它分組默認策略，如圖6；

因為知識庫的容量畢竟有限，不可能容納所有的應用軟件，所以針對每一個節(jié)電策略有一個默認的策略，如果該手機整體硬件配置較低，則默認節(jié)電策略定義嚴一點，否則節(jié)電策略可以定義的稍寬松點，那么針對那些在我們的知識庫找不到的應用，可以參考這個其它分組的默認策略；

步驟s508：通過步驟s504,s506，形成應用分組節(jié)電策略，就是不針對具體應用，只針對應用的不同類別形成的節(jié)電策略庫。

步驟s510：收集應用市場常見應用，或不同手機廠商預置在手機中的應用，安卓手機一般是收集應用的唯一標識應用包名，通過包名就可以對該應用進行進程清理、禁止后臺自啟動，深度睡眠，對齊喚醒，禁止應用間相互喚醒等節(jié)電策略。

步驟s512：根據(jù)其在系統(tǒng)運行中是否起核心作用確定其是否關鍵應用，如名片夾，短信等系統(tǒng)核心應用如果被進行節(jié)電策略，則可能影響其手機的正常功能，另一方面，這些核心應用一般是系統(tǒng)預置應用，要對齊進行限制需要更高的權限，所以將其劃入關鍵應用；

步驟s514：制定關鍵應用節(jié)電策略，列為關鍵應用的應用如果功耗較高，需要特殊的處理辦法降低其對功耗的影響；

步驟s516：根據(jù)其功能和硬件依賴確定其應用分組，定義應用分組有二個好處，一是如果其在沒有定義節(jié)電策略，可以參考所在分組的節(jié)電策略，第二可以根據(jù)其分組信息作其它智能節(jié)電處理。

步驟s518：如果該應用節(jié)電策略與該應用所在分組的節(jié)電策略有所沖突或差異，則轉入步驟s524，否則轉入步驟s526；

步驟s520：取默認無效值，依賴其分組節(jié)電策略；

步驟s522：針對該應用作差異化節(jié)電策略，如圖7；

步驟s524：成功構建節(jié)電應用知識庫。

一般情況下，進程清理分為前臺節(jié)電處理，方便用戶根據(jù)需要有選擇性的應用處理。更多的時候，需要后臺自動節(jié)電處理，比如在手機黑屏的時候，啟動自動應用功耗處理；在應用后臺自啟及應用后臺喚醒自動進行限制。

以下對知識庫的具體使用實施節(jié)電管理是基于上述實施例的基礎上做針對性的細化。

知識庫的具體應用實施例

前臺自動節(jié)電實時性要求較高，適合檢測那些較快速的鑒定功能，然后針對應用進程給出描述性的提示和缺省的清理狀態(tài)。用戶可以根據(jù)這些提示和缺省節(jié)電策略狀態(tài)進行節(jié)電處理，圖8為根據(jù)本發(fā)明優(yōu)選實施例的節(jié)點處理的流程圖，包括以下步驟：

步驟s802：獲取并遍歷正在運行的所有程序，正在運行的程序就是目前占用系統(tǒng)內(nèi)存和處理器資源的影響手機功耗的因素；

步驟s804：得到運行程序的包名，針對不同的手機平臺可能這個有所不同，抽象點說是得到運行應用程序的唯一標識，通過這個唯一標識可以對該應用進行后臺進程清理，限制自啟動，強制對齊喚醒，強制深度睡眠和禁止相互喚醒等等節(jié)電策略；

步驟s806：在知識庫中通過應用在手機平臺的唯一標識如應用包名去查找該應用節(jié)電策略中查找某項節(jié)電策略；

步驟s808：判斷該應用包名在應用節(jié)電策略知識庫中是否能找到？能找到轉入步驟s810，否則轉入步驟s814；

步驟s810：同樣通過該應用包名在知識庫中判斷該應用是否關 鍵應用，知識庫中有一個關鍵應用的字段，關鍵應用的節(jié)電策略處理和普通應用不一樣，關鍵應用如果在某些方面被限制是影響手機系統(tǒng)核心功能和穩(wěn)定性的；如果被判斷是關鍵應用轉入步驟s812進一步處理；否則轉入步驟s818處理；

步驟s812：按關鍵應用策略進行處理，因為關鍵應用如果在某些方面被限制是影響手機系統(tǒng)核心功能和穩(wěn)定性的，所以只能在前臺用戶手動對其進行限制，這樣做的好處是用戶知道限制后可能影響手機相關的功能；

步驟s814：是否系統(tǒng)預置應用進程，如果是轉入步驟s816進一步處理，如果否轉入步驟s822進一步處理；

步驟s816：對在知識庫中找不到的系統(tǒng)應用認為是核心級的應用，一是可能沒有權限對其進行處理，二是處理后可能極大的破壞系統(tǒng)功能和穩(wěn)定性，所以對這類應用不進行任何節(jié)電策略處理；

步驟s818：通常如果某個應用的節(jié)電策略與其所在分組節(jié)電策略一致則不定義其應用節(jié)電策略(默認無效值)。所以如果通過應用的唯一標識包名在應用節(jié)電知識庫中找到的應用節(jié)電策略，判斷其是否有效，如果有效則轉入步驟s820處理，如果無效則轉入步驟s824進一步處理；

步驟s820：如果找到了應用分組策略且該應用節(jié)電策略有效，則按應用分組策略來進行節(jié)電處理，通過節(jié)電策略包括但不限于后臺自動清理進程，限制應用后臺自啟動，不允許應用之間相互喚醒，允許應用深度睡眠，允許應用對齊喚醒等，所以該節(jié)電策略的判斷是針對不同的節(jié)電策略進行知識庫的不同字段的判斷；

步驟s822：知識庫的容量畢竟有限，我們設計時考慮到這種情況，所以存在很多在知識庫中找不到的應用程序，如果找不到，我們則缺省指定其分組策略為“其它”，轉入步驟s830進行處理；

步驟s824：如果該應用策略無效，則取該應用的分組類型，通過其分組類型轉入步驟s826進一步處理；

步驟s826：判斷該應用的分組類型是否為其它，如果是則轉入步驟s830進一步處理，如果否則轉入步驟s828進一步處理；

步驟s828：按該應用的分組策略來進行節(jié)電處理；

步驟s830：按其它分組默認策略來進行節(jié)電處理；

步驟s832：流程結束。

在本發(fā)明實施例中，還提供了一種對節(jié)點策略進行更新的流程，圖9為根據(jù)本發(fā)明優(yōu)選實施例的節(jié)點策略進行更新的流程圖，如圖9所示，主要包括以下步驟：

步驟s902：用戶安裝新應用；

步驟s904：用戶修改/云端更新節(jié)電策略；

步驟s906：更新節(jié)電知識庫；

步驟s908：知識庫發(fā)出更新通知；

步驟s910：節(jié)電相關應用收到通知；

步驟s912：按新的節(jié)電策略對該應用進行節(jié)電處理。

這樣做的好處是不同的節(jié)電策略實施模塊可以共用這個節(jié)電知識庫，而且一個節(jié)電策略實施模塊修改了相關的節(jié)電配置，其它模塊都可以及時響應，起到聯(lián)動作用。

本發(fā)明優(yōu)選實施例在手機實施節(jié)電策略的過程中，不管是前臺還是后臺，都可以較為智能的進行節(jié)電策略，既避免了用戶不會設置各類名單的痛苦，又避免了用戶頻繁修改名單的麻煩。

進一步地，通過本發(fā)明實施例的技術方案，可以有效的避免“誤殺”進程，規(guī)避了現(xiàn)有方案的過分依賴靜態(tài)“名單”的弊端。

本發(fā)明的實施例還提供了一種存儲介質(zhì)。可選地，在本實施例中，上述存儲介質(zhì)可以被設置為存儲用于執(zhí)行以下步驟的程序代碼：

s1，獲取終端中當前正在運行的所有應用程序的標識，其中，該標識用于唯一標記應用程序；

s2，根據(jù)標記在預先設置的知識庫中查找該標識對應的節(jié)電策略，其中，知識庫中保存有應用程序的標識與節(jié)電策略的對應關系；

s3，根據(jù)節(jié)點策略對應用程序進行節(jié)電處理。

可選地，在本實施例中，上述存儲介質(zhì)可以包括但不限于：u盤、只讀存儲器(rom，read-onlymemory)、隨機存取存儲器(ram，randomaccessmemory)、移動硬盤、磁碟或者光盤等各種可以存儲程序代碼的介質(zhì)。

可選地，本實施例中的具體示例可以參考上述實施例及可選實施方式中所描述的示例，本實施例在此不再贅述。

顯然，本領域的技術人員應該明白，上述的本發(fā)明的各模塊或各步驟可以用通用的計算裝置來實現(xiàn)，它們可以集中在單個的計算裝置上，或者分布在多個計算裝置所組成的網(wǎng)絡上，可選地，它們可以用計算裝置可執(zhí)行的程序代碼來實現(xiàn)，從而，可以將它們存儲在存儲裝置中由計算裝置來執(zhí)行，并且在某些情況下，可以以不同于此處的順序執(zhí)行所示出或描述的步驟，或者將它們分別制作成各個集成電路模塊，或者將它們中的多個模塊或步驟制作成單個集成電路模塊來實現(xiàn)。這樣，本發(fā)明不限制于任何特定的硬件和軟件結合。

以上所述僅為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明，對于本領域的技術人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進等，均應包含在本發(fā)明的保護范圍之內(nèi)。