一行代碼搞定 Android 復雜列表埋點曝光

一個好的產品離不開數據分析，在手機 APP 中，數據分析極致化需要細致到某個時刻列表曝光的了哪幾個 Item。

我們提供的服務有：網站建設、成都網站制作、微信公眾號開發、網站優化、網站認證、建寧ssl等。為上1000+企事業單位解決了網站和推廣的問題。提供周到的售前咨詢和貼心的售后服務，是有科學管理、有技術的建寧網站制作公司

2022 年了，基本上目前 Android 上可以滑動的復雜列表都是 RecyclerView 或者其擴展，這里分享一個封裝的思路。

如果非要細化細節：

各種方案核心都差不多，最關鍵的就是通過 LayoutManager 獲取屏幕內第一個可見和最后一個可見 item position，上報其區間內的 Item。這里簡稱這個邏輯為 檢查上報邏輯 。

但是觸發時機有所不同，通常如下方案一和二所述，當然除了方案一和方案二外，還有一些別的方案，比如監聽 RecyclerView 的布局樹變化觸發 檢查上報邏輯 等方案。

可以發現方案二相比方案一更有利于減少各種回調的注冊和周期的控制，下文會在方案二的基礎上，闡述用法和相關實現思路。

倉庫地址： RecyclerViewExposure

這里會主要說明一些主要邏輯，需要完整的邏輯可以 fork 倉庫 查看

思路來自于 lifecycle 的設計，這里主要是想讓 Activity/Fragment 提供可見和不可見的狀態變化給外部訂閱

對 List Item 的收集處理是 RecyclerViewExposure 最核心的收集數據邏輯，這里針對在 Activity 的使用作為例子。上文已經講述如何做一個 PageLifeCycleHolder 為其他組件提供頁面可見狀態，下文將直接使用。

關于數據埋點，你需要知道的技術方案和規范流程

埋點是數據采集的專用術語，在數據驅動型業務中，如營銷策略、產品迭代、業務分析、用戶畫像等，都依賴于數據提供決策支持，希望通過數據來捕捉特定的用戶行為，如按鈕點擊量、閱讀時長等統計信息。因此，數據埋點可以簡單理解為：針對特定業務場景進行數據采集和上報的技術方案。

數據埋點非常看重兩件事，一個是數據記錄的準確性，另一個則是數據記錄的完備性。

先講數據的準確性。數據埋點非常強調規范和流程，因為參數的規范與合法，將直接影響到數據分析的準確性，如果準確性得不到保障，那么所有基于埋點得出的結論，都是不可信的。辛辛苦苦做了很久的方案，一旦因為一個疏忽的小問題，導致下游集中投訴，其實非常劃不來。

道理每個人都懂，但現實情況中，數據埋點所面對的客觀環境，其實非常復雜，例如：

因此本文有非常長的篇幅來寫流程問題，其實是非常有必要的。

再講數據的完備性。因為埋點主要是面向分析使用，對用戶而言是個額外的功能，因此埋點的業務侵入性很強，很容易對用戶體驗造成影響。別的不說，僅僅是流量的消耗，就很容被用戶噴。因此，要提前想清楚，我們要采集哪些東西，因為修改方案的成本，是傷不起的。

通常情況下，我們需要記錄用戶在使用產品過程中的操作行為，通過4W1H模型可以比較好的保障信息是完備的。4W1H包括：

規定好記錄信息的基本方法之后，按照固定的頻率，如每小時、每天，或者是固定的數量，比如多少條日志，或者是網絡環境，比如在Wifi下上傳，我們就可以開心的把埋點數據用起來了。

當然，數據記錄的時效性也比較重要，但因為埋點數據通常量級會比較大，且各個端數據回傳的時間不同，因此想做到實時統計，還是需要分場景來展開。在Flink技術日漸成熟的今天，全鏈路的實時采集與統計，已經不是什么難題。

在埋點的技術方案中，首先要重視的，是用戶唯一標識的建設。如果做不到對用戶的唯一識別，那么基礎的UV統計，都將是錯誤的。

因此，在數據埋點方案中，有兩個信息是一定要記錄的，即設備ID+用戶ID。設備ID代表用戶使用哪個設備，如安卓的ANDROID_ID/IMEI，IOS中的IDFA/UDID，瀏覽器的Cookie，小程序的OpenID等。用戶ID，代表用戶在產品中所注冊的賬號，通常是手機號，也可以是郵箱等其他格式。

當這兩個信息能夠獲得時，不論是用戶更換設備，或者是同一臺設備不同賬號登錄，我們都能夠根據這兩個ID，來識別出誰在對設備做操作。

其次，我們來看一下Web的數據采集技術。Web端數據采集主要通過三種方式實現：服務器日志、URL解析及JS回傳。

瀏覽器的日志采集種類又可以分為兩大類：頁面瀏覽日志和頁面交互日志。

除此之外，還有一些針對特定場合統計的日志，例如頁面曝光時長日志、用戶在線操作監控等，但原理都基于上述兩類日志，只是在統計上有所區分。

再次，我們來看下客戶端的數據采集。與網頁日志對應的，是手機應用為基礎的客戶端日志，由于早期手機網絡通訊能力較差，因而SDK往往采用延遲發送日志的方式，也就是先將日志統計在本地，然后選擇在Wifi環境下上傳，因而往往會出現統計數據延遲的情況。現如今網絡環境好了很多，4G、5G流量充足，尤其是視頻類APP基本上都是一直聯網，因而很多統計能夠做到實時統計。

客戶端的日志統計主要通過SDK來完成，根據不同的用戶行為分成不同的事件，“事件”是客戶端日志行為的最小單位，根據類型的不同，可以分為頁面事件（類比頁面瀏覽）和控件點擊事件（類比頁面交互）。對于頁面事件，不同的SDK有不同的方式，主要區別為是在頁面創建時發送日志，還是在頁面瀏覽結束后發送日志，區別在于業務統計是否需要采集用戶的頁面停留時長。

頁面事件的統計主要統計如下三類信息：

埋點其實還需要考慮數據上傳的方案，批量的數據可以通過Flume直接上報，流式的可以寫到Kafka，或者直接使用Flink來處理。這些框架相關的內容不是本文考慮的重點，有興趣的可以自行查閱資料。

有了指導思路和技術方案后，我們就可以著手制定相應的數據埋點流程規范了。

籠統上，流程規范會分成五個步驟，即需求評審、埋點申請、技術開發、埋點驗證、發布上線。

第一步，需求評審。

前文提到過，數據埋點的方案一旦確定，返工和排查問題的成本都很高，但數據埋點之后的分析工作，又涉及到了PD、BI、算法、數據等多個角色。因此非常有必要，將需求內容和數據口徑統一收口，所有人在一套口徑下，將需求定義出來，隨后業務側再介入，進行埋點方案的設計和開發。

以前文提到的4W1H模型為例，常見的記錄內容如下：

最后我們統計時，按照上述約定，統計用戶在某個時間和地點中，看到了哪些信息，并完成了怎樣的動作。上下游的相關人員，在使用這份數據時，產生的歧義或者是分歧，會小很多。

第二步，埋點申請

當下的熱門應用，大多是以超級APP的形式出現，比如微信、淘寶、支付寶、抖音，超級APP會承載非常多的業務，因此技術方案上會十分統一。

因此，當我們的技術方案確定后，通常要在相應的埋點平臺上，進行埋點申請。申請的內容包括分配的SPM、SCM碼是什么，涉及到的平臺是哪些，等等。SPM、SCM是什么，有什么用，同樣可以自行查閱。

第三步，技術開發

當需求確定、申請通過后，我們就可以開始開發動作了，這里基本上是對研發同學進行約束。埋點的開發，簡單講，是分成行為埋點和事件埋點兩個大類，每一類根據端的不同進行相應的開發。具體的技術方案詳見前文01章節。

詳細的設計規范，是需要留文檔的，因為代碼不能反應業務的真實意圖，而不論是事后復盤與業務交接，都需要完整的文檔來闡述設計思路。

第四步，埋點驗證

埋點的驗證很關鍵，如果上線后才發現問題，那么 歷史 數據是無法追溯的。

驗證有兩種方式，一種是實時的功能驗證，一種是離線的日志驗證。

實時功能驗證，指功能開發好后，在灰度環境上測試相應的埋點功能是否正常，比如點擊相應的業務模塊，日志是否會正確的打印出來。通常而言，我們需要驗證如下三個類型的問題：

除去實時驗證，我們也需要把日志寫到測試環境中，查看數據上報的過程是否正確，以及對上報后的數據進行統計，側面驗證記錄的準確性，如統計基本的PV、UV，行為、事件的發生數量。

很多時候，數據是需要多方驗證的，存在一定的上下游信息不同步問題，比如對某個默認值的定義有歧義，日志統計會有效的發現這類問題。

第五步，發布上線。

應用的發布上線通常會有不同的周期，例如移動端會有統一的發版時間，而網頁版只需要根據自己的節奏走，因此數據開始統計的時間是不同的。最后，應用應當對所有已發布的埋點數據，有統一的管理方法。

大多數時候，數據埋點的技術方案，只需要設計一次，但數據準確性的驗證，卻需要隨著產品的生命周期持續下去，因此僅僅依靠人肉來準確性驗證是不夠的，我們需要平臺來支持自動化的工作。埋點的準確性，大體有兩種方法保障：一種是灰度環境下驗證真實用戶數據的準確性；另一種則是在線上環境中，驗證全量數據的準確性。因此，發布上線之后，后續的管理動作，應該是對現有流程的自動化管理，因為團隊大了，需要埋點的東西多種多樣，讓平臺自己測試、自動化測試，就是很多測試團隊必須走的路

數據埋點技巧

移動互聯網時代，無論是Android、iOS還是小程序，都有很多成熟的解決方案，無需花費很多的時間去處理埋點的事情，而且基于第三方提供的SDK進行埋點，在數據處理和分析上也有很大的優勢。

但是在之前的PC互聯網時代，除了網頁端有百度統計、谷歌分析等，客戶端的埋點似乎沒有一套能拿出來可供大家討論的解決方案，我就基于我的工作經驗和理解，給大家分享一下PC客戶端的埋點。

PC客戶端的埋點

首先，在PC上，我們得知道我們需要統計些什么內容。

一個PC客戶端，無論是工具類的還是內容類的，我們都希望知道我們提供的服務的效果。那么，我們從一個客戶端安裝、運行到最終被卸載來看看。

就拿產品使用較多的工具“Axure RP”來舉例吧。如果“Axure RP”是我們自己的軟件，首先我們需要知道被安裝了，之后，我們關注激活情況，也就是使用，到最后，被卸載了，這一整個環節，構成了一個生命周期。 重點來了，對于這個生命周期，所有你想知道的關于“Axure RP”的情況你都可以統計到。

1.軟件的安裝

在PC客戶端安裝的過程中，流程一般是這樣的：①運行安裝包②彈出安裝界面提供給用戶操作③執行安裝過程-寫注冊表、啟動項、計劃任務等④執行安裝過程-創建安裝的文件夾（③和④可以交換）。

在這個環節，我們一般需要知道：

安裝包被運行了

在安裝界面用戶做了哪些操作

我們的安裝過程是否正常執行

我們最終是否安裝成功

在PC上，只要我們的安裝包運行起來了，無論是彈出安裝界面、寫注冊表還是創建文件，這些都是安裝包可以控制的，所以我們能通過安裝包進程，將整個安裝環節的所有數據記錄下來發送到我們的后臺并記錄下來 （這里要重點記住，由于安裝是一次性的動作，所以統計一定要發實時的） 。

2.軟件的使用

軟件的使用，包括啟動軟件、使用功能和退出軟件。

在PC上，軟件的啟動有很多種方式，例如開機自啟動、計劃任務、手動點擊快捷方式，我們繼續以“Axure RP”舉例，當我們裝上了“Axure RP”后，會在桌面、開始菜單中，創建快捷方式（有些程序會在任務欄上也創建），同時，會將后綴名為“rp”的文件默認打開方式調整為“Axure RP”。

對于啟動， 我們就有了三種方式：桌面快捷方式、開始菜單快捷方式和默認軟件打開，所以我們需要統計軟件是否被啟動了，是如何啟動的。

對于使用功能， 當軟件運行起來后，其進程就會啟動，這個時候就跟移動端的應用類似，我們需要統計一系列事件，每個功能的使用情況、功能狀態、付費、登錄等一系列信息（區別于移動端的是，在PC上一般這些統計都是做單點統計，例如統計彈窗的彈出、功能的點擊、某個狀態，對于相互關聯的一組事件統計是比較復雜的，需要定義結構體，在一條統計中包含很多組字段信息，因為沒有成熟的SDK集成，所以基本都要自己定義埋點，復用性較差）。

這部分統計分為公共統計和專用統計。公共統計就是基本信息，常用的是用戶標識、用戶基本信息、計算機硬件信息和其他的可復用的；專用統計就是針對你的功能，你想了解哪些情況，針對性進行埋點統計。

對于軟件退出， 這就比較簡單了，是正常退出還是異常退出？軟件使用了多久退出？

3.軟件的卸載

軟件卸載的流程包括啟動卸載程序、用戶操作、刪除注冊表及文件等操作、完成卸載。

在這個過程中，我們主要關注兩方面的信息，一方面是用戶怎么卸載的？是主動使用卸載程序，還是通過一些管理軟件進行卸載；另一方面是用戶為什么要卸載，這個時候我們可以在卸載的界面中給用戶提供選擇，以獲取用戶的反饋。

該怎么埋點

1.埋點的分類

（1）時效性

PC客戶端一般情況下都比較復雜，子功能很多，可統計的內容很多，為了節省帶寬，我們不可能每次都實時將數據傳輸回來，而且很多時效性不是很強的功能沒有必要實時上報。

實時統計

當功能觸發時或達到一定條件，立即將統計回傳，一般情況下用于時效性比較強的功能，例如活躍統計、營收類統計，我們需要實時分析并調整策略。

延時統計

統計不立即回傳，將統計積累，達到一定的條件或者一定的時間，統一將這部分統計回傳，一般情況用于時效性不強的功能，例如采集設備信息、獲取某些功能的狀態、常規功能的統計，這部分統計使用范圍比較廣，一般都是隔日發送，有一天的延遲，統計的信息晚一天不會對分析產生較大的影響。

（2）埋點的作用

常規的基礎統計

每次統計都需要發送，可以理解為公用統計，這部分統計是將幾乎所有的統計都需要的部分包括進來，封裝成一個統一的部分，每次發送統計都會帶上這些內容，方便管理，節省后續埋點時間。

功能統計

針對特定功能，當功能被使用或者生效的時候，我們需要統計效果或者狀態，可以理解為專用統計，不同于移動端，PC一般沒有第三方提供的SDK，需要每個專用統計自己埋點，維護大量的統計內容，不過在一個公司內部，可以統一設計規范，方便維護。

（3）數據類型

結構體

統計連貫的事件，各項信息之間的關聯很重要。

計數

統計某個行為發生的次數。

字符串

統計內容。

整形

統計數值，也可用來統計狀態。

布爾型

統計需要判斷的類型，一般使用場景較少，為了方便計算，大部分被整形和字符串替代。

2.數據埋點實例

（1）軟件安裝

場景：統計安裝過程中的信息

（2）軟件的使用

場景：軟件啟動后，用戶使用了分享功能，將自己做的原型分享到了云端，最后用戶關閉了軟件。

要注意的是，軟件啟動和關閉，看需要是可以調整的，如果你只是想知道是不是啟動了，來判斷活躍，那么僅僅需要啟動的時候發送個整型的值標識即可；如果想知道更詳細的信息，比如啟動方式、啟動時間等等，可以定義結構體，將這一刻更多的信息發送回來，可靈活定義。

（3）軟件卸載

卸載跟軟件安裝類似，這里就不贅述了。

在這里，如果希望收集用戶的卸載原因，可以定義一個字符串，將用戶填寫的內容上報，這種形式的數據如果太多，不太利于分析，所以看產品情況可靈活設置。

Android性能優化第（八）篇---App啟動速度優化之耗時檢測處理

應用的啟動速度緩慢這是很多開發者都遇到的一個問題，比如啟動緩慢導致的黑屏，白屏問題，大部分的答案都是做一個透明的主題，或者是做一個Splash界面，但是這并沒有從根本上解決這個問題。那么如何從根本上解決這個問題或者做到一定程度的緩解？

1、冷啟動：當啟動應用時，后臺沒有該應用的進程，這時系統會首先會創建一個新的進程分配給該應用，這種啟動方式就是冷啟動。

2、熱啟動：當啟動應用時，后臺已有該應用的進程，比如按下home鍵，這種在已有進程的情況下，這種啟動會從已有的進程中來啟動應用，這種啟動方式叫熱啟動。

3、溫啟動 ：當啟動應用時，后臺已有該應用的進程，但是啟動的入口Activity被干掉了，比如按了back鍵，應用雖然退出了，但是該應用的進程是依然會保留在后臺，這種啟動方式叫溫啟動。

adb shell am start -W [PackageName]/[PackageName.MainActivity]

執行成功后將返回三個測量到的時間：

這里面涉及到三個時間，ThisTime、TotalTime 和 WaitTime。WaitTime 是 startActivityAndWait 這個方法的調用耗時，ThisTime 是指調用過程中最后一個 Activity 啟動時間到這個 Activity 的 startActivityAndWait 調用結束。TotalTime 是指調用過程中第一個 Activity 的啟動時間到最后一個 Activity 的 startActivityAndWait 結束。如果過程中只有一個 Activity ，則 TotalTime 等于 ThisTime。

總結:如果只關心某個應用自身啟動耗時，參考TotalTime；如果關心系統啟動應用耗時，參考WaitTime；如果關心應用有界面Activity啟動耗時，參考ThisTime。

從我們Application開始到首頁顯示出來，這個過程，我們應該注意一些什么，將這個過程細分一下，會有下面的時間點需要注意。

Application的構造器方法——attachBaseContext()——onCreate()——Activity的構造方法——onCreate()——配置主題中背景等屬性——onStart()——onResume()——測量、布局、繪制顯示在界面上。

因為上面這些階段全部都是在主線程中執行的，任何不經意的操作都可能拖慢應用的啟動速度。所以我們不應在Application以及Activity的生命周期回調中做任何費時操作，具體指標大概是你在onCreate，onResume，onStart等回調中所花費的總時間最好不要超過400ms，否則用戶在桌面點擊你的應用圖標后，將感覺到明顯的卡頓。但是有些 不得以的任務 又必須在UI顯示之前執行。所以我們要將 任務 劃分優先級。

對于首頁渲染完成后，開始加載，或者延遲加載，延遲加載的目的就是界面先顯示出來，然后加載，但是你覺得要延遲多久呢？在 Android 的高端機型上,應用的啟動是非常快的 , 這時候只需要 Delay 很短的時間就可以了, 但是在低端機型上,應用的啟動就沒有那么快了,而且現在應用為了兼容舊的機型,往往需要 Delay 較長的時間,這樣帶來體驗上的差異是很明顯的。延遲加載有一種方式。

極力推薦用第二種，在窗口完成以后進行加載，這里面的run方法是在onResume之后運行的。關于這種懶加載機制，參考 Android應用啟動優化:一種DelayLoad的實現和原理(上篇) ，給出了詳細的解釋。

通過上面我們知道一種懶加載機制，所以我們可以將Application中和首頁的onCreate中的有些耗時任務，放到首頁渲染完畢后加載。如何找出這些耗時任務，TraceView就派上用場了，TraceView的用法，移步我的前面的博客 Android性能優化第（六）篇---TraceView 分析圖怎么看？

比如在首頁的onCreate中我們進行了用戶啟動上報，這個進行懶加載是不是分分鐘減少139毫秒呢？

在比如在Application里面用到了GSON，將String轉化成json,我將這個移動到懶加載里面，是不是又減少了100毫秒呢？

在比如，有些Application中做了支付SDK的初始化，用戶又不會一打開App就要支付，放在Application中加載干嘛？

此處我們這里舉得例子是優化了139毫秒和100毫秒的，其實真正耗時的任務有的有1秒多，都被我優化完了，所以trace圖中看不到了，就舉個了這兩個例子，還有SharedPreferences也是耗時大戶，經過檢測保存一個boolean變量耗時120+毫秒以上。

利用TraceView可以清楚我們每一個方法的耗時時間，極大的幫助了我們做優化工作。

五、優化思路總結

1、UI渲染優化，去除重復繪制，減少UI重復繪制時間，打開設置中的GPU過度繪制開關，各界面過度繪制不應超過2.5x；也就是打開此調試開關后，界面整體呈現淺色，特別復雜的界面，紅色區域也不應該超過全屏幕的四分之一；

2、根據優先級的劃分，KoMobileApplication的一些初始化工作能否將任務優先級劃分成3,在首頁渲染完成后進行加載，比如：PaySDKManager。

3、主線程中的所有SharedPreference能否在非UI線程中進行，SharedPreferences的apply函數需要注意，因為Commit函數會阻塞IO，這個函數雖然執行很快，但是系統會有另外一個線程來負責寫操作，當apply頻率高的時候，該線程就會比較占用CPU資源。類似的還有統計埋點等，在主線程埋點但異步線程提交，頻率高的情況也會出現這樣的問題。

4、檢查BaseActivity,不恰當的操作會影響所有子Activity的啟動。

5、對于首次啟動的黑屏問題，對于“黑屏”是否可以設計一個.9圖片替換掉，間接減少用戶等待時間。

6、對于網絡錯誤界面，友好提示界面，使用ViewStub的方式，減少UI一次性繪制的壓力。

7、任務優先級為2，3的，通過下面這種方式進行懶加載的方式

8、Multidex的使用，也是拖慢啟動速度的元兇，必須要做優化。后面有空專門寫一篇Multidex。

相關鏈接：

Android應用啟動優化:一種DelayLoad的實現和原理(上篇)

Android性能優化之加快應用啟動速度

手機淘寶性能優化全記錄

Android客戶端性能優化（魅族資深工程師毫無保留奉獻）

Please accept mybest wishes for your happiness and success !

分享題目：android埋點,安卓埋點怎么設計
網頁URL：http://vcdvsql.cn/article28/dsdisjp.html

成都網站建設公司_創新互聯，為您提供建站公司、企業網站制作、外貿網站建設、手機網站建設、網站營銷、網頁設計公司

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯