在一些場景中，經常會需要判斷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就可以了