判斷App是否在後台運行，判斷App後台運行

判斷App是否在後台運行，判斷App後台運行

在一些場景中，經常會需要判斷App是否在後台運行，比如是否顯示解鎖界面，收到新消息是否顯示Notification等。需求可能是多樣化的，但所依仗的原理是相通的，今天Stay打算說說這些需求的最優解。

當然，Stay肯定不會說去for loop判斷當前runningProcess或者runningTasks。比如：

這樣

或者這樣

這種方法調用起來感覺就像是在用Windows系統裡的任務管理器，真是讓人蛋疼。我們暫且不去計較性能問題，就說為啥Android連個像樣的API都不給我，著實讓人郁悶。

如果帶著這樣的質疑去調研，你會發現還真有其他方式來實現。

Android在SDK 14的時候提供了一個Callback。ActivityLifecycleCallbacks，你可以通過這個Callback拿到App所有Activity的生命周期回調。看圖：

這個Callback寫在Application裡的，你可以在Application初始化的時候來注冊。我們可以寫個單例類來cache這些status。這裡我叫它AppStatusTracker。在Application的onCreate()裡讓AppStatusTracker注冊ActivityLifecycleCallbacks。

拿到這些Callback有什麼用呢，我怎麼能知道App是否在前台運行呢。 

別急，我們先來說說Activity的生命周期。這是面試時必問題，雖然有官方答案，但真正理解生命周期，並靈活運用的不多。

我們來設想下如果Activity調用了onResume()，那麼這個Activity肯定是可見的，也就是運行在前台的。如果調用了onPause()，且沒有Activity來調用onResume()，那麼App要跑到後台去了。至於它是點了home鍵還是back鍵我都不管。

通過這樣的判斷，我們來利用ActivityLifecycleCallbacks回調的onActivityResumed()和onActivityPaused()方法來計數，如果只有一個activityCount，那麼當前App在前台，如果木有activityCount，它就在後台。

好了，就這麼愉快的解決了，再也不用for loop了。但是很快你會發現，這裡有個延時，會導致判斷不准確。

我們假設有兩個Activities，一個A，一個B，從A跳轉到B，生命周期怎麼走的？ A.onPause() -> B.onResume() 對應到ActivityLifecycleCallbacks裡是onActivityPaused(A) -> onActivityResumed(B)，剛才我們說的計數resumeCount，在onActivityPaused()裡--，在onActivityResumed()裡++， 根據這樣的判斷會有個短暫的間隔，也就是在A的onPause()到B的onResume()之間，App是運行在後台的，這樣邏輯肯定就不對了。

那如何解決問題呢？如果你打印過生命周期的哪些方法，你會發現是Activity間切換的步驟是這樣的： 

從WelcomeActivity跳轉到GestureActivity。（這裡只說onStart, onResume這些回調 ）
A.onPause() -> B.onStart() -> B.onResume() -> A.onStop()

我估摸著60%的同學都沒想過Activities之間切換的生命周期是什麼樣的。

通過這些回調我們可以將這個計數放在onStart()和onStop()中去，這樣就不會存在那個短暫間隔。activityCount==1，那麼就是前台，activityCount==0，那就是後台。這樣判斷很很簡單了吧。

現在再說，什麼情況下來顯示手勢解鎖界面。 
我的需求是當用戶鎖屏後再解鎖或者切換到後台10分鐘後顯示手勢解鎖界面。 
我們拆分下需求，先說鎖屏，解鎖。

這個是有BroadCastReciever來接收的，注冊下就可以了，每次收到鎖屏ACTION_SCREEN_OFF的action時，將AppStatusTracker裡的isScreenOff設置為true。 
當onActivityResumed()被調用時再將isScreenOff設為false。

再說切換到後台10分鐘後顯示手勢解鎖。這個只需要在onActivityStop()時更新下lastBackgroudTimestamp就可以了

核心代碼如下：

原理很簡單，但是涉及到的知識點很重要，大家可以自己寫寫測試下，別總依賴別人的代碼，別人的類庫，技術實現很簡單，但需求的變體擴展有時候還是需要自己來想辦法解決的。