1、為什么要做？

先看下之前的埋點流程，如圖所示。產(chǎn)品提出埋點需求，開發(fā)人員在mp平臺配置埋點事件，然后進行代碼埋點，再測試埋點，沒問題之后再提審。

這個時候如果有一個 實時的埋點系統(tǒng) 就可以完美解決了。

2、怎么做

2.1、避免重復(fù)造輪子

1. growingio是全埋點，數(shù)據(jù)全，但是由于是全埋點，后期還需要開發(fā)介入清理數(shù)據(jù)，不滿足埋點系統(tǒng)的要求；

2. 神策和MP需要代碼埋點，不能實時生效。
   因此，現(xiàn)有的埋點方案都不能夠完全滿足我們的要求，需要獨立開發(fā)一個系統(tǒng)。

2.2、埋點方案設(shè)計

框架圖如下，小程序的sdk分成兩種模式，埋點模式和采集模式，

1. 埋點模式是產(chǎn)品操作的，供產(chǎn)品新增埋點事件。

2. 采集模式就是采集用戶的點擊操作，在小程序啟動的時候，從后臺拉取產(chǎn)品需要的埋點事件，用戶點擊動作命中埋點事件之后自動進行上報。

在web端，產(chǎn)品可以查看埋點數(shù)據(jù)

這一篇闡述的是小程序SDK的實現(xiàn)，下面做具體介紹

3、埋點系統(tǒng)具體實現(xiàn)

3.1 埋點整體流程

1. 尋找響應(yīng)者

2. 唯一標(biāo)識

3. 攔截交互事件

   其中比較難的一個點是尋找響應(yīng)者，因為小程序是雙線程，視圖層和邏輯層是分開的，跟H5不太一樣，H5是可以獲取完整的dom節(jié)點信息。但是在小程序中可以獲取到的信息很少

     下面重點介紹下這幾個流程

3.2 尋找響應(yīng)者

1）業(yè)界方案介紹 業(yè)界方案主要有兩種，分別是工程化注入和冒泡采集。

• 工程化注入就是給所有標(biāo)簽注入點擊事件，這種相當(dāng)于全埋點，數(shù)據(jù)比較全。
  但是缺點也很明顯，給所有標(biāo)簽加上點擊事件會讓項目顯得比較重，而且假如原來的標(biāo)簽有點擊事件，就更不好處理了。

• 冒泡采集就是在wxml代碼的最外層添加一個view，然后綁定catchtap事件。這種就比較輕量級，無需注入大量代碼。但是依賴于冒泡事件，假如原來的業(yè)務(wù)代碼阻止了冒泡，那就獲取不了，可靠性比較差。

  這兩種方案都是從視圖層出發(fā)，或多或少需要入侵業(yè)務(wù)代碼，各有缺陷，不滿足我們的需求。

2）思路轉(zhuǎn)換 上面的方案是從視圖層出發(fā)，因為小程序的雙線程模型，這里我從另外一個角度出發(fā)，從邏輯層下手。

原理是這樣的：在渲染層觸發(fā)的點擊事件都會傳遞到邏輯層，所以可以從邏輯層入手，對邏輯層的每個函數(shù)提供hook方法，在hook中捕獲到用戶的點擊事件。

3）具體實現(xiàn)

• 目標(biāo)分析：獲取用戶的 點擊行為 ，從  wxml=>js ，也就是從渲染層轉(zhuǎn)向邏輯層。小程序的邏輯層涉及到兩個系統(tǒng)對象

• 頁面對象

• 自定義組件
  因此，只要重構(gòu)這兩個系統(tǒng)對象即可，具體做法如下：

• 在小程序啟動的時候， 重構(gòu)Page()和Component()這兩個系統(tǒng)對象 ，遍歷對象里面的所有屬性，如果屬性類型是函數(shù)，則進一步判斷是否在忽略名單，像監(jiān)聽頁面滾動的函數(shù)這種是不需要添加hook的，最后才是給函數(shù)添加hook

  不過在小程序啟動的時候去給頁面的函數(shù)添加hook還不完整，因為有些函數(shù)是在運行時添加的，像這種該 怎么添加hook呢 ？

• 給運行時的func添加hook
  這塊我想到了幾種方案

1. 給Page對象設(shè)置proxy，監(jiān)控set方法

2. 在所有hook中監(jiān)控Page屬性的數(shù)量

3. Page添加生命周期函數(shù)，onLoad執(zhí)行完之后給新生成的func添加hook

第一種和第二種都存在多次觸發(fā)的情況，影響性能。只有第三種是一勞永逸的，只需要執(zhí)行一次就可以了。

3.3 唯一標(biāo)識

唯一標(biāo)識就是確定用戶點擊動作的唯一性，傳統(tǒng)的標(biāo)識大部分是通過視圖棧方案，也叫特征值標(biāo)識。在小程序中，就是通過標(biāo)簽的id來標(biāo)識，id就是標(biāo)簽的特征值。

1）視圖棧方案

如圖所示，當(dāng)用戶點擊某個標(biāo)簽時，可以獲取到兩個id，一個是targetId，另一個是currentTargetId，其中

• Target，觸發(fā)事件的源組件，

• currentTarget，事件綁定的當(dāng)前組件。

這種方案，唯一標(biāo)識就是通過這 兩個id進行組合 得到

使用這種方案 可靠性比較差 ，因為在寫業(yè)務(wù)代碼的時候，可能沒有給標(biāo)簽添加id，這樣取到的id就是空字符串，使得標(biāo)識并不唯一

2）變量名+新特征值

不過細想一下，還是有一些情況需要考慮：

• custom components如何獲取pagePath

  因為組件的層級比頁面層級低，從組件對象是沒法獲取頁面信息的。

  但是由于是 可視化埋點 ，所以組件所在的頁面肯定在頁面棧的最上面，因此，可以通過 頁面棧 獲取當(dāng)前的 頁面對象 ，然后再獲取頁面路徑

• 對于list點擊事件，如何區(qū)分？

如圖，每個tab的點擊情況是需要區(qū)分統(tǒng)計的，而對于下面列表中的獎勵領(lǐng)取，一般是不需要區(qū)分的。不需要區(qū)分的按照原方案即可。
對于需要區(qū)分統(tǒng)計的，因為tab不同時，所觸發(fā)的函數(shù)參數(shù)肯定也不同，所以 唯一標(biāo)識需要帶上函數(shù)的參數(shù)。

• 如何統(tǒng)計一個事件在所有頁面的情況

對于全局范圍的統(tǒng)計，因為要統(tǒng)計所有頁面的情況，所以需要將頁面路徑和函數(shù)名稱分開存放，其中函數(shù)名作為埋點事件的唯一標(biāo)識，頁面路徑作為子標(biāo)識。

3.4 攔截交互事件

1）事件模型分析

2）埋點模式流程

埋點模式是供產(chǎn)品使用的，產(chǎn)品點擊頁面時，會觸發(fā)邏輯層的某個函數(shù)，前面說到，每個函數(shù)都會添加hook.

Hook的執(zhí)行流程如下，首先會根據(jù)事件對象的事件戳和標(biāo)識符來判斷這個事件是否已經(jīng)上報處理過，如果是就直接結(jié)束。

否則就記錄下這個事件已經(jīng)處理過，防止后面重復(fù)處理。

然后再判斷這個事件類型是否為點擊事件，如果是就詢問用戶是否要執(zhí)行埋點上報，最后確保埋點類型及名稱。

3）采集模式流程

采集模式是根據(jù)埋點事件進行數(shù)據(jù)上報?？梢愿顸c模式一樣，

• 給所有func添加hook，在hook判斷是否要上報。這種方案有個弊端，因為埋點事件的數(shù)量遠比函數(shù)的數(shù)量要少，大多數(shù)函數(shù)是沒必要進行hook的，給全部函數(shù)加上hook會影響頁面的性能。

• 根據(jù)埋點事件找到需要上報的func，只給這些func添加hook。很明顯，這種方案更佳，下面看看具體實現(xiàn)流程。

小程序啟動的時候，同時進行兩件事。

• 給頁面添加一個生命周期函數(shù)initFuncHook

• 從后臺拉取埋點事件

  當(dāng)頁面打開的時候，去執(zhí)行initFuncHook生命周期函數(shù)，initFuncHook的流程如下：

  遍歷頁面的屬性，判斷屬性是否為fun類型，并且是需要埋點的，如果需要則添加hook，如果不需要就重新遍歷對象屬性，直到所有屬性都遍歷為止。