對于 $AppStart 和 $AppEnd 而言，歸根結底就是判斷當前 App 是處于前臺還是處于后臺。而 Android 系統本身沒有給 App 提供相關的接口來判斷這些狀態，所以我們只能借助其它方式來間接判斷。目前，業界也有很多種方法來判斷一個 App 是處于前臺還是后臺，以 Github 上的一個開源項目為例:https://github.com/wenmingvs/AndroidProcess?這個開源項目目前提供了 6 種方案:?

關于這 6 種方案詳細源碼，可以參考開源項目。 以上這 6 種方案，各有優缺點，但同時，都無法解決下面兩個問題:

? App 有多個進程如何判斷?

? App 崩潰或者被強殺了如何判斷?

原理概述

對于多進程間的數據共享問題，我們采用 ContentPro- vider 機 制 來 解 決。一 方 面 ContentProvider 是 基 于 Binder 機制封裝的系統組件，目的就是解決跨進程的數據共享問題。另一方面，Android 系統提供了針對 ContentProvider 的 數 據 回 調 監 聽 ，即 ContentOb- server，這樣就更加能滿足跨進程間的數據通信。

一般情況下，針對跨進程數據共享采用的是 ContentPro- vider + SQLite 方案，但是基于我們的實際情況，使用 SQLite 數據庫存儲一些簡單數據、標記位明顯太過重量級了。通常在 Android 系統中，針對一些比較簡單數據存儲，一般是采用 SharedPreferences 進行快速讀寫。

所以在這里我們采用的跨進程數據共享實現方式是基于 ContentProvider + SharedPreferences 的方案。對于 App 崩潰或者應用進程被強殺的場景，我們引入了 Session 的概念。即:對于一個 App，當一個頁面退出了， 如果 30s 之內沒有新的頁面打開，我們就認為 App 處于 后臺了;當一個頁面顯示了，如果與上一個頁面退出時間的間隔超過 30s，我們就認為 App 重新處于前臺了。

我們首先注冊一個 ActivityLifecycleCallbacks 回調，來監聽應用程序內所有 Activity 的生命周期。處理業務時涉及到標記位的保存以及跨進程間的數據通信，我們采用 ContentProvider + SharedPreferences 的方式實現進程間數據共享，同時注冊 ContentObserver 來監聽跨進程間的數據通信。

下面分兩種情況進行處理:

在頁面退出的時候(onPause)，我們啟動一個倒計時 30s 定時器，如果 30s 之內沒有新的頁面顯示，則觸發 $AppEnd 事件;如果有新的頁面進來，我們存儲一個標記位來標記新頁面進來。這里需要注意的是，由于 Activity 之間可能是跨進程的，所以標記位需要實現進程 間的共享，即通過 ContentProvider + SharedPreferenc- es 進行存儲。然后通過 ContentObserver 監聽到新頁面進來的標記位改變，然后取消定時器。如果 30s 之內沒有新的頁面進來(比如用戶按 Home 鍵 / 返回鍵退出 App、 App 崩潰、App 被強殺)，我們會下次啟動的時候補發一 個 $AppEnd 事件。

在下次頁面啟動的時候(onStart)，我們判斷一下與上個頁面的退出時間間隔是否超過了 30s，如果沒有超過 30s， 則無需補發 $AppEnd 事件，直接觸發 $AppScreen 事件。 接下來判斷是否已觸發 $AppEnd 事件的標記位，如果標記位為 true，則觸發 $AppStart 事件，反之不觸發;如果超過了 30s，我們判斷一下是否已經觸發了 $AppEnd 事件，如果沒有則先觸發 $AppEnd 事 件，然 后 再 觸 發 $AppStart 和 $AppScreen 事件。

實現步驟

完整的項目源碼后續會 release 給大家。

知識點

ContentProvider

注：該內容來自神策數據用戶行為洞察研究院出品的《Android 全埋點解決方案》白皮書，查看完整白皮書可點擊《Android 全埋點解決方案》

更多白皮書、報告、干貨和案例，可以關注“神策數據”和“用戶行為洞察研究院”公眾號了解~?

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的$AppStart、$AppEnd 全埋点解析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。