一種內存回收方法及裝置與流程

2023-05-29 03:07:16 5

本發明涉及信息技術領域，尤其涉及一種內存回收方法及裝置。

背景技術：

隨著終端(如智慧型手機、平板電腦等終端)的發展，終端已成為人們日常生活必不可缺的物品。實踐中發現，用戶在剛開始購買終端的時候，用戶使用終端非常順滑，應用運行起來非常快，而在終端被長期使用後，由於安裝的應用越來越多，會有許多無用進程和服務在後臺運行，並且用戶瀏覽網頁以及使用應用程式(application，app)會產生過多的緩存，這些將會使得系統的可用內存變少，進而導致終端出現卡頓現象。

通常採取的做法是在系統分配內存時檢查系統是否有充足的可用內存，若發現當前系統的可用內存不能支撐當前的內存分配需求，則會啟動系統內存清理操作，比如：回收系統緩存、關閉進程等。然而，這樣會導致需要內存資源的應用阻塞，處於等待狀態，延長了app的響應時間，進而增大了終端出現卡頓現象的概率。

技術實現要素：

本發明實施例提供了一種內存回收方法及裝置，可以減少終端出現卡頓現象的概率。

本發明實施例第一方面公開了一種內存回收方法，包括：

在確定系統當前的可用內存小於內存閾值時，從後臺進程列表中確定待回收內存的進程，其中，所述後臺進程列表包括一個或多個應用的進程，所述待回收內存的進程為所述一個或多個應用的進程中滿足進程所佔用內存與內存壓力值的差值的絕對值小於預設閾值的條件的進程，所述內存壓力值為所述內存閾值與所述系統當前的可用內存的差值；向系統內核發送處理指令，以觸發所述系統內核對所述待回收內存的進程進行處理以回收所述待回收內存的進程所佔用的內存。

其中，可以由一個或多個內存管控線程、一個或多個內存管控進程、應用中的任一個來執行上述方法的步驟。

其中，後臺進程列表是一個根據應用的重要程度以及進程優先級進行排序的動態二維表，包括一個或多個應用的進程，即後臺進程列表可以包括一個或多個應用，同時，一個應用可以包括一個或多個進程。該後臺進程列表在2種情況下創建，第一種：在確定系統當前的可用內存小於內存閾值時創建後臺進程列表，這種情況一般是針對需要立即進行內存回收的場景，第二種：在確定系統當前的可用內存小於內存閾值並且系統處於空閒狀態時創建後臺進程列表，這種情況一般是用戶和終端進行交互，為了不影響用戶體驗，需要在系統空閒的時候進行內存回收。

具體的，本發明實施例中，在確定系統當前的可用內存小於內存閾值時，可以制定內存回收策略，根據該內存回收策略，從後臺進程列表中確定待回收內存的進程，進一步地，向系統內核發送處理指令，以觸發系統內核對待回收內存的進程進行處理以回收待回收內存的進程對應的內存，直到緩解系統當前的內存壓力。

此外，由於應用之間存在各種關聯關係，在對後臺進程所佔用的內存進行回收時，為了防止被清理的進程被其關聯的進程拉起來，所以，在回收內存時是以應用為單位，回收該應用包括的進程所佔用的內存。其中，進程所佔用的內存是指該進程獨立佔用的那部分內存，而不包括該進程與其他進程共享的那部分內存。

可見，這種方式中，在確定系統當前的可用內存小於內存閾值時，可以主動進行內存回收，當應用程式真正需要大量內存的時候，系統內核已經回收回來大量可用的內存，從而可以減少終端出現卡頓現象的概率。

在一個可能的實施方式中，在檢測到第一關鍵事件時觸發所述確定系統當前的可用內存小於內存閾值的操作，且所述內存閾值為與所述第一關鍵事件對應的第一內存閾值。其中，該內存閾值可以是靜態預置的，也可以是動態配置的。不同的第一關鍵事件對應的場景是不同的，相應的第一內存閾值也不同。

在一個可能的實施方式中，所述第一關鍵事件包括如下事件中的任意一種：程序啟動開始事件、清理事件以及內存不足oom事件。其中，當發生第一關鍵事件時需要立即進行內存回收。

在一個可能的實施方式中，在檢測到第二關鍵事件且確定系統處於空閒狀態時觸發所述確定當前系統的可用內存小於內存閾值的操作，且所述內存閾值為與所述第二關鍵事件對應的第二內存閾值。其中，該內存閾值可以是靜態預置的，也可以是動態配置的。不同的第二關鍵事件對應的場景是不同的，相應的第二內存閾值也不同。

其中，在該實施方式中，步驟的先後順序是：在檢測到第二關鍵事件時先判斷系統是否處於空閒狀態，在確定系統處於空閒狀態時再去讀取當前系統的可用內存，在確定當前系統的可用內存小於內存閾值時，從後臺進程列表中確定待回收內存的進程，進一步地，向系統內核發送處理指令，以觸發系統內核對待回收內存的進程進行處理以回收待回收內存的進程對應的內存。

在一個可能的實施方式中，在檢測到第二關鍵事件時觸發所述確定當前系統的可用內存小於內存閾值的操作，在確定系統處於空閒狀態時觸發所述從後臺進程列表中選擇待回收內存的進程的操作，且所述內存閾值為與所述第二關鍵事件對應的第二內存閾值。

其中，在該實施方式中，步驟的先後順序是：在檢測到第二關鍵事件時，先讀取當前系統的可用內存，在確定當前系統的可用內存小於內存閾值的情況下，再判斷系統是否處於空閒狀態，在確定系統處於空閒狀態時從後臺進程列表中選擇待回收內存的進程，進一步地，向系統內核發送處理指令，以觸發系統內核對待回收內存的進程進行處理以回收待回收內存的進程對應的內存。

在一個可能的實施方式中，所述第二關鍵事件包括如下事件中的任意一種：程序啟動完成事件、亮屏事件、滅屏事件、觸屏事件、界面切換事件、任務切換完成事件以及廣播事件。

在一個可能的實施方式中，所述確定系統處於空閒狀態包括：

判斷所述系統當前的負載是否小於負載閾值；在所述系統當前的負載小於所述負載閾值的情況下，確定系統處於空閒狀態。

其中，系統處於空閒狀態有2種場景，第一種是在用戶未使用終端的情況下，比如終端處於待機狀態可以看作是系統處於空閒狀態，又比如：在應用啟動完成出現顯示畫面，但以後並沒有和終端進行交互，這個時候系統沒有大量的io操作，可以看作是系統處於空閒狀態，第二種是在用戶使用終端但系統當前的負載不影響用戶體驗的情況下，可以看作是系統處於空閒狀態，比如系統的負載小於負載閾值。

在一個可能的實施方式中，在確定出的所述待回收的進程為多個的情況下，所述向系統內核發送處理指令包括：

調用多個線程向系統內核發送多個處理指令，其中，每個所述線程用於發送一個或多個處理指令。

其中，確定出的待回收的進程可以為一個也可以為多個，在一個進程需要發送多個處理指令的情況下，該進程可以一個一個連續地發送處理指令，而不需要在發送完一個處理指令後去檢測系統內核回收進程對應的內存的狀態，然後再去發送另一個處理指令。

在該可選的實施方式中，在確定出的所述待回收的進程為多個的情況下，可以調用多個線程向系統內核發送多個處理指令。具體的，一個線程發送多個處理指令是指該線程一個一個連續地發送處理指令，而不需要在發送完一個處理指令後去檢測系統內核回收進程對應的內存的狀態，然後再去發送另一個處理指令。其中，每個處理指令攜帶一個待回收的進程的標識。

可見，這種方式可以提高線程向系統內核發送處理指令的效率，同時，也可以加速系統內核回收內存性能。

在一個可能的實施方式中，所述從後臺進程列表中確定待回收內存的進程包括：

根據應用的重要程度從低到高的順序，從所述後臺進程列表包括的多個應用中確定至少一個應用；根據進程優先級從低到高的順序，從所述至少一個應用包括的進程中確定待回收內存的進程。

在一個可能的實施方式中，所述方法還包括：

在確定所述系統當前的可用內存小於所述內存閾值時創建所述後臺進程列表。其中，這種情況是針對需要立即進行內存回收的場景而言的。

在一個可能的實施方式中，所述方法還包括：

在確定所述系統當前的可用內存小於所述內存閾值並且所述系統處於空閒狀態時創建所述後臺進程列表。其中，這種情況是針對用戶和終端進行交互，為了不影響用戶體驗，需要在系統空閒的時候進行內存回收的場景而言的。

在一個可能的實施方式中，所述創建所述後臺進程列表包括：

確定當前在後臺運行的每個應用的關鍵因素的分值，所述關鍵因素包括以下中的一個或多個：進程優先級、用戶使用習慣、進程佔用系統資源以及應用的關聯關係；針對每個所述應用，將所有所述關鍵因素的分值進行加權計算，獲得所述應用的重要程度；根據所有所述應用的重要程度，對所有所述應用進行排序；根據進程優先級，對排序後的每個所述應用包括的進程進行排序，以生成後臺進程列表。

其中，系統資源可以包括但不限於計算資源，存儲資源，cpu資源以及io資源。基於應用的關鍵因素(進程優先級、用戶使用習慣、進程佔用系統資源以及應用的關聯關係)來創建後臺進程列表，後續就可以根據內存的需求從該後臺進程列表中確定需要處理的進程，這樣就可以精確地選擇可殺進程隊列，減少錯殺/多殺/少殺進程的概率。

本發明實施例第二方面公開了一種內存回收裝置，包括用於執行本發明實施例第一方面任一方法的部分或全部步驟的功能單元。其中，該終端執行第一方面任一方法的部分或全部步驟時可以減少終端出現卡頓現象的概率。

本發明實施例第三方面公開了一種終端，包括處理器以及存儲器，所述存儲器被配置用於存儲指令，所述處理器被配置用於運行所述指令，所述處理器運行所述指令以執行本發明實施例第一方面任一方法的部分或全部步驟。其中，該終端執行第一方面任一方法的部分或全部步驟時可以減少終端出現卡頓現象的概率。

本發明實施例第四方面公開了一種計算機存儲介質，所述計算機存儲介質存儲有程序，所述程序具體包括用於執行本發明實施例第一方面任一方法的部分或全部步驟的指令。

附圖說明

為了更清楚地說明本發明實施例中的技術方案，下面將對實施例描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發明的一些實施例，對於本領域普通技術人員來講，在不付出創造性勞動的前提下，還可以根據這些附圖獲得其他的附圖。

圖1是本發明實施例公開的一種作業系統的結構示意圖；

圖2是本發明實施例公開的一種內存回收方法的流程示意圖；

圖2a是本發明實施例公開的一種app重要程度識別的示意圖；

圖2b是本發明實施例公開的一種應用的關聯關係的示意圖；

圖2c是本發明實施例公開的一種相機啟動時序圖；

圖2d是本發明實施例公開的另一種相機啟動時序圖；

圖3是本發明實施例公開的另一種內存回收方法的流程示意圖；

圖4是本發明實施例公開的另一種內存回收方法的流程示意圖；

圖5是本發明實施例公開的一種內存回收裝置的結構示意圖；

圖6是本發明實施例公開的一種終端的結構示意圖。

具體實施方式

下面將結合本發明實施例中的附圖，對本發明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發明一部分實施例，而不是全部的實施例。基於本發明中的實施例，本領域普通技術人員在沒有做出創造性勞動前提下所獲得的所有其他實施例，都屬於本發明保護的範圍。

本發明的說明書和權利要求書及上述附圖中的術語「包括」和「具有」以及它們任何變形，意圖在於覆蓋不排他的包含。例如包含了一系列步驟或單元的過程、方法、系統、產品或設備沒有限定於已列出的步驟或單元，而是可選地還包括沒有列出的步驟或單元，或可選地還包括對於這些過程、方法、產品或設備固有的其它步驟或單元。

本發明實施例公開了一種內存回收方法及裝置，可以減少終端出現卡頓現象的概率。以下分別進行詳細說明。

本發明實施例提供的內存回收方法主要應用於終端，該終端也可稱之為用戶設備(userequipment，簡稱為「ue」)、移動臺(mobilestation，簡稱為「ms」)、移動終端(mobileterminal)等，可選的，該終端可以具備經無線接入網(radioaccessnetwork，ran)與一個或多個核心網進行通信的能力，例如，終端可以是行動電話(或稱為「蜂窩」電話)、或具有移動性質的計算機等，例如，終端還可以是可攜式、袖珍式、手持式、計算機內置的或者車載的移動裝置。該終端的作業系統可包括但不限於android(安卓)作業系統、ios作業系統、symbian(塞班)作業系統、blackberry(黑莓)作業系統、windowsphone8作業系統等等。

本發明實施例提供的內存回收方法主要應用於具有android作業系統的終端。

為了更好的理解本發明實施例，下面先對本發明實施例公開的一種作業系統的結構示意圖進行描述。

請參閱圖1，圖1是本發明實施例公開的一種作業系統的結構示意圖。具體的，該作業系統可以是android作業系統。android作業系統是google開發的基於linux平臺的開源作業系統，android作業系統是一個分層的環境，構建在linux內核的基礎上，它包括豐富的功能。

如圖1所示，該作業系統100包括應用層110、框架層120、核心庫層130以及內核層140。

其中，應用層110包括終端工作時所需的所有應用程式，比如電子郵件客戶端、簡訊、日曆、地圖、瀏覽器等應用程式，這些應用程式可以由java、c/c++等語言編寫。

框架層120即為android應用程式框架，android應用程式均是基於該框架進行開發的。該框架通過提供一組基礎類庫，可以使開發者開發出豐富且新穎的應用程式，基於該類庫，開發者可以自由地利用設備硬體優勢，實現訪問位置信息，運行後臺服務，設置鬧鐘，向狀態欄添加通知等功能。需要說明的是，圖1所示的框架層120保留了原有android作業系統框架層的功能模塊，此外，在系統服務121上做了一些修改，如圖1所示，本發明中，該系統服務121包括資源管理系統(resourcemanagementsystem，rms)模塊1211、應用管控模塊1212以及系統資源狀態採集模塊1213，其中，rms模塊1211主要用於對系統資源狀態採集模塊1213採集的信息進行管理，應用管控模塊1212主要用於對進程快速處理，系統資源狀態採集模塊1213主要用於採集並識別系統的資源負載狀態。此外，如圖1所示，在該框架層120中新增了感知進程122，感知進程122包括rms模塊1221、省電精靈模塊1222以及內存管控模塊1223，其中，rms模塊1221主要用於處理執行時間較長的內存管控措施以及亮滅屏識別，省電精靈模塊1222主要用於識別應用的運行狀態，並判斷應用所消耗的電量是否超過電量閾值，以進行管控處理(如關閉進程、限制應用啟動，延遲分發消息等)，內存管控模塊1223主要用於外部模塊接口管理及處理、系統空閒狀態/負載狀態識別，空閒內存閾值配置管理、內存壓力狀態識別、精細化內存回收策略制定、智能內存分配以及維測管理。

核心庫層130主要為框架層120的各個組件提供其基本實現的一組c/c++庫(應用框架的底層庫)，其中，核心庫層130包括感知守護進程131，感知守護進程131主要用於採集系統資源狀態信息。

內核層140位於android作業系統的最底層，可以看做為硬體層與系統中其他軟體組直接的抽象，主要為android作業系統提供核心的系統服務，包括安全機制、內存管理、進程管理、文件管理、網絡通訊管理以及驅動管理，此外，本發明實施例中，內核層140還可以用於單個進程級的緩存回收。

請參見圖2，圖2是本發明實施例公開的一種內存回收方法的流程示意圖。其中，該方法可以應用於圖1所示的內存管控模塊1223，具體的，內存管控模塊1223可以是一個或多個線程，或者，內存管控模塊1223可以是一個或多個進程。如圖2所示，該方法可以包括以下步驟。

201、在檢測到第一關鍵事件時，確定系統當前的可用內存小於內存閾值。

本發明實施例中，內存管控模塊1223可以檢測應用程式的關鍵事件，具體的，可以在活動管理器服務(activitymanagerservice，ams)啟動每個應用的活動(activity)的時候，通過鉤子(hook)函數獲取應用程式的關鍵信息(如進程名稱、用戶身份標識(useridentifier，uid)以及進程身份標識(processidentifier，pid)，進一步地，ams可以將獲取到的應用程式的關鍵信息發送給內存管控模塊1223，這樣，內存管控模塊1223就可以檢測到應用程式的關鍵事件。

其中，該應用程式的關鍵事件可以包括但不限於程序啟動開始事件、清理事件、內存不足(outofmenory，oom)事件，程序啟動完成事件、亮屏事件、滅屏事件、觸屏事件、界面切換事件、任務切換完成事件、廣播事件、網絡連接/掃描/狀態變化事件(如wifi、2/3/4g、藍牙、紅外、全球定位系統(globalpositioningsystem，gps)、電臺廣播、近場通信(nearfieldcommunication，nfc))、外設連接變化事件(如插拔充電器等)、通知鬧鈴類事件、電話類事件(來電、信號變化等)、媒體類事件(音視頻變化、錄音播放)、閃光燈相關類事件、程序安裝卸載類事件、電池電量類事件等。

本發明實施例中，可以預先將需要立即進行內存回收的事件定義為第一關鍵事件，該第一關鍵事件可以包括但不限於程序啟動開始事件、清理事件以及oom事件。其中，程序啟動開始事件主要指由用戶觸發的需要立即啟動的應用程式事件(如用戶點擊微信應用)，清理事件可以包括但不限於終端管家清理事件、一鍵清理事件、應用卸載事件以及應用緩存清空事件。oom事件可以包括但不限於大內存應用啟動需求內存超過內存閾值事件、系統oom事件以及應用強制停止事件。

本發明實施例中，系統的內存可以包括：被佔用內存以及可用內存，其中，被佔用內存主要指當前正在運行的進程和服務所佔用的內存以及內核運行所佔用的內存，可用內存指系統的空閒內存和緩存。

在檢測到第一關鍵事件時可以獲取系統當前的可用內存，並判斷系統當前的可用內存是否小於內存閾值，當確定系統當前的可用內存小於內存閾值時，表明當前系統存在內存壓力，需要進行內存回收。其中，該內存閾值為與第一關鍵事件對應的第一內存閾值。

可選的，該內存閾值可以是靜態預置的。具體的，有如下幾種情況：

(1)根據產品規格配置內存閾值

針對2g/3g/4g/6g隨機存取存儲器(randomaccessmemory，ram)的產品，系統的可用內存不同，相應的，內存閾值也不同。比如：針對3gram的產品，可以配置內存閾值為600mb，針對4gram的產品，可以配置內存閾值為700mb。

(2)根據應用場景配置儘可能小的內存閾值

不同的應用及其不同的場景，對於內存的耗費是不同的。因此要想配置合理的內存閾值，採用方式(1)存在一些弊端，可能會因為沒有考慮某個第三方應用而出現該應用啟動時卡頓的現象。針對此類問題，可以通過離線分析應用市場中排名靠前的第三方應用，獲取各類應用在各個場景中最大的內存佔用信息。

請參見表1，表1為第三方應用在典型場景下最大的內存佔用信息。需要說明的是，表1隻是示例性地列舉了幾個應用。

表1

具體的，可以在終端開機完成，接收到啟動完成(boot_completed)事件時，查詢所有在終端上已安裝的應用的標識(如應用名稱)，進一步地，根據應用的標識從表1中獲取需要的信息(如進程名稱、運行場景、最大內存佔用信息)，以生成本地程序內存佔用表，可以使用可擴展標記語言(extensiblemarkuplanguage，xml)文件或者txt文件來保存本地程序內存佔用表。終端可以針對不同的應用，分別從本地程序內存佔用表中查詢該應用的最大內存佔用信息，並設置內存閾值為該應用的最大佔用內存。

(3)根據系統運行進程歷史佔用內存進行配置

由於每個用戶都有自己的特點，終端被長時間使用後，終端上安裝和運行的應用並不一致，可以根據系統運行進程歷史佔用內存來配置內存閾值。具體的，可以在用戶不使用終端的時候(比如半夜)查詢每個進程運行時內存佔用的歷史狀態信息(procstats)，獲取其中最大的內存佔用信息(如應用程式名稱、最大佔用內存)，進一步地，將最大佔用內存和當前系統的內存閾值比較，若最大佔用內存大於當前系統的內存閾值，則選取該最大佔用內存作為系統新的內存閾值。

(4)通過雲端下發配置內存閾值

雲端伺服器可以根據終端的標識收集在終端上運行的所有應用在各個場景佔用的內存信息，將佔用內存大於預設值(如300mb)的應用名及該應用當時的運行場景等信息形成一張表單，定期(如每月)將該表單推送給終端；終端接收到表單後，將此表單中的應用信息和本地應用列表進行遍歷，並確定終端上安裝的應用的最大內存佔用信息，進一步地，將最大佔用內存和當前系統的內存閾值進行比較，若最大佔用內存大於當前系統的內存閾值，則選取該最大佔用內存作為系統新的內存閾值。

可選的，該內存閾值可以是動態配置的。

具體的，可以通過用戶行為分析算法，根據用戶使用習慣、應用使用歷史、使用頻率、使用時長等信息，根據預測算法，預測出接下來最有可能運行的應用，並形成應用列表；獲取應用列表中的應用需要使用的最大內存，並將最大內存和當前系統的內存閾值相比，若最大內存大於當前系統的內存閾值，則選取該最大內存作為系統新的內存閾值。

202、在確定系統當前的可用內存小於內存閾值時創建後臺進程列表。

其中，在確定系統當前存在內存壓力時需要立即創建後臺進程列表，該後臺進程列表為一個根據應用的重要程度以及進程優先級進行排序的動態二維表，包括一個或多個應用的進程，即後臺進程列表可以包括一個或多個應用，同時，一個應用可以包括一個或多個進程。該後臺進程列表為根據應用的重要程度以及進程優先級排序後的列表。

具體的，創建後臺進程列表的方式具體包括以下步驟：

11)確定當前在後臺運行的每個應用的關鍵因素的分值，所述關鍵因素包括以下中的一個或多個：進程優先級、用戶使用習慣、進程佔用系統資源以及應用的關聯關係；

12)針對每個所述應用，將所有所述關鍵因素的分值進行加權計算，獲得所述應用的重要程度；

13)根據所有所述應用的重要程度，對所有所述應用進行排序；

14)根據進程優先級，對排序後的每個所述應用包括的進程進行排序，以生成後臺進程列表。

在該實施例中，在終端後臺運行的每個應用可以包括一個或多個進程，每個應用的關鍵因素包括以下種的一個或多個：進程優先級、用戶使用習慣、進程佔用系統資源以及應用的關聯關係。每個關鍵因素都有相應的分值。基於應用的關鍵因素(進程優先級、用戶使用習慣、進程佔用系統資源以及應用的關聯關係)來創建後臺進程列表，後續就可以根據內存的需求從該後臺進程列表中確定需要處理的進程，這樣就可以精確地選擇可殺進程隊列，減少錯殺/多殺/少殺進程的概率。

其中，系統會對每個進程的重要性進行評估，進程的重要性也代表了進程優先級。通常，將重要性以oom_adj(outofmemoryadjust)這個數值表示出來，賦予各個進程，系統會根據oom_adj來判斷需要結束哪些進程。一般，oom_adj的分值由系統提供，系統可以根據應用當前的運行狀態來分配，oom_adj的分值範圍如下：-17<oom_adj<16。oom_adj的分值越大，該進程被系統選中終止的可能就越高，進程優先級就越低。

其中，用戶使用習慣可以包括但不限於應用的使用時間記錄、應用的累計使用次數、每次被使用的時長以及累計使用時長。根據用戶使用習慣可以確定哪些進程為用戶經常使用的應用的進程，或者確定哪些進程為用戶使用時間較長的應用的進程，或者確定哪些進程為用戶最近使用的應用的進程等等相關進程的信息。其中，可以通過rms模塊1221來進行app使用習慣的學習，此外，可以綜合考慮三類算法來識別app的重要程度。

請一併參見圖2a，圖2a是本發明實施例公開的一種app重要程度識別的示意圖。如圖2a所示，虛線框1代表的是基於機器學習的app重要程度識別模型；虛線框2代表的是基於統計規則的app重要程度識別模型，第三類算法是基於最近使用的應用(latestrecentused，lru)來識別。針對應用a來說，假設基於機器學習的app重要程度為ph(a)，基於統計規則的app重要程度識別為pl(a)，基於最近使用的應用識別為pu(a)，對應的權重分別為wh、wl、wu，則最後應用a的重要程度計算公式為

p(a)＝wh*ph(a)+wl*pl(a)+wu*pu(a)

其中，各權重值需要在訓練中不斷學習得到，與用戶無關，預置到app重要程度識別插件中，通過版本迭代更新。

可以根據應用的重要程度來分配用戶使用習慣(habit)的分值，habit的分值範圍如下：0<habit<16。habit的分值越低，表明用戶使用應用越頻繁。

其中，進程佔用系統資源可以包括但不限於計算資源，存儲資源，中央處理器(centralprocessingunit，cpu)資源以及輸入輸出(inputoutput，io)資源。可以根據資源佔用大小來設定進程佔用系統資源(resource)的分值，resource的分值範圍如下：0<resource3％，則resource＝16。通常，進程佔用的系統資源越多，該進程就越容易被選中回收該進程對應的內存。

應用的關聯關係是指應用之間存在的關聯關係，具體的，兩個應用之間可以通過進程關聯起來。本發明實施例中可以是後臺應用與前臺應用的關聯關係，該關聯關係是一個瞬態，可以根據當前進程狀態實時更新。其中，關聯關係包括但不限於getcontentprovider、startactivity、bindservice、unbindservice、startservice、stopservice以及widget。

請一併參見圖2b，圖2b是本發明實施例公開的一種應用的關聯關係的示意圖。其中，pid1、pid2、pid3、pid4……代表進程的身份標識，圖2b中最左邊的進程表示被最右邊的進程所依賴，兩個進程存在關聯關係，例如：pid1進程的service1被pid2進程通過bindservice關聯，pid2進程的service1被pid3進程通過startservice關聯。

一般在進行後臺進程清理的時候，被清理的進程可能會被其關聯的進程拉起來，或者由於清理了某個進程會導致功能異常。舉例來說，前臺輸入法需要使用後臺的provider獨立進程，如果把該後臺的provider獨立進程凍結或清理，會導致前臺輸入法異常；如果後臺應用在播放音樂，而音樂又依賴後臺的service獨立進程，如果把該service獨立進程凍結或清理，會導致音樂播放應用異常。其中，用戶可以設定應用的關聯關係(application-relation)的分值，以進行後續的加權操作。application-relation的分值的範圍如下：0<application-relation<16，如果應用之間是直接關聯，application-relation的分值可以為0，如果應用之間是間接關聯，application-relation的分值可以為16。application-relation的分值越高，表明該應用與其他應用的關聯性就越弱。

進一步地，針對每個應用，可以將所有關鍵因素的分值進行加權計算，獲得應用的重要程度。具體的，算法如下：

score＝oom_adj*poom_adj+habit*phabit+resource*presource+application-relation*papplication-relation，其中，poom_adj+phabit+presource+papplication-relation＝1。

score得分可以用來衡量應用的重要程度，score得分越小，應用的重要程度越高。比如：應用1的score得分高於應用2的score得分，則可以確定應用2的重要程度高於應用1。

更進一步地，根據score得分的高低可以對應用進行排序，針對每個應用，在應用包括至少兩個進程的情況下，可以根據進程優先級，對該應用包括的進程進行排序，這樣就可以生成後臺進程列表，該後臺進程列表實質上是一個包括應用以及應用的進程的二維表，該二維表中應用按照重要程度從高到底或者從低到高進行排序，應用的進程按照進程優先級從高到底或者從低到高進行排序。

請參見表2，表2是本發明實施例公開的一種應用-進程列表。

表2

其中，系統內運行的應用可以分為18大類；主要包括：關鍵系統服務、關鍵常駐應用、前臺應用、systemserver、前臺所依賴的後臺、普通系統服務、普通常駐應用、home在後臺、用戶可感知到的後臺應用、visible應用、手機管家保護的後臺、上一次在前臺的應用、和前臺弱關聯的後臺、用戶對應用使用習慣、應用預置重要程度、應用oom_adj大於2、系統識別為有害應用、人為識別有害應用(黑名單)。

作為一種可選的實施方式，上述後臺進程列表可以為一張表(如上表2)，或者，上述後臺進程列表可以包括3張子表(比如將上述表2分割成3部分，形成3張子表)，分別為不可回收列表、重要進程列表以及可殺列表。其中，不可回收列表主要是系統進程和服務，如果缺少這些進程，將會影響整個應用的運行，比如關鍵系統服務、關鍵常駐應用、前臺應用、systemserver、前臺所依賴的後臺等相關類應用，重要進程列表主要是設備閾值應用、用戶感知類應用以及用戶常用的重要應用，比如普通系統服務、普通常駐應用、home在後臺、用戶可感知到的後臺應用、visible應用、手機管家保護的後臺、上一次在前臺的應用、和前臺弱關聯的後臺等相關類應用，可殺列表主要包括用戶對應用使用習慣、應用預置重要程度、應用oom_adj大於2、系統識別為有害應用、人為識別有害應用等相關類應用。

203、從後臺進程列表中確定待回收內存的進程。

在後臺進程列表包括3張子表的情況下，內存回收列表處理順序為：在進行內存回收時，優先回收可殺列表，回收方式從可殺列表末尾從下往上進行回收；當可殺列表為空，同時系統內存還存在壓力，則開始回收重要進程列表，回收方式還是從重要進程列表末尾從下往上進行回收。基於上述原則，可以優先從可殺列表中確定待回收內存的進程，其次是從重要進程列表中確定待回收內存的進程。

可選的，上述列表的分類也可以是變化，比如：對於重要進程列表中重要性不夠高的應用，可以將該應用降低列入到可殺列表中。

其中，後臺進程列表包括多個應用的進程，待回收內存的進程為多個應用的進程中滿足進程所佔用內存與內存壓力值的差值的絕對值小於預設閾值的條件的進程，內存壓力值為內存閾值與系統當前的可用內存的差值。也就是說，待回收內存的進程所佔用內存可以大於內存壓力值，也可以小於內存壓力值，待回收內存的進程所佔用內存與內存壓力值的差值的絕對值在一定範圍之內，即絕對值小於預設閾值，該預設閾值可以是用戶設定的，也可以是系統默認的，本發明實施例不做限定。

其中，預先設定了內存壓力等級：高級、中級以及低級，高級表徵內存壓力較大，中級表徵內存壓力適中，低級表徵內存壓力較小。以及預先設定了內存壓力值所屬的範圍：第一範圍、第二範圍以及第三範圍，其中，第一範圍小於第二範圍，第二範圍小於第三範圍。可以根據內存壓力值所屬的範圍來確定系統當前的內存壓力等級。比如：當內存壓力值屬於第一範圍時，可以確定系統當前的內存壓力等級為低級，當內存壓力值屬於第二範圍時，可以確定系統當前的內存壓力等級為中級，當內存壓力值屬於第三範圍時，可以確定系統當前的內存壓力等級為高級。

在確定系統當前的內存壓力等級為高級的情況下，需要採取對待回收內存的進程進行清理的策略。這種策略是將終端中已存在的進程所佔用的資源進行銷毀回收，使得系統的可用內存增加。

在確定系統當前的內存壓力等級為中級的情況下，需要採取對待回收內存的進程進行系統級或應用級的內存回收的策略，系統級的內存回收的策略可以將系統的緩存根據其重要程度進行回收，達到增大空閒內存的目的。其中，一個應用可能有一個或多個進程，因此，可以採取針對應用級的內存回收的策略，比如：kill、compress、dropcache等策略。

在確定系統當前的內存壓力等級為低級的情況下，需要根據應用的重要程度採取對待回收內存的進程進行單個進程級壓縮或者單個進程級緩存回收的策略。如果應用的重要程度較高，可以採取對待回收內存的進程進行單個進程級壓縮，如果應用的重要程度較低，可以採取對待回收內存的進程進行單個進程級緩存回收。其中，對待回收內存的進程進行單個進程級壓縮是將終端中運行進程佔用的內存資源通過交換分區進行壓縮處理，從而達到減小佔用系統物理內存的目的。對待回收內存的進程進行單個進程級緩存回收是提前將終端中緩存佔用的內存空間釋放，減少緩存所佔用的內存，從而增加空閒內存，這樣就可以提高內存分配的效率。

本發明實施例中，根據系統當前的內存壓力，可以從後臺進程列表中確定待回收內存的進程，這樣就不會錯殺重要進程，不會多殺或少殺進程。

204、向系統內核發送處理指令，以觸發系統內核對待回收內存的進程進行處理以回收待回收內存的進程所佔用的內存。

本發明實施例中，不同的內存壓力等級可以採取不同的內存回收策略，每種內存回收策略對應一個接口。可以通過與內存回收策略對應的接口向系統內核發送處理指令，系統內核接收到處理指令之後，就可以採取相應的內存回收策略對待回收內存的進程進行處理以回收所述待回收內存的進程對應的內存。

其中，可以以kill_sig信號的方式向系統內核發送處理指令，通常，一個處理指令可以攜帶一個待回收內存的進程的標識。

其中，確定出的待回收的進程可以為一個也可以為多個，在一個進程需要發送多個處理指令的情況下，該進程可以一個一個連續地發送處理指令，而不需要在發送完一個處理指令後去檢測系統內核回收進程對應的內存的狀態，然後再去發送另一個處理指令。

作為一種可選的實施方式，在確定出的待回收的進程為多個的情況下，向系統內核發送處理指令包括：

調用多個線程向系統內核發送多個處理指令，其中，每個所述線程用於發送一個或多個處理指令。

在該可選的實施例中，在確定出的待回收的進程為多個的情況下，可以調用多個線程向系統內核發送多個處理指令，具體的，一個線程發送多個處理指令的實現方式為：該線程一個一個連續地發送處理指令，而不需要在發送完一個處理指令後去檢測系統內核回收進程對應的內存的狀態，然後再去發送另一個處理指令。系統對該待回收內存的進程所佔用的內存進行回收後，可以緩解系統當前的內存壓力。

可見，這種方式中，不需要等待系統內核真正完成進程對應的內存的回收操作，直接採取異步回收待回收內存的進程對應的內存的機制，加速後臺進程的回收性能，從而提高內存回收的效率。

請一併參見圖2c以及圖2d，圖2c是本發明實施例公開的一種相機啟動時序圖，圖2d是本發明實施例公開的另一種相機啟動時序圖。其中，圖2c中，相機應用程式在系統可用內存只有619mb時，在啟動開始時不進行內存回收，等到系統的內存低於系統水線後，通過(lowmemorykiller，lmk)機制回收內存，從圖2c可以看出，整個相機在內存只有619mb的時候啟動，到出現相機的拍照按鈕截止，總計花費了3.255s。其中，圖2d中，相機應用程式在系統可用內存只有604mb時，採用本發明實施例中的方案，在啟動時採取相應的策略進行內存回收，從圖2d可以看出，整個相機在內存只有604mb的時候啟動，到出現相機的拍照按鈕截止，總計花費了1.85s。可見，從圖2c以及圖2d的對比可以看出，在同樣的測試環境，可用內存相差不大的條件下，本發明方案相較於傳統的lmk方案，相機啟動性能得到明顯改善。

可見，在圖2所描述的方法流程中，在檢測到第一關鍵事件並確定系統當前的可用內存小於內存閾值時，可以主動進行內存回收，當應用程式真正需要大量內存的時候，系統內核已經回收回來大量可用的內存，從而可以減少終端出現卡頓現象的概率。

請參見圖3，圖3是本發明實施例公開的另一種內存回收方法的流程示意圖。其中，該方法可以應用於圖1所示的內存管控模塊1223，具體的，內存管控模塊1223可以是一個或多個線程，或者，內存管控模塊1223可以是一個或多個進程。如圖3所示，該方法可以包括以下步驟。

301、在檢測到第二關鍵事件且確定系統處於空閒狀態時，確定當前系統的可用內存小於內存閾值。

本發明實施例中，內存管控模塊1223可以檢測應用程式的關鍵事件，具體的，可以在活動管理器服務(activitymanagerservice，ams)啟動每個應用的活動(activity)的時候，通過鉤子(hook)函數獲取應用程式的關鍵信息(如進程名稱、用戶身份標識(useridentifier，uid)以及進程身份標識(processidentifier，pid)，進一步地，ams可以將獲取到的應用程式的關鍵信息發送給內存管控模塊1223，這樣，內存管控模塊1223就可以檢測應用程式的關鍵事件。

其中，該應用程式的關鍵事件可以包括但不限於程序啟動開始事件、清理事件、內存不足(outofmenory，oom)事件，程序啟動完成事件、亮屏事件、滅屏事件、觸屏事件、界面切換事件、任務切換完成事件、廣播事件、網絡連接/掃描/狀態變化事件(如wifi、2/3/4g、藍牙、紅外、gps、電臺廣播、近場通信(nearfieldcommunication，nfc))、外設連接變化事件(如插拔充電器等)、通知鬧鈴類事件、電話類事件(來電、信號變化等)、媒體類事件(音視頻變化、錄音播放)、閃光燈相關類事件、程序安裝卸載類事件、電池電量類事件等。

本發明實施例中，如果當前系統存在人機互動操作，系統直接進行內存回收，有可能會導致用戶的響應操作由於cpu得不到及時響應而影響用戶體驗，這種情況下就不能立即進行內存回收。

可以預先將不需要立即進行內存回收的事件定義為第二關鍵事件，該第二關鍵事件可以包括但不限於以下程序啟動完成事件、亮屏事件、滅屏事件、觸屏事件、界面切換事件、任務切換完成事件以及廣播事件。

在檢測到第二關鍵事件時，可以先判斷系統是否處於空閒狀態，在確定系統處於空閒狀態時，再讀取當前系統的可用內存，以及判斷當前系統的可用內存是否小於內存閾值，在確定當前系統的可用內存小於內存閾值時，表明當前系統存在內存壓力，需要進行內存回收。其中，該內存閾值為與第二關鍵事件對應的第一內存閾值。其中，系統的空閒狀態可以包括終端的空閒狀態和應用的空閒狀態。

可選的，該內存閾值可以靜態預置的，或者，該內存閾值可以動態配置的，具體可以參照圖2中所描述的，在此不再贅述。

可選的，可以通過讀取終端的運行狀態來確定系統是否處於空閒狀態，或者，可以通過判斷系統當前的負載情況來確定系統是否處於空閒狀態。

系統處於空閒狀態有2種場景，第一種是在用戶未使用終端的情況下，比如終端處於待機狀態可以看作是系統處於空閒狀態，又比如：在應用啟動完成出現顯示畫面，但以後並沒有和終端進行交互，這個時候系統沒有大量的io操作，可以看作是系統處於空閒狀態，第二種是在用戶使用終端但系統當前的負載不影響用戶體驗的情況下，可以看作是系統處於空閒狀態，比如系統的負載小於負載閾值。

具體的，確定系統處於空閒狀態的方式具體可以包括以下步驟：

11)判斷所述系統當前的負載是否小於負載閾值；

12)在所述系統當前的負載小於所述負載閾值的情況下，確定系統處於空閒狀態。

在該實施例中，可以預先設置一個負載閾值，該負載閾值可以是影響用戶體驗的系統的負載的臨界值。如果判斷系統當前的負載小於負載閾值，表明系統當前的負載不影響用戶體驗，則可以確定系統處於空閒狀態。

302、在系統處於空閒狀態時創建後臺進程列表。

本發明實施例中，需要在系統處於空閒狀態時進程內存回收，而後臺進程列表是一個動態列表，故同樣需要在系統處於空閒狀態時創建後臺進程列表，這樣可以確保後臺進程列表的有效性。

303、從後臺進程列表中確定待回收內存的進程。

304、向系統內核發送處理指令，以觸發系統內核對待回收內存的進程進行處理以回收待回收內存的進程對應的內存。

可見，在圖3所描述的方法流程中，在檢測到第二關鍵事件且系統處於空閒狀態時確定當前系統的可用內存小於內存閾值，可以主動進行內存回收，當應用程式真正需要大量內存的時候，系統內核已經回收回來大量可用的內存，從而可以減少終端出現卡頓現象的概率。

請參見圖4，圖4是本發明實施例公開的另一種內存回收方法的流程示意圖。其中，該方法可以應用於圖1所示的內存管控模塊1223，具體的，內存管控模塊1223可以是一個或多個線程，或者，內存管控模塊1223可以是一個或多個進程。如圖4所示，該方法可以包括以下步驟。

401、在檢測到第二關鍵事件時，確定當前系統的可用內存小於內存閾值。

其中，第二關鍵事件具體可以參照圖3中所描述的，在此不再贅述，內存閾值具體可以參照圖2所描述的，在此不再贅述。

本發明實施例中，圖3所示的實施例是在檢測到第二關鍵事件時先判斷系統是否處於空閒狀態，在確定系統處於空閒狀態時再去讀取當前系統的可用內存，而圖4所示的實施例是在檢測到第二關鍵事件時，先讀取當前系統的可用內存，在確定當前系統的可用內存小於內存閾值的情況下，再判斷系統是否處於空閒狀態，在確定系統處於空閒狀態時，執行步驟402。

402、在確定系統處於空閒狀態時創建後臺進程列表。

403、從後臺進程列表中確定待回收內存的進程。

404、向系統內核發送處理指令，以觸發系統內核對待回收內存的進程進行處理以回收待回收內存的進程對應的內存。

可見，在圖4所描述的方法流程中，在檢測到第二關鍵事件並確定系統當前的可用內存小於內存閾值時，可以在系統處於空閒狀態時主動進行內存回收，當應用程式真正需要大量內存的時候，系統內核已經回收回來大量可用的內存，從而可以減少終端出現卡頓現象的概率。

請參見圖5，圖5是本發明實施例公開的一種內存回收裝置的結構示意圖。其中，該內存回收裝置可以用於執行圖2～圖4中所描述的內存回收方法的部分或全部步驟，具體請參見圖2～圖4中的相關描述，在此不再贅述。如圖5所示，該內存回收裝置500可以包括：

確定單元501，用於在確定系統當前的可用內存小於內存閾值時，從後臺進程列表中確定待回收內存的進程，其中，所述後臺進程列表包括一個或多個應用的進程，所述待回收內存的進程為所述一個或多個應用的進程中滿足進程所佔用內存與內存壓力值的差值的絕對值小於預設閾值的條件的進程，所述內存壓力值為所述內存閾值與所述系統當前的可用內存的差值；

發送單元502，用於向系統內核發送處理指令，以觸發所述系統內核對所述待回收內存的進程進行處理以回收所述待回收內存的進程所佔用的內存。

其中，可選的，在檢測到第一關鍵事件時觸發所述確定系統當前的可用內存小於內存閾值的操作，且所述內存閾值為與所述第一關鍵事件對應的第一內存閾值。所述第一關鍵事件包括如下事件中的任意一種：程序啟動開始事件、清理事件以及內存不足oom事件。

其中，可選的，在檢測到第二關鍵事件且確定系統處於空閒狀態時觸發所述確定當前系統的可用內存小於內存閾值的操作，且所述內存閾值為與所述第二關鍵事件對應的第二內存閾值。

其中，可選的，在檢測到第二關鍵事件時觸發所述確定當前系統的可用內存小於內存閾值的操作，在確定系統處於空閒狀態時觸發所述從後臺進程列表中選擇待回收內存的進程的操作，且所述內存閾值為與所述第二關鍵事件對應的第二內存閾值。所述第二關鍵事件包括如下事件中的任意一種：程序啟動完成事件、亮屏事件、滅屏事件、觸屏事件、界面切換事件、任務切換完成事件以及廣播事件。

可選的，所述確定單元501具體用於：

判斷所述系統當前的負載是否小於負載閾值；

在所述系統當前的負載小於所述負載閾值的情況下，確定系統處於空閒狀態。

可選的，在確定出的所述待回收的進程為多個的情況下，所述發送單元502具體用於：

調用多個線程向系統內核發送多個處理指令，其中，每個所述線程用於發送一個或多個處理指令。

可選的，所述確定單元501具體用於：

根據應用的重要程度從低到高的順序，從所述後臺進程列表包括的多個應用中確定至少一個應用；

根據進程優先級從低到高的順序，從所述至少一個應用包括的進程中確定待回收內存的進程。

可選的，所述內存回收裝置還包括：

創建單元503，用於在所述確定單元501確定所述系統當前的可用內存小於所述內存閾值時創建所述後臺進程列表，或，用於在所述確定單元501確定所述系統當前的可用內存小於所述內存閾值並且所述系統處於空閒狀態時創建所述後臺進程列表。

可選的，創建單元503具體用於：

確定當前在後臺運行的每個應用的關鍵因素的分值，所述關鍵因素包括以下中的一個或多個：進程優先級、用戶使用習慣、進程佔用系統資源以及應用的關聯關係；

針對每個所述應用，將所有所述關鍵因素的分值進行加權計算，獲得所述應用的重要程度；

根據所有所述應用的重要程度，對所有所述應用進行排序；

根據進程優先級，對排序後的每個所述應用包括的進程進行排序，以生成後臺進程列表。

在圖5所描述的內存回收裝置中，在確定系統當前的可用內存小於內存閾值時，可以主動進行內存回收，當應用程式真正需要大量內存的時候，系統內核已經回收回來大量可用的內存，從而可以減少終端出現卡頓現象的概率。

請參見圖6，圖6是本發明實施例公開的一種終端的結構示意圖。其中，該終端可以用於執行圖2～圖4中所描述的內存回收方法的部分或全部步驟，具體請參見圖2～圖4中的相關描述，在此不再贅述。如圖6所示，終端600包括：射頻(radiofrequency，rf)電路601、存儲器602、輸入單元603、顯示單元604、傳感器605、音頻電路606、無線保真(wirelessfidelity，wifi)模塊607、處理器608、以及電源609等部件。本領域技術人員可以理解，圖6中示出的終端結構並不構成對手機的限定，可以包括比圖示更多或更少的部件，或者組合某些部件，或者不同的部件布置。

rf電路601可用於收發信息或通話過程中，信號的接收和發送，特別地，將基站的下行信息接收後，給處理器608處理；另外，將設計上行的數據發送給基站。通常，rf電路601包括但不限於天線、至少一個放大器、收發信機、耦合器、低噪聲放大器(lownoiseamplifier，lna)、雙工器等。此外，rf電路601還可以通過無線通信與網絡和其他設備通信。上述無線通信可以使用任一通信標準或協議，包括但不限於全球移動通訊系統(globalsystemofmobilecommunication，gsm)、通用分組無線服務(generalpacketradioservice，gprs)、碼分多址(codedivisionmultipleaccess，cdma)、寬帶碼分多址(widebandcodedivisionmultipleaccess，wcdma)、長期演進(longtermevolution，lte)、電子郵件、短消息服務(shortmessagingservice，sms)等。

存儲器602存儲電腦程式，該電腦程式包括應用程式6021和作業系統程序6022，處理器608用於讀取存儲器602中的電腦程式，然後執行電腦程式定義的方法，例如處理器608讀取作業系統程序6022從而在該終端600上運行作業系統以及實現作業系統的各種功能，或讀取一種或多種應用程式6021，從而在該終端600上運行應用。作業系統6022中包含了可實現本發明實施例提供的內存回收方法的電腦程式，從而使得處理器608讀取到該作業系統程序6022並運行該作業系統後，該作業系統可具備本發明實施例提供的內存回收功能。另外，存儲器602還存儲有除電腦程式之外的其他數據6023，其他數據6023可包括作業系統6022或應用程式6021被運行後產生的數據，該數據包括系統數據(例如作業系統的配置參數)和用戶數據。此外，存儲器602一般包括內存和外存。內存可以為隨機存儲器(ram)，只讀存儲器(rom)，以及高速緩存(cache)等。外存可以為硬碟、光碟、usb盤、軟盤或磁帶機等。電腦程式通常被存儲在外存上，處理器在執行處理前會將電腦程式從外存加載到內存。

輸入單元603可用於接收輸入的數字或字符信息，以及產生與終端600的用戶設置以及功能控制有關的鍵信號輸入。具體地，輸入單元603可包括觸控面板6031以及其他輸入設備6032。觸控面板6031，也稱為觸控螢幕，可收集用戶在其上或附近的觸摸操作(比如用戶使用手指、觸筆等任何適合的物體或附件在觸控面板6031上或在觸控面板6031附近的操作)，並根據預先設定的程式驅動相應的連接裝置。可選的，觸控面板6031可包括觸摸檢測裝置和觸摸控制器兩個部分。其中，觸摸檢測裝置檢測用戶的觸摸方位，並檢測觸摸操作帶來的信號，將信號傳送給觸摸控制器；觸摸控制器從觸摸檢測裝置上接收觸摸信息，並將它轉換成觸點坐標，再送給處理器608，並能接收處理器608發來的命令並加以執行。此外，可以採用電阻式、電容式、紅外線以及表面聲波等多種類型實現觸控面板6031。除了觸控面板6031，輸入單元603還可以包括其他輸入設備6032。具體地，其他輸入設備6032可以包括但不限於物理鍵盤、功能鍵(比如音量控制按鍵、開關按鍵等)、軌跡球、滑鼠、操作杆等中的一種或多種。

顯示單元604可用於顯示由用戶輸入的信息或提供給用戶的信息以及手機的各種菜單。顯示單元604可包括顯示面板6041，可選的，可以採用液晶顯示器(liquidcrystaldisplay，lcd)、有機發光二極體(organiclight-emittingdiode,oled)等形式來配置顯示面板6041。進一步的，觸控面板6031可覆蓋顯示面板6041，當觸控面板6031檢測到在其上或附近的觸摸操作後，傳送給處理器608以確定觸摸事件的類型，隨後處理器608根據觸摸事件的類型在顯示面板6041上提供相應的視覺輸出。雖然在圖6中，觸控面板6031與顯示面板6041是作為兩個獨立的部件來實現手機的輸入和輸入功能，但是在某些實施例中，可以將觸控面板6031與顯示面板6041集成而實現手機的輸入和輸出功能。

傳感器605可以為光傳感器、運動傳感器以及其他傳感器。具體地，光傳感器可包括環境光傳感器及接近傳感器，其中，環境光傳感器可根據環境光線的明暗來調節顯示面板6041的亮度，接近傳感器可在手機移動到耳邊時，關閉顯示面板6041和/或背光。作為運動傳感器的一種，加速計傳感器可檢測各個方向上(一般為三軸)加速度的大小，靜止時可檢測出重力的大小及方向，可用於識別手機姿態的應用(比如橫豎屏切換、相關遊戲、磁力計姿態校準)、振動識別相關功能(比如計步器、敲擊)等；至於手機還可配置的陀螺儀、氣壓計、溼度計、溫度計、紅外線傳感器等其他傳感器，在此不再贅述。

音頻電路606、揚聲器6061，傳聲器6062可提供用戶與手機之間的音頻接口。音頻電路606可將接收到的音頻數據轉換後的電信號，傳輸到揚聲器6061，由揚聲器6061轉換為聲音信號輸出；另一方面，傳聲器6062將收集的聲音信號轉換為電信號，由音頻電路606接收後轉換為音頻數據，再將音頻數據輸出處理器608處理後，經rf電路601以發送給比如另一手機，或者將音頻數據輸出至存儲器602以便進一步處理。

wifi屬於短距離無線傳輸技術，終端通過wifi模塊607可以幫助用戶收發電子郵件、瀏覽網頁和訪問流式媒體等，它為用戶提供了無線的寬帶網際網路訪問。雖然圖6示出了wifi模塊607，但是可以理解的是，其並不屬於終端的必須構成，完全可以根據需要在不改變發明的本質的範圍內而省略。

處理器608是終端的控制中心，利用各種接口和線路連接整個終端的各個部分，通過運行或執行存儲在存儲器602內的軟體程序和/或模塊，以及調用存儲在存儲器602內的數據，執行終端的各種功能和處理數據，從而對終端進行整體監控。可選的，處理器608可以包括一個或多個處理器，例如，處理器608可以包括一個或多個中央處理器，或者包括一個中央處理器和一個圖形處理器。當處理器608包括多個處理器時，這多個處理器可以集成在同一塊晶片上，也可以各自為獨立的晶片。一個處理器可以包括一個或多個處理核。

終端600還包括給各個部件供電的電源609(比如電池)，優選的，電源可以通過電源管理系統與處理器608邏輯相連，從而通過電源管理系統實現管理充電、放電、以及功耗管理等功能。

儘管未示出，終端還可以包括攝像頭、藍牙模塊等，在此不再贅述。

前述實施例中，各步驟方法流程可以基於該終端的結構實現。其中應用層和作業系統內核均可視為處理器608的抽象化結構的組成部分。

在本發明實施例中，處理器608通過調用存儲於存儲器602中的程序代碼，用於執行以下操作：

在確定系統當前的可用內存小於內存閾值時，從後臺進程列表中確定待回收內存的進程，其中，所述後臺進程列表包括一個或多個應用的進程，所述待回收內存的進程為所述一個或多個應用的進程中滿足進程所佔用內存與內存壓力值的差值的絕對值小於預設閾值的條件的進程，所述內存壓力值為所述內存閾值與所述系統當前的可用內存的差值；

向系統內核發送處理指令，以觸發所述系統內核對所述待回收內存的進程進行處理以回收所述待回收內存的進程所佔用的內存。

其中，在檢測到第一關鍵事件時觸發所述確定系統當前的可用內存小於內存閾值的操作，且所述內存閾值為與所述第一關鍵事件對應的第一內存閾值。

其中，所述第一關鍵事件包括如下事件中的任意一種：程序啟動開始事件、清理事件以及內存不足oom事件。

其中，在檢測到第二關鍵事件且確定系統處於空閒狀態時觸發所述確定當前系統的可用內存小於內存閾值的操作，且所述內存閾值為與所述第二關鍵事件對應的第二內存閾值。

其中，在檢測到第二關鍵事件時觸發所述確定當前系統的可用內存小於內存閾值的操作，在確定系統處於空閒狀態時觸發所述從後臺進程列表中選擇待回收內存的進程的操作，且所述內存閾值為與所述第二關鍵事件對應的第二內存閾值。

其中，所述第二關鍵事件包括如下事件中的任意一種：程序啟動完成事件、亮屏事件、滅屏事件、觸屏事件、界面切換事件、任務切換完成事件以及廣播事件。

作為另一種可選的實施方式，所述處理器608確定系統處於空閒狀態包括：

判斷所述系統當前的負載是否小於負載閾值；

在所述系統當前的負載小於所述負載閾值的情況下，確定系統處於空閒狀態。

作為另一種可選的實施方式，在確定出的所述待回收的進程為多個的情況下，所述處理器608向系統內核發送處理指令包括：

調用多個線程向系統內核發送多個處理指令，其中，每個所述線程用於發送一個或多個處理指令。

作為另一種可選的實施方式，所述處理器608從後臺進程列表中確定待回收內存的進程包括：

根據應用的重要程度從低到高的順序，從所述後臺進程列表包括的多個應用中確定至少一個應用；

根據進程優先級從低到高的順序，從所述至少一個應用包括的進程中確定待回收內存的進程。

作為另一種可選的實施方式，所述處理器608通過調用存儲於存儲器602中的程序代碼，還用於執行以下操作：

在確定所述系統當前的可用內存小於所述內存閾值時創建所述後臺進程列表。

作為另一種可選的實施方式，所述處理器608通過調用存儲於存儲器602中的程序代碼，還用於執行以下操作：

在確定所述系統當前的可用內存小於所述內存閾值並且所述系統處於空閒狀態時創建所述後臺進程列表。

作為另一種可選的實施方式，所述處理器608創建所述後臺進程列表包括：

確定當前在後臺運行的每個應用的關鍵因素的分值，所述關鍵因素包括以下中的一個或多個：進程優先級、用戶使用習慣、進程佔用系統資源以及應用的關聯關係；

針對每個所述應用，將所有所述關鍵因素的分值進行加權計算，獲得所述應用的重要程度；

根據所有所述應用的重要程度，對所有所述應用進行排序；

根據進程優先級，對排序後的每個所述應用包括的進程進行排序，以生成後臺進程列表。

在圖6所描述的終端600中，可以在確定系統當前的可用內存小於內存閾值時，可以主動進行內存回收，當應用程式真正需要大量內存的時候，系統內核已經回收回來大量可用的內存，從而可以減少終端出現卡頓現象的概率。

需要說明的是，對於前述的各方法實施例，為了簡單描述，故將其都表述為一系列的動作組合，但是本領域技術人員應該知悉，本發明並不受所描述的動作順序的限制，因為依據本發明，某些步驟可以採用其他順序或者同時進行。其次，本領域技術人員也應該知悉，說明書中所描述的實施例均屬於優選實施例，所涉及的動作和模塊並不一定是本發明所必須的。

在上述實施例中，對各個實施例的描述都各有側重，某個實施例中沒有詳述的部分，可以參見其他實施例的相關描述。

在本申請所提供的幾個實施例中，應該理解到，所揭露的裝置，可通過其它的方式實現。例如，以上所描述的裝置實施例僅僅是示意性的，例如所述單元的劃分，僅僅為一種邏輯功能劃分，實際實現時可以有另外的劃分方式，例如多個單元或組件可以結合或者可以集成到另一個系統，或一些特徵可以忽略，或不執行。另一點，所顯示或討論的相互之間的耦合或直接耦合或通信連接可以是通過一些接口，裝置或單元的間接耦合或通信連接，可以是電性或其它的形式。

所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位於一個地方，或者也可以分布到多個網絡單元上。可以根據實際的需要選擇其中的部分或者全部單元來實現本實施例方案的目的。

另外，在本發明各個實施例中的各功能單元可以集成在一個處理單元中，也可以是各個單元單獨物理存在，也可以兩個或兩個以上單元集成在一個單元中。上述集成的單元既可以採用硬體的形式實現，也可以採用軟體功能單元的形式實現。

所述集成的單元如果以軟體功能單元的形式實現並作為獨立的產品銷售或使用時，可以存儲在一個計算機可讀取存儲器中。基於這樣的理解，本發明的技術方案本質上或者說對現有技術做出貢獻的部分或者該技術方案的全部或部分可以以軟體產品的形式體現出來，該計算機軟體產品存儲在一個存儲器中，包括若干指令用以使得一臺計算機設備(可為個人計算機、伺服器或者網絡設備等)執行本發明各個實施例所述方法的全部或部分步驟。而前述的存儲器包括：u盤、只讀存儲器(rom，read-onlymemory)、隨機存取存儲器(ram，randomaccessmemory)、移動硬碟、磁碟或者光碟等各種可以存儲程序代碼的介質。

本領域普通技術人員可以理解上述實施例的各種方法中的全部或部分步驟是可以通過程序來指令相關的硬體來完成，該程序可以存儲於一計算機可讀存儲器中，存儲器可以包括：快閃記憶體盤、只讀存儲器(英文：read-onlymemory，簡稱：rom)、隨機存取器(英文：randomaccessmemory，簡稱：ram)、磁碟或光碟等。

以上對本發明實施例進行了詳細介紹，本文中應用了具體個例對本發明的原理及實施方式進行了闡述，以上實施例的說明只是用於幫助理解本發明的方法及其核心思想；同時，對於本領域的一般技術人員，依據本發明的思想，在具體實施方式及應用範圍上均會有改變之處，綜上所述，本說明書內容不應理解為對本發明的限制。