西瓜客户端埋点实践：基于责任链的埋点框架
埋點的背景
目前互聯(lián)網(wǎng)/軟件行業(yè)內(nèi)，廣泛使用數(shù)據(jù)驅(qū)動產(chǎn)品迭代，通過精細的數(shù)據(jù)分析、模型訓(xùn)練為用戶提供更好的服務(wù)。在此過程中，數(shù)據(jù)埋點的工作是后續(xù)數(shù)據(jù)分析、模型訓(xùn)練等工作的基礎(chǔ)。
數(shù)據(jù)埋點通常是產(chǎn)品經(jīng)理、數(shù)據(jù)分析師，以及推薦系統(tǒng)工程師，基于業(yè)務(wù)需求（例如：廣告的下載安裝轉(zhuǎn)化），產(chǎn)品需求（例如：關(guān)注按鈕的曝光次數(shù)以及點擊的人數(shù)）對用戶行為的每一個事件確定埋點需求。客戶端工程師進行對應(yīng)的埋點功能開發(fā)，通過 SDK 上報埋點的數(shù)據(jù)結(jié)果，后端記錄數(shù)據(jù)進行一系列處理，并匯總后提供給產(chǎn)品經(jīng)理、數(shù)據(jù)分析師，以及推薦系統(tǒng)工程師進行數(shù)據(jù)分析或模型訓(xùn)練，幫助優(yōu)化產(chǎn)品運營策略。
經(jīng)典的消費場景
下面有幾種經(jīng)典的數(shù)據(jù)消費場景：
我們可以看到，行為分析埋點，需要包括某一事件發(fā)生時的前因、后果，以及事件發(fā)生對象的特征。在復(fù)雜的數(shù)據(jù)分析、模型訓(xùn)練等需求中，不僅僅需要獲知某個事件的發(fā)生次數(shù)，對埋點上下文尤為關(guān)注。此處上下文指的通常有 2 類，分別是：
事件發(fā)生的頁面信息和頁面位置信息
用戶經(jīng)過怎樣的路徑來到當前頁面，也就是“來源”信息
經(jīng)典的埋點需求
下面我們結(jié)合具體場景，看 1 個簡單的埋點需求，“點擊收藏”事件
上面左圖是西瓜放映廳的推薦列表，右圖是某個影片的詳情頁，點擊推薦列表的影片卡片，會跳轉(zhuǎn)到詳情頁。作為最常見的消費場景，列表和詳情都有收藏按鈕，我們希望知道每一個收藏事件發(fā)生的場景，方便后續(xù)優(yōu)化收藏功能，以及結(jié)合用戶收藏的情況，優(yōu)化推薦模型。
埋點需求是上報收藏按鈕的點擊事件 click_favorite，要求包含收藏影片的信息，所在的場景信息等。
如果收藏事件發(fā)生在列表頁，會上報如下的內(nèi)容
如果收藏事件發(fā)生在詳情頁，會上報如下的內(nèi)容
現(xiàn)有方案
前端用戶交互的界面，通常有復(fù)雜的頁面層級關(guān)系和跳轉(zhuǎn)邏輯，為了準確記錄埋點信息，滿足上述埋點需求，主要有以下幾種實現(xiàn)方案。
直接傳參
通過平臺支持的參數(shù)傳遞方式，逐個定義并且讀寫參數(shù)；或者基于面向?qū)ο蟪绦蛟O(shè)計，對每個類添加相應(yīng)的埋點參數(shù)，在類對象的關(guān)系中進行埋點參數(shù)傳遞。
對于上面的埋點需求 click_favorite，我們假設(shè)列表頁和詳情頁的層級結(jié)構(gòu)是：
列表頁：CinemaTabFragment（放映廳 Tab）=> VideoChannelFragment（頻道）=> VideoViewHolder（卡片）
詳情頁：VideoDetailActivity（詳情頁 Activity） -> BottomActionBar（底部操作欄）
當然實際情況因為項目的組件抽象復(fù)用等原因，往往會有更復(fù)雜的層級。直接傳參要怎么實現(xiàn)這個埋點需求呢：
列表頁的 click_favorite 埋點，需要從底 Tab 把所在 Tab 信息傳給頻道，頻道再把底 Tab 和頻道信息傳給卡片
詳情頁的 click_favorite 埋點，首先需要在列表頁點擊卡片跳轉(zhuǎn)的時候，把上下文信息通過跳轉(zhuǎn)參數(shù)傳遞給詳情頁，然后詳情頁解析出參數(shù)，傳給底部操作欄
這里是簡化過的偽代碼，即便是這樣，依然可以看出直接傳參有非常顯著的缺陷：
每增加一個參數(shù)，都需要寫大量的重復(fù)代碼，工程代碼膨脹
模塊間約定了很多埋點參數(shù)的協(xié)議，耦合程度高，難以維護
一些場景的嵌套層次深，經(jīng)過很多層的參數(shù)傳遞，非常容易漏報埋點參數(shù)
單例傳參
上述問題有一種輕微緩解的辦法，使用單例來進行埋點參數(shù)的訪問。通過一個單例進行埋點參數(shù)的維護，由于單例提供了全局唯一訪問入口，程序中的任何位置都能方便地讀和寫埋點參數(shù)。這種方式帶來的好處是不需要在每個類都定義大量的埋點參數(shù)，只需要訪問單例進行修改和讀取。
以詳情頁的 click_favorite 埋點舉例，可以通過跳轉(zhuǎn)前把值寫入單例，上報埋點時直接從單例獲取，而無須再從詳情頁 Activity 傳值給底部操作欄。
object?VideoDetailTracker?{var?fromTabNamevar?fromChannelNamevar?fromPagevar?videoInfo }class?VideoViewHolder?{var?tabNamevar?channelNamevar?videoInfofun?clickJumpDetail()?{//?把上下文信息先存到單例VideoDetailTracker.fromTabName?=?this.tabNameVideoDetailTracker.fromChannelName?=?this.channelNameVideoDetailTracker.fromPage?=?"feed"VideoDetailTracker.videoInfo?=?this.videoInfostartActivity(intent)} }class?VideoDetailActivity?{fun?onCreate()?{//?詳情頁不需要再解析埋點參數(shù)，也不需要再傳遞給BottomActionBar//?只需有正常的功能代碼val?videoId?=?intent.getString("video_id")videoInfo?=?loadVideoInfo(videoId)} }class?BottomActionBar?{fun?clickFavorite()?{//?上報埋點的時候，直接從單例取出來拼接參數(shù)LogSdk.onEvent("click_favorite",?mapOf("from_tab_name"?to?VideoDetailTracker.fromTabName,"from_channel_name"?to?VideoDetailTracker.fromChannelName,"from_page"?to?VideoDetailTracker.fromPage,"video_id"?to?VideoDetailTracker.videoInfo.id,"video_type"?to?VideoDetailTracker.videoInfo.type,"page_name"?to?"detail"))} }可以看出來，從列表頁 => 詳情頁以后，在詳情頁上報埋點，獲取頁面來源信息，確實比之前更簡單了。但仔細想想，這種方案治標不治本，同樣有明顯的弊端：
首先，無法解決列表頁這種多實例場景的問題，比如一個推薦列表中有多個卡片，每個卡片的埋點參數(shù)都不一樣，卡片的埋點參數(shù)還是需要自己傳
單例的數(shù)據(jù)可能被多個位置寫入，且一旦被覆蓋就沒法恢復(fù)，比如這樣的路徑：列表 -> 詳情頁 1 -> 相關(guān)推薦 -> 詳情頁 2，進到詳情頁 2 以后，單例的數(shù)據(jù)被覆蓋了，這時候再回到詳情頁 1，獲取到的埋點參數(shù)實際是詳情頁 2 的，導(dǎo)致埋點參數(shù)上報錯誤。
存放和清理的時機難以控制，清理早了會導(dǎo)致埋點參數(shù)缺失，忘記清理可能導(dǎo)致后面的埋點獲取不到參數(shù)
無埋點
無埋點是業(yè)界流行的一種埋點方案，所謂的“無埋點”、“全埋點”，是指埋點 SDK 通過編譯時插樁、運行時反射或動態(tài)代理的方式，自動進行埋點事件的觸發(fā)和上報，無須客戶端工程師手動進行埋點開發(fā)工作。由產(chǎn)品經(jīng)理、數(shù)據(jù)分析師等在埋點管理后臺，使用 XPath 路徑、頁面視圖 id 或者文本匹配等技術(shù)，定位到頁面視圖的位置，過濾出所需的數(shù)據(jù)。
此方案的優(yōu)勢很明顯，客戶端只需要一次性的接入，理論上能夠搜集到所有頁面、視圖的曝光、點擊等事件，無需客戶端同學(xué)進行后續(xù)的埋點需求開發(fā)。
有這么好的事？為什么字節(jié)沒有廣泛使用？此方案的缺陷在于：
僅能上報有限的簡單事件類型，如頁面視圖曝光、點擊等，無法完成復(fù)雜事件的上報，如一次支付行為的操作路徑、結(jié)果、錯誤信息等
無法自定義參數(shù)，主要指跳轉(zhuǎn)的來源、所處的場景等上下文信息，無法滿足復(fù)雜的數(shù)據(jù)分析和推薦模型所需的數(shù)據(jù)要求
由產(chǎn)品經(jīng)理、數(shù)據(jù)分析師等在埋點管理后臺進行的事件錄入，把復(fù)雜度從開發(fā)轉(zhuǎn)嫁給了產(chǎn)品，消費成本較高
對頁面視圖的穩(wěn)定性有很高的要求，需要約定 id、文本、視圖的層級，保持頁面結(jié)構(gòu)不變，如果客戶端工程師因為一些新需求開發(fā)、性能優(yōu)化等調(diào)整了視圖結(jié)構(gòu)，將會導(dǎo)致已錄入的埋點失效，增加了額外的維護成本
全場景的數(shù)據(jù)上報，可能產(chǎn)生大量的無用數(shù)據(jù)，消耗大量傳輸、存儲、計算資源
基于責任鏈的埋點框架
下面介紹下我們正在使用的埋點框架，是怎么解決埋點傳參困難、代碼冗余的問題，簡化埋點開發(fā)復(fù)雜度的。
分析問題
回顧下剛剛的埋點需求，上報 click_favorite 埋點，復(fù)雜度在于上報埋點的對象（列表卡片、詳情頁底部操作欄），為了埋點需要從其他對象（頻道、底 Tab、前面的頁面）獲取埋點參數(shù)。
卡片需要關(guān)注自己所在的底 Tab、頻道，詳情頁需要關(guān)注自己的來源頁面，這顯然違反了“關(guān)注點分離”的原則。如果我們讓每個對象僅關(guān)注自己的信息，是否可行？
埋點與視圖層級的關(guān)系
我們回想下列表頁的視圖層級
是不是會發(fā)現(xiàn)所需的埋點參數(shù)恰好就分布在視圖樹的責任鏈中？
沒錯，聰明的你已經(jīng)想到了，我們在收藏按鈕被點擊時，只需要從收藏按鈕的節(jié)點按照卡片 -> 推薦頻道 -> 放映廳Tab的順序向上找，就能夠拿到所有需要的參數(shù)了。既然這個上下級關(guān)系（責任鏈）已經(jīng)客觀存在，我們?yōu)槭裁催€需要層層透傳埋點，直接利用這個關(guān)系不就好了嗎？
埋點與頁面跳轉(zhuǎn)鏈路的關(guān)系
來源類埋點參數(shù)定義，常見的有 from_page、click_position 等，需要在跳轉(zhuǎn)的過程中，從前序頁面，傳遞到后序頁面，同時會有些映射規(guī)則，比如前序頁面的 page_name 到了后序頁面，上報 from_page。
那么頁面的跳轉(zhuǎn)鏈路是什么樣的呢？我們回想下，跳轉(zhuǎn)到詳情頁，有很多種路徑，比如下面的 2 種：
上面是直接從推薦列表頁進詳情頁：推薦列表 => 詳情頁
下面是從推薦列表頁，點擊標簽進入選集頁，再從選集頁進入詳情頁：推薦列表 => 選集 => 詳情頁
可以看出頁面的跳轉(zhuǎn)鏈路，邏輯上也是一個樹狀結(jié)構(gòu)。如果我們結(jié)合前面說到的頁面內(nèi)視圖層級，把兩個樹放在一起，會是下面的樣子：
是不是發(fā)現(xiàn)，我們需要的埋點上下文參數(shù)，理論上都可以通過節(jié)點的關(guān)系找到？
解決問題
有了前面的討論，我們來看一下怎么把這個問題，抽象成一個框架。
1. ITrackModel
ITrackModel 很簡單，這個接口定義了能夠填充埋點參數(shù)的對象，只要實現(xiàn)了這個接口，就可以在埋點上報的時候添加參數(shù)
interface?ITrackModel?{fun?fillTrackParams(trackParams:?TrackParams) }2. ITrackNode
ITrackModel 只是定義了填充參數(shù)的職責，ITrackModel 對象之間并沒有關(guān)聯(lián)，怎么找到所有的 ITrackModel，讓它們填充自己的埋點參數(shù)呢？在此基礎(chǔ)上，我們定義了 ITrackNode 接口
interface?ITrackNode:?ITrackModel?{fun?parentTrackNode():?ITrackNode?fun?referrerTrackNode():?ITrackNode? }ITrackModel 繼承了 ITrackModel，除了有填充埋點參數(shù)的能力外，還會指向父節(jié)點和來源節(jié)點。
parentTrackNode：指向父節(jié)點，通過它可以建立一個頁面內(nèi)的責任鏈，在一個頁面內(nèi)，根節(jié)點通常是頁面的頂層容器，例如 Android 的 Activity
referrerTrackNode：指向來源節(jié)點，通過它可以建立用戶跳轉(zhuǎn)的邏輯鏈路，在用戶使用 App 的一個會話中，來源鏈路根節(jié)點通常指啟動頁面（也可以由 Push、DeepLink 的啟動參數(shù)構(gòu)造虛擬的 referrer 節(jié)點）
3. 建立頁面上下級責任鏈
定義了 ITrackModel 和 ITrackNode，接下來就是實現(xiàn)每個節(jié)點，并且將這些節(jié)點連起來。
最通用的方式，是直接實現(xiàn) ITrackNode，例如在列表場景中，我們可以建立 ViewHolder -> Adapter -> Fragment 的責任鏈
//?放映廳Tab class?CinemaTabFragment:?ITrackNode?{override?fun?parentTrackNode():?ITrackNode?{return?activity?as?ITrackNode}override?fun?fillTrackParams(trackParams:?TrackParams)?{trackParams.putIfNull("tab_name",?"long_video")} }//?頻道Fragment class?VideoChannelFragment:?ITrackNode?{override?fun?parentTrackNode():?ITrackNode?{return?parentFragment?as?ITrackNode}override?fun?fillTrackParams(trackParams:?TrackParams)?{trackParams.putIfNull("channel_name",?"lvideo_recommend")trackParams.putIfNull("page_name",?"feed")} }//?列表Adapter，這一層沒有參數(shù)，只是作為中間節(jié)點，連接卡片ViewHolder和頻道Fragment class?VideoChannelAdapter(private?val?parent:?ITrackNode):?ITrackNode?{override?fun?parentTrackNode():?ITrackNode?{return?fragment?as?ITrackNode} }//?卡片ViewHolder class?VideoViewHolder(private?val?parent:?ITrackNode,?val?view:?View)?:?ITrackNode?{var?videoInfooverride?fun?parentTrackNode():?ITrackNode?{return?parentFragment?as?ITrackNode}override?fun?fillTrackParams(trackParams:?TrackParams)?{trackParams.putIfNull("video_id",?videoInfo.id)trackParams.putIfNull("video_type",?videoInfo.type)}fun?clickFavorite()?{//?使用ITrackNode.onEvent上報埋點，會從當前節(jié)點開始向上收集埋點參數(shù)this.onEvent("click_favorite")} }這樣，我們就建立起了列表頁的上下級責任鏈，我們可以看到埋點參數(shù)都在對應(yīng)的節(jié)點添加了，而不需要再從上級層層傳入，上報埋點的代碼變得非常簡單。
直接實現(xiàn) ITrackNode 的方式，特別適合 Fragment、Adapter、ViewHolder 等需要我們自定義的類，他們在視圖構(gòu)建中的作用是將視圖拆分層級，更好的管理局部的視圖、數(shù)據(jù)和邏輯。然而，我們發(fā)現(xiàn)這種方式需要實現(xiàn)每一個節(jié)點，并且手動建立節(jié)點之間的聯(lián)系，使用起來還是挺麻煩的。
大部分情況下，我們發(fā)現(xiàn)上下級責任鏈的關(guān)系，和視圖層級的關(guān)系是一致的，而系統(tǒng)已經(jīng)為我們建立了視圖樹 ViewTree，那么我們可以利用 ViewTree，來建立上下級責任鏈。其中 ViewTree 上的每一個 View，只需要實現(xiàn) ITrackModel 的能力，就可以負責填充埋點參數(shù)。
我們利用 View.setTag 可以存放任意對象的特性，為 View 增加了擴展屬性
/***?設(shè)置View的TrackModel*/ var?View.trackModel:?ITrackModel?get()?=?this.getTag(TAG_ID_TRACK_MODEL)?as??ITrackModelset(value)?{this.setTag(TAG_ID_TRACK_MODEL,?value)}上面的例子，可以換一種實現(xiàn)方式：
//?放映廳Tab class?CinemaTabFragment:?ITrackModel?{override?fun?fillTrackParams(trackParams:?TrackParams)?{trackParams.putIfNull("tab_name",?"long_video")}override?fun?onViewCreated(view:?View)?{//?放映廳Tab根視圖，ITrackModel由Fragment實現(xiàn)view.trackModel?=?this} }//?頻道Fragment class?VideoChannelFragment:?ITrackModel?{override?fun?fillTrackParams(trackParams:?TrackParams)?{trackParams.putIfNull("channel_name",?"lvideo_recommend")trackParams.putIfNull("page_name",?"feed")}override?fun?onViewCreated(view:?View)?{//?頻道根視圖，ITrackModel由Fragment實現(xiàn)view.trackModel?=?this} }//?卡片ViewHolder class?VideoViewHolder(val?view:?View)?:?ITrackModel?{var?videoInfofun?bind(videoInfo:?VideoInfo)?{this.videoInfo?=?videoInfothis.itemView.trackModel?=?this}override?fun?fillTrackParams(trackParams:?TrackParams)?{trackParams.putIfNull("video_id",?videoInfo.id)trackParams.putIfNull("video_type",?videoInfo.type)}fun?clickFavorite()?{//?使用View.trackEvent上報埋點，會從當前View開始向上收集埋點參數(shù)itemView.trackEvent("click_favorite")} }可以看到，利用 ViewTree，為 View 添加 trackModel 的方式，不需要再實現(xiàn) ITrackNode，手動建立上下級關(guān)系。由于 ViewTree 的存在，即便是層級很深的子視圖，也可以直接作為埋點節(jié)點來使用，而不需要再經(jīng)過中間的橋接節(jié)點。
直接在自定義類實現(xiàn) ITrackNode，和為 View 添加 ITrackModel，這兩種方式可以組合在一起使用。理想的頁面上下級鏈路是這樣的，實現(xiàn) ITrackNode 作為上層節(jié)點，更加方便組織邏輯關(guān)系復(fù)雜的子視圖，如首頁頻道等；層級較深的節(jié)點直接利用 ViewTree，方便向上搜索責任鏈。
4. 建立頁面來源責任鏈
建立來源責任鏈的建立，指的是頁面跳轉(zhuǎn)過程中，將跳轉(zhuǎn)前的節(jié)點/上下文參數(shù)傳遞給跳轉(zhuǎn)后的頁面，作為后者的來源節(jié)點（referrerTrackNode）。
我們利用跳轉(zhuǎn) Intent 攜帶來源節(jié)點信息：
//?設(shè)置當前跳轉(zhuǎn)的來源節(jié)點 class?VideoViewHolder?{fun?clickJumpDetail()?{//?設(shè)置跳轉(zhuǎn)的來源節(jié)點是當前節(jié)點intent.setReferrerTrackNode(this)startActivity(intent)} }在跳轉(zhuǎn)后的頁面，只需要從 intent 再取出來就可以了
class?VideoDetailActivity?{override?fun?referrerTrackNode():?ITrackNode?{return?intent.getReferrerTrackNode()} }值得注意的是，邏輯上應(yīng)該直接使用當前節(jié)點的引用作為下個頁面的 referrerTrackNode，但實際使用中，可能會有內(nèi)存泄漏、鏈路過于復(fù)雜的問題，所以在 setReferrerTrackNode 的時候，我們制作了當前節(jié)點的快照，把當前節(jié)點的上下文參數(shù)都添加進了 Map，傳遞給下個頁面的實際上是這個快照節(jié)點。
完成了來源節(jié)點的傳遞，在下個頁面怎么使用呢？最簡單的是直接把來源節(jié)點的所有參數(shù)，添加進埋點中，但我們的埋點需求常常會需要一些轉(zhuǎn)換規(guī)則，比如：
上個頁面的 category_name，跳轉(zhuǎn)后上報 parent_category_name
上個頁面的 page_name，跳轉(zhuǎn)后上報 from_page
因此我們定義了 IPageTrackNode，用來做頁面級別的埋點處理
interface?IPageTrackNode:?ITrackNode?{fun?referrerKeyMap():?Map<String,?String> }通常會由頁面的 Activity 實現(xiàn) IPageTrackNode
class?VideoDetailActivity:?IPageTrackNode?{var?videoInfo//?定義來源參數(shù)映射override?fun?referrerKeyMap():?Map<String,?String>?{return?mapOf("page_name"?to?"from_page","channel_name"?to?"from_channel_name","tab_name"?to?"from_tab_name")}override?fun?fillTrackParams(trackParams:?TrackParams)?{trackParams.putIfNull("video_id",?videoInfo.id)trackParams.putIfNull("video_type",?videoInfo.type)trackParams.putIfNull("page_name",?"detail")} }class?BottomActionBar?{fun?clickFavorite()?{//?上報埋點的時候，直接從當前節(jié)點往上收集埋點參數(shù)trackEvent("click_favorite")} }可以看到這樣一來，在詳情頁上報 click_favorite 埋點也變得簡單了。
5. 埋點參數(shù)的收集
前面說明了如何建立頁面上下級責任鏈和來源責任鏈。上報埋點的時候，按照下面的流程，順著責任鏈收集埋點參數(shù)：
6. 埋點線索：TrackThread
按照前面的內(nèi)容，我們已經(jīng)可以建立用戶使用整個 App 的過程中，所有上下文的責任鏈關(guān)系，理論上可以上報任意需要的上下文參數(shù)。然而實際業(yè)務(wù)的埋點需求中，還有一類更復(fù)雜的場景，需要在多個節(jié)點/頁面間共享埋點參數(shù)。例如西瓜視頻創(chuàng)作過程的埋點：
tab_name：進入創(chuàng)作場景的來源，在一次創(chuàng)作過程中，所有埋點都需要帶上這個信息
is_record/is_cut：是否使用過拍攝、剪輯功能，可能在創(chuàng)作過程中發(fā)生變化，在創(chuàng)作過程的任意節(jié)點上，需要讀寫這些參數(shù)
以前這類埋點基本會通過單例來維護，單例的話就會遇到前面“單例傳參”部分講到的問題，而我們發(fā)現(xiàn)在整個頁面上下級和來源責任鏈都已經(jīng)建立的情況下，頁面的之間的關(guān)聯(lián)不就可以方便地共享參數(shù)嗎？在一個打開的頁面上添加參數(shù)，并且共享到后續(xù)的頁面，參數(shù)的生命周期和頁面的生命周期綁定，用戶離開這個頁面后自動消失，不用擔心清除和覆蓋的問題。
因此我們引入埋點線索（TrackThread）的定義，任意起始節(jié)點都可以初始化一個 TrackThread，TrackThread 上能夠存放各種類型的 TrackModel，在后續(xù)的所有關(guān)聯(lián)節(jié)點中，都能夠通過已經(jīng)建立的責任鏈，訪問到 Thread 進行讀寫。通過任意節(jié)點上報埋點，可以指定需要添加哪些 TrackModel 的埋點參數(shù)。
//實現(xiàn)ITrackModel接口 class?RecordInfo?:?ITrackModel?{var?isRecord?=?falseoverride?fun?fillTrackParams(params:?TrackParams)?{params.put("is_record",?isRecord.toYesOrNo())} }//?在某個合適的時機，比如進入拍攝頁面，開啟埋點thread，添加TrackModel node.startTrackThread().putTrackModel(RecordInfo())//?任意節(jié)點上更新thread node.trackThread?.getTrackModel(RecordInfo::class.java).isRecord?=?true//?上報埋點 view.newTrackEvent("click_publish")?//?通過newTrackEvent創(chuàng)建Event實例.with(RecordInfo::class.java)?//?聲明需要上報TrackThread中的RecordInfo.emit()?//?最終計算并上報埋點埋點線索適合用于具有會話特性的流程中，方便在流程中共享參數(shù)，常見的還有登錄、注冊的流程，訂單創(chuàng)建流程等。
總結(jié)
至此，我們基于責任鏈的埋點開發(fā)框架已經(jīng)差不多介紹完了，從上面的內(nèi)容可以看出，這個框架更多是約定了一套責任鏈的協(xié)議，通過責任鏈的存在，方便埋點參數(shù)的收集上報。當然我們?yōu)榱朔奖闶褂?#xff0c;也使用到很多語言特性來簡化框架的 API，比如通過接口默認實現(xiàn)，Fragment 的父節(jié)點默認指向 Activity，通過擴展函數(shù)，讓 View 可以直接添加 TrackModel 和上報埋點，但這些都不影響協(xié)議原本的內(nèi)涵。
總結(jié)下這個方案的優(yōu)勢和問題：
優(yōu)勢
埋點需求對原有的功能代碼侵入性小，只需實現(xiàn) ITrackNode 接口建立鏈路，或者直接使用 ViewTree 的責任鏈，就可以達到跨層級傳參的目的，傳參復(fù)雜度大大降低，減少代碼量和人力成本
各個節(jié)點不再需要關(guān)注其他節(jié)點的埋點參數(shù)，只需要負責填充自己的參數(shù)即可，做到“關(guān)注點分離”，同時還能夠讓每個節(jié)點的參數(shù)得到復(fù)用，無需反復(fù)添加同樣的參數(shù)，理想情況下，一個場景的一個新增參數(shù)，只需在相關(guān)節(jié)點上添加一處，即可做到所有的子節(jié)點都能收集到
問題
理解成本，就像前端同學(xué)使用 React 一樣，不可避免地有一些學(xué)習(xí)成本；同時還需要和數(shù)據(jù)分析師約定好埋點規(guī)范，只有在良好的規(guī)范下，埋點框架才能發(fā)揮更好的作用
無法通過類、參數(shù)定義等方式，強制約束埋點參數(shù)列表，新來的開發(fā)同學(xué)做新需求時，可能不知道該傳哪些參數(shù)
重構(gòu)現(xiàn)有埋點的建議
一些場景已經(jīng)有大量埋點邏輯，無法短時間全部改掉。主要原因是因為埋點往往沒有“邊界”：埋點需要大量的“上下文”與“來源”參數(shù)，而我們已經(jīng)在實踐中發(fā)現(xiàn)，這些參數(shù)是埋點錯綜復(fù)雜的主要原因。
舉 2 個例子：進入個人主頁埋點（enter_pgc）和點擊關(guān)注埋點(rt_follow)，開發(fā)面臨的情況是進入個人主頁的入口有 100+處，關(guān)注組件被引用的場景有 58 處。短時間要修改全部來源參數(shù)和上下文參數(shù)的傳遞方式，開發(fā)和測試成本很大，一次迭代基本不可能完成。
因此我們建議弄清埋點的“邊界”，在此基礎(chǔ)上控制每一次重構(gòu)的影響范圍。
重構(gòu)通用業(yè)務(wù)組件
通用業(yè)務(wù)組件指的是像“關(guān)注按鈕”或者“關(guān)注操作”這種有特定業(yè)務(wù)邏輯、大量使用于各種業(yè)務(wù)場景的下沉組件。這類組件往往有特定的埋點要求，觸發(fā)埋點本身不是很復(fù)雜的事情，復(fù)雜的是怎么獲取到觸發(fā)事件時的上下文信息。對于此類組件，建議：
保留新舊兩種埋點傳參的接口
在老接口中對埋點參數(shù)進行封裝，轉(zhuǎn)發(fā)到新接口執(zhí)行實際的邏輯，同時對老接口標注@Deprecated
未來逐步替換到新接口上
重構(gòu)一個頁面的結(jié)構(gòu)
重構(gòu)一個頁面時，期望可以把各個層級定義成 TrackNode 節(jié)點，構(gòu)建完整的責任鏈。但是一個頁面結(jié)構(gòu)中，常常使用了大量其他模塊的組件或者功能，而依賴的這些模塊還沒完成埋點重構(gòu)。因此重構(gòu)時依賴到其他模塊/組件的情況，建議：
對當前模塊內(nèi)的部分構(gòu)建責任鏈
不改變其他模塊的接口，涉及到這些模塊埋點參數(shù)傳遞的，在傳參的節(jié)點上，獲取節(jié)點的埋點參數(shù)，使用老的方式傳參
重構(gòu)一個頁面的來源傳參方式
一個頁面的來源參數(shù)，外部可能通過很多種方式，如 Intent、單例等傳遞過來。為了讓頁面內(nèi)責任鏈上的每個節(jié)點，都能夠獲取到來源的參數(shù)，同時兼容外部新老傳參的方式，建議：
當前頁面改造成新的獲取來源參數(shù)的方式，同時支持按照老的傳參方式讀取來源參數(shù)，需要時可在頁面初始化的時機 Mock 一個 referrerTrackNode
外部跳轉(zhuǎn)逐步切換到新的來源參數(shù)傳參方式
加入我們
歡迎加入字節(jié)跳動西瓜視頻客戶端團隊，我們專注于西瓜視頻 App 的開發(fā)和基礎(chǔ)技術(shù)建設(shè)，在客戶端架構(gòu)、性能、穩(wěn)定性、編譯構(gòu)建、研發(fā)工具等方向都有投入。如果你也想一起攻克技術(shù)難題，迎接更大的技術(shù)挑戰(zhàn)，歡迎加入我們！
西瓜視頻客戶端團隊正在熱招 Android、iOS 架構(gòu)師和研發(fā)工程師，最 Nice 的工作氛圍和成長機會，各種福利各種機遇，在北京、杭州、上海三地均有職位，歡迎投遞簡歷！聯(lián)系郵箱：liaojinxing@bytedance.com ；郵件標題：姓名-工作年限-西瓜-Android/iOS/基礎(chǔ)技術(shù)。
點個在看殺個 Bug ?
總結(jié)
以上是生活随笔為你收集整理的西瓜客户端埋点实践：基于责任链的埋点框架的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 1000日本版式设计速查手册
- 下一篇： 绘画教程：各种情况下褶皱的产生和画法