一、前言

Android Support v4 一直作為一個(gè)向下兼容的庫(kù)而存在，而從 23.3.0 開始，增加了一個(gè) AppLaunchChecker 的類，用于判定當(dāng)前的 App 是否被用戶從桌面啟動(dòng)過(guò)。

這樣一個(gè)功能，有點(diǎn)略顯雞肋，不過(guò)不影響我們?nèi)チ私馑?/p>

[[198025]]

二、AppLaunchChecker

1.1 存在的意義

看 Api Doc ，AppLaunchChecker 就是為了檢查當(dāng)前 App 是否被用戶啟動(dòng)過(guò)，是一個(gè)用戶行為。

***次看到這樣的解釋，可能會(huì)有歧義，如果 App 能做這樣的檢測(cè)，就說(shuō)明當(dāng)前處于運(yùn)行階段，所以很難想像這樣的一個(gè)判斷的意義在哪里。

而實(shí)際上，有一些 App ，是會(huì)提供一些其他服務(wù)給別的 App 使用的，例如最常見(jiàn)的系統(tǒng)相冊(cè)的 App ，其他 App 是可以調(diào)用它來(lái)選擇圖片的，而無(wú)需從桌面去啟動(dòng)它，但是它的代碼卻被運(yùn)行過(guò)。

AppLaunchChecker 就是為了做這種區(qū)分，標(biāo)記是否有一個(gè)以用戶行為為出發(fā)點(diǎn)，啟動(dòng)了你的 App。

1.2 它的 Api

AppLaunchChecker 的功能非常的簡(jiǎn)單，所以它的 Api 也相對(duì)簡(jiǎn)單。

它提供了一個(gè) onActivityCreate() 的方法，供啟動(dòng)的 Activity 在 onCreate() 的時(shí)候調(diào)用，主要用于檢測(cè)是否由用戶從 Launcher App 中啟動(dòng)，又提供了一個(gè) hasStartedFromLauncher() 方法來(lái)獲取檢測(cè)的結(jié)果。

這實(shí)際上也沒(méi)什么好說(shuō)的，既然這么簡(jiǎn)單，那我們進(jìn)去看看它的實(shí)現(xiàn)原理。

先來(lái)看看 onActivityCreate() 的實(shí)現(xiàn)。

可以看到，它的原理就是通過(guò)啟動(dòng) Activity 的 Intent 中的 Action 和 Category 來(lái)區(qū)分，這個(gè)看看代碼就能知道，沒(méi)什么好說(shuō)的。

它會(huì)把判斷的結(jié)果，存入 SharedPreferences 中，name 和 key 都在 AppLauncherChecker 中定義好了。

最終，需要在我們需要判斷的時(shí)候，調(diào)用 hasStartedFromLauncher() 方法即可。

2.3 需要注意什么?

既然知道 AppLaunchChecker 的判斷原理，那么它使用的時(shí)候還是有一些需要注意的。

1、需要在 App 的入口 Activity 中，調(diào)用 onActivityCreate()

因?yàn)楝F(xiàn)在大部分 App 的結(jié)果是有一個(gè) SplashActivity 來(lái)放一個(gè)啟動(dòng)圖，然后再去跳轉(zhuǎn)到 MainActivity 。所以這樣的情況下，就需要在 SplashActivity 的 onCreate() 中，調(diào)用 AppLaunchChecker.onActivityCreate() ，之后就可以在需要的地方去獲取結(jié)果了。而在 MainActivity 中去檢測(cè)的話，它的 Action 和 Category 都將是不正確的。

2、它只能判斷是否曾經(jīng)啟動(dòng)過(guò)

AppLaunchChecker.onActivityCreate() 方法，只有存儲(chǔ)狀態(tài)的，一旦存儲(chǔ)將不會(huì)去修改它，所以只要有一次是用戶啟動(dòng)的，通過(guò) hasStartedFromLauncher() 方法獲取到的值將永遠(yuǎn)是 true 。

3、它真的不準(zhǔn)

既然它是通過(guò) Action 和 Category 去做的判斷，實(shí)際上這是不嚴(yán)謹(jǐn)?shù)?。只要是個(gè) App ，通過(guò) PackageManager 去啟動(dòng)你的 App ，它的 Action 和 Category 其實(shí)都是符合這里的判斷條件的。

只要有 App 通過(guò)這樣的方式啟動(dòng)，AppLaunchChecker 就會(huì)人為是用戶行為。

看看 ApplicationPackageManager 中的實(shí)現(xiàn)，確實(shí)也是這樣的。

三、結(jié)語(yǔ)

到這里就基本上明白了 AppLaunchChecker 的原理了，有一些人覺(jué)得它的值沒(méi)有修改的時(shí)機(jī)，然后對(duì) AppLaunchChecker 進(jìn)行修改的邏輯，想在判斷的地方加個(gè) else ，修改它為 false。

現(xiàn)在看來(lái)，實(shí)際上這樣的修改完全沒(méi)有意義，通過(guò)正常走 PackageManager.getLaunchIntentForPackage() 去調(diào)起，必然會(huì)判斷是用戶啟動(dòng)的，否者也啟動(dòng)不起來(lái)。

AppLaunchChecker 現(xiàn)在看來(lái)確實(shí)挺雞肋的，它有什么使用場(chǎng)景，就只能發(fā)揮想象力了。

【本文為51CTO專欄作者“張旸”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過(guò)微信公眾號(hào)聯(lián)系作者獲取授權(quán)】

戳這里，看該作者更多好文