Andoid系統從Android5.0開始對獲取前臺程序介面進行相關限制。本文為對突破Android介面限制進行的一系列研究的總結。目前所有獲取前臺程序的介面有如下7種方式：

接下來將對每一種方案進行詳細的闡述。

1.通過RunningTask

1.1.實現原理

當一個App處於前臺的時候，會處於RunningTask的這個棧的棧頂，所以我們可以取出RunningTask的棧頂的任務程序，看他與我們的想要判斷的App的包名是否相同，來達到效果。

程式碼實現如下：

1.2.方案缺點

getRunningTask方法在Android5.0以上已經被廢棄，只會返回自己和系統的一些不敏感的

task，不再返回其他應用的task，用此方法來判斷自身App是否處於後臺，仍然是有效的，但是無法判斷其他應用是否位於前臺，因為不再能獲取資訊

2.通過RunningProcess

2.1.實現原理

通過runningProcess獲取到一個當前正在執行的程序的List，我們遍歷這個List中的每一個程序，判斷這個程序的一個importance 屬性是否是前臺程序，並且包名是否與我們判斷的APP的包名一樣，如果這兩個條件都符合，那麼這個App就處於前臺。

程式碼實現如下：

2.2.方案缺點

1、對於前臺Service（通過setForeground介面設定）的程序會被誤判判斷是前臺程序，程式碼上的表現就是

appProcess.importance的值永遠是ActivityManager.RunningAppProcessInfo.IMPORTANCE_FOREGROUND，這樣就會存在誤判的情況出現。

2、該方案只在Android5.0之前有效，Android5.0以後也被系統廢棄。而且基於Android5.0的小米開發版及部分基於Android5.0的華為版本該方案也會存在問題。

針對會在部分Android5.0的機型上存在問題的問題，我封裝了一個測試介面用於判斷，如果該介面返回為true則說明為問題機型，則RunningProcess方案不適用。測試介面的思想為：先通過getRunningAppProcesses

獲取到程序的List，然後判斷如果程序數量非常少（這裡設定的閾值為3個），或者程序列表中只有Launcher和應用自身存在，則認為介面存在問題。測試程式碼如下：

3.通過ActivityLifecycleCallbacks

3.1.實現原理

AndroidSDK14在Application類裡增加了ActivityLifecycleCallbacks，我們可以通過這個Callback拿到App所有Activity的生命週期回撥。

public interface ActivityLifecycleCallbacks {

voidonActivityCreated(Activity activity, Bundle savedInstanceState);

voidonActivityStarted(Activity activity);

voidonActivityResumed(Activity activity);

voidonActivityPaused(Activity activity);

voidonActivityStopped(Activity activity);

voidonActivitySaveInstanceState(Activity activity, Bundle outState);

voidonActivityDestroyed(Activity activity);

}

知道這些資訊，我們就可以用更官方的辦法來解決問題，當然還是利用方案二里的Activity生命週期的特性，我們只需要在Application的onCreate()裡去註冊上述介面，然後由Activity回調回來執行狀態即可。

3.2.方案特點

1、在Android應用開發中一般認為back鍵是可以捕獲的，而Home鍵是不能捕獲的（除非修改framework）,雖然這兩種方式的Activity生命週期並不相同，但是二者都會執行onStop（）；所以並不關心到底是觸發了哪個鍵切入後臺的。另外,Application是否被銷燬,都不會影響判斷的正確性。

2、該方案除了用於判斷當前應用內那個Activity位於前臺外，還可以用於作為實現“程序完全退出”的一種很好的技術方案。

3、該方案需要在Application中進行註冊相關Activity生命週期的回撥，主要程式碼如下：

在用該介面判斷應用是否在前臺時，只需要對activityCount計數進行判斷即可：

4.通過UsageStatsManager獲取

4.1.實現原理

通過使用UsageStatsManager獲取，此方法是Android5.0之後提供的新API，可以獲取一個時間段內的應用統計資訊，但是必須滿足一下要求

使用前提

1、此方法只在android5.0以上有效

2、AndroidManifest中加入此許可權

3、手動開啟許可權：開啟手機設定，點選安全-高階，在有權檢視使用情況的應用中，為這個App打上勾

該方案的實現程式碼如下：

4.2.方案特點

1、該方案最大的缺點是需要使用者手動授權，因此在使用時要結合場景做適當引導。

2、該方案為Android5.0以後Google官方比較推薦的獲取程序資訊的方式，是最符合Google意圖的方式，不過在使用時會有一些延時需要小心處理。

4.3.相關輔助介面

1、跳轉到“檢視應用使用許可權”介面的跳轉程式碼如下：

2、判斷“檢視應用使用許可權”是否開啟的介面：

5.通過AccessibilityService獲取

5.1.技術原理

Android 輔助功能(AccessibilityService) 為我們提供了一系列的事件回撥，幫助我們指示一些使用者介面的狀態變化。我們可以派生輔助功能類，進而對不同的AccessibilityEvent進行處理。同樣的，這個服務就可以用來判斷當前的前臺應用

5.2.方案特點

1. AccessibilityService有非常廣泛的 ROM 覆蓋，特別是非國產手機，從 API Level 8(Android 2.2) 到API Level 23(Android 6.0)。

2. AccessibilityService不再需要輪詢的判斷當前的應用是不是在前臺，系統會在視窗狀態發生變化的時候主動回撥，耗時和資源消耗都極小。

3. 不需要許可權請求

4. 它是一個穩定的方法，並非利用 Android 一些設計上的漏洞，可以長期使用的可能很大。

5. 可以用來判斷任意應用甚至 Activity，PopupWindow， Dialog 物件是否處於前臺。

5.3.方案缺點

1、需要使用者手動開啟輔助功能。

2、輔助功能會伴隨應用被“強行停止”或第三方管理工具通過Root而剝奪，而且程序重啟後需要對使用者進行重新引導開啟。

3、部分廠商可能對輔助功能進行限制，如已發現的vivo的部分機型

5.4.方案實現

1、派生 ACCESSIBILITY SERVICE，建立視窗狀態探測服務：

4、建立 ACCESSIBILITY SERVICE INFO 屬性檔案：

5、在AndroidManifes.xml中註冊第1步定義的Service：

6、使用服務判斷應用是否在前臺：

5.5.相關輔助介面

1、跳轉到“輔助功能”設定介面的程式碼如下：

2、判斷輔助功能是否開啟的程式碼如下：

6.自解析/process獲取

6.1.技術原理

Linux系統核心會把process程序資訊儲存在/proc目錄下，通過JNI封裝介面，在JNI中去訪問並解析相關程序的裝置節點，再根據程序的屬性判斷是否為前臺

6.2.方案特點

1、不需要任何許可權。

2、可以判斷任意一個應用是否在前臺，而不侷限在自身應用。

3、當/proc下資料夾過多時，此方法是耗時操作。

4、該方案存在能耗問題。

5、在Android6.0.1以上版本或部分廠商版本受限於SEAndroid，只能獲取到第三方程序的資訊。

6.3.程式碼實現

在Android層我們平時使用較多的程序屬性包括：pid、uid、processName、packageName、importance等，在自解析方案中只對這些屬性進行解析就可以滿足大部分需求。

該方案中需要進行解析的裝置節點包括：

6.4.程式碼缺點

1、該方案在6.0手機適配執行OK，但在最新的小米、華為6.0.1手機中發現受SELinux的限制，無法讀取系統應用的裝置節點進行解析，只能解析第三方應用裝置節點。

2、可能存在能耗問題。

6.5.能耗問題解決

1、Java層物件快取：對呼叫比較頻繁的Java層物件在JNI中建立全域性快取，這就避免了每次呼叫時都需要通過JNI介面獲取。

對一些判斷是需要的場景在初始化時有Java層傳入Jni層，並建立全域性快取：

2、過來為Android程序：將pid小於1000的Native程序過濾掉。

3、只解析發生變化的程序：在每次輪詢解析/proc節點時先判斷程序的pid在快取中是否存在，如果存在只需要更新程序的優先順序資訊，其他資訊不會發生變化；如果程序之前不存在則需要全新解析：

命中快取時的解析程式碼如下：

未命中快取時，則進全新解析：

4、在解析程序時，過來父程序為zygote的程序：Android中所有應用程序的父程序都是zyote。

5、在Java層對呼叫做快取處理：對於呼叫比較頻繁的情況，如果當次Native呼叫沒有完成，則之前返回之前的值，不需要堵塞等待。

6、對於只關心前臺程序的場景進行特殊處理：

通過優化後，適配方案的能耗與系統介面基本保持一致：

Android獲取前臺程序技術方案