這個時間軸上有如下5個埋點事件發生： 進入A頁面。A頁面首幀渲染完畢，並獲得了焦點。 曝光坑位X。按鈕X處於手機屏幕內，且停留一段時間，讓用戶可見可觸摸。 點擊坑位X。用戶對按鈕X的內容很感興趣，於是點擊了它。按鈕X響應點擊，然後需要打開一個新頁面。 離開A頁面。A頁面失去焦點。 * 進入B頁面。B頁面首幀渲染完畢，並獲得焦點。

在這裡，打埋點最重要的是時機，即在什麼時機下的事件中觸發什麼埋點，下面來看看閑魚在Flutter上的實現方案。

實現方案

進入/離開頁面

在Native原生開發中，Android端是監聽Activity的onResume和onPause事件來做為頁面的進入和離開事件，同理iOS端是監聽UIViewController的viewWillAppear和viewDidDisappear事件來做為頁面的進入和離開事件。同時整個頁面棧是由Android和iOS操作系統來維護。

在Flutter中，Android和iOS端分別是用FlutterActivity和FlutterViewController來做為容器承載Flutter的頁面，通過這個容器可以在一個Native的頁面內（FlutterActivity/FlutterViewController）來進行Flutter原生頁面的切換。即在Flutter自己維護了一個Flutter頁面的頁面棧。這樣，原來我們最熟悉的那套在Native原生上方案在Flutter上無法直接運作起來。

針對這個問題，可能很多人會想到去註冊監聽Flutter的NavigatorObserver，這樣就知道Flutter頁面的進棧（push）和出棧（pop）事件。但是這會有兩個問題： 假設A、B兩個頁面先後進棧（A enter -> A leave -> B enter）。然後B頁面返回退出（B leave），此時A頁面重新可見，但是此時是收不到A頁面push（A enter）的事件。 假設在A頁面彈出一個Dialog或者BottomSheet，而這兩類也會走push操作，但實際上A頁面並未離開。

好在Flutter的頁面棧不像Android Native的頁面棧那麼複雜，所以針對第一個問題，我們可以來維護一個和頁面棧匹配的索引列表。當收到A頁面的push事件時，往隊列里塞一個A的索引。當收到B頁面的push事件時，檢測列表內是否有頁面，如有，則對列表最後一個頁面執行離開頁面事件記錄，然後再對B頁面執行進入頁面事件記錄，接著往隊列里塞一個B的索引。當收到B頁面的pop事件時，先對B頁面執行離開頁面事件記錄，然後對隊列里存在的最後一個索引對應的頁面（假設為A）進行判斷是否在棧頂（ModalRoute.of(context).isCurrent ），如果是，則對A頁面執行進入頁面事件記錄。

針對第二個問題，Route類內有個成員變數overlayEntries，可以獲取當前Route對應的所有圖層OverlayEntry，在OverlayEntry對象中有個成員變數opaque可以判斷當前這個圖層是否全屏覆蓋，從而可以排除Dialog和BottomSheet這種類型。再結合問題1，還需要在上述方案中加上對push進來的新頁面來做判斷是否為一個有效頁面。如果是有效頁面，才對索引列表中前一個頁面做離開頁面事件，且將有效頁面加到索引列表中。如果不是有效頁面，則不操作索引列表。

以上並不是閑魚的方案，只是筆者給出的一個建議。因為閑魚APP在一開始落地Flutter框架時，就沒有使用Flutter原生的頁面棧管理方案，而是採用了Native+Flutter混合開發的方案。具體可參考前面的一篇文章《已開源|碼上用它開始Flutter混合開發——FlutterBoost》。因此接下來也是基於此來闡述閑魚的方案。

閑魚的方案如下（以Android為例，iOS同理）：

註：首次打開指的是基於混合棧新打開一個頁面，非首次打開指的是通過回退頁面的方式，在後台的頁面再次到前台可見。

看似我們將何時去觸發進入/離開頁面事件的判斷交給Flutter側，實際上依然跟Native側的頁面棧管理保持了一致，將原先在Native側做打埋點的時機告知Flutter側，然後Flutter側再立刻通過channel來調用Native側的打埋點方法。那麼可能會有人問，為什麼這麼繞，不全部交給Native側去直接管理呢？交給Native側去直接管理這樣做針對非首次打開這個場景是合適的，但是對首次打開這個場景卻是不合適的。因為在首次打開這個場景下，onResume時Flutter頁面尚未初始化，此時還不知道頁面信息，因此也就不知道進入了什麼頁面，所以需要在Flutter頁面初始化（init）時再回過來調Native側的進入頁面埋點介面。為了避免開發人員去關注是否為首次打開Flutter頁面，因此我們統一在Flutter側來直接觸發進入/離開頁面事件。

曝光坑位

先講下曝光坑位在我們這裡的定義，我們認為圖片和文本是有曝光意義的，其他用戶看不見的是沒有曝光意義的，在此之上，當一個坑位同時滿足以下兩點時才會被認為是一次有效曝光： 坑位在屏幕可見區域中的面積大於等於坑位整體面積的一半。 坑位在屏幕可見區域中停留超過500ms。

基於此定義，我們可以很快得出如下圖所示的場景，在一個可以滾動的頁面上有A、B、C、D共4個坑位。其中： 坑位A已經滑出了屏幕可見區域，即invisible； 坑位B即將向上從屏幕中可見區域滑出，即visible->invisible； 坑位C還在屏幕中央可視區域內，即visible； 坑位D即將滑入屏幕中可見區域，invisible->visible；

那麼我們的問題就是如何算出坑位在屏幕內曝光面積的比例。要算出這個值，需要知道以下幾個數值： 容器相對屏幕的偏移量 坑位相對容器的偏移量 坑位的位置和寬高 容器的位置和寬高

其中坑位和容器的寬和高很容易獲取和計算，這裡就不再累述。

獲取容器相對屏幕的偏移量

//監聽容器滾動，得到容器的偏移量
double _scrollContainerOffset = scrollNotification.metrics.pixels;

獲取坑位相對容器的偏移量

//曝光坑位Widget的context
final RenderObject childRenderObject = context.findRenderObject();
final RenderAbstractViewport viewport = RenderAbstractViewport.of(childRenderObject);
if (viewport == null) {
return;
}
if (!childRenderObject.attached) {
return;
}
//曝光坑位在容器內的偏移量
final RevealedOffset offsetToRevealTop = viewport.getOffsetToReveal(childRenderObject, 0.0);

邏輯判斷

if (當前坑位是invisible && 曝光比例 >= 0.5) {
記錄當前坑位是visible狀態
記錄出現時間
} else if (當前坑位是visible && 曝光比例 < 0.5) {
記錄當前坑位是invisible狀態
if (當前時間-出現時間 > 500ms) {
調用曝光埋點介面
}
}

點擊坑位

點擊坑位埋點沒什麼難點，很容易就可以想到下面的方案：

效果

經過多輪迭代和優化，目前線上Flutter頁面的埋點準確率已經達到100%，有力地支持了業務的分析和判斷。同時這套方案讓業務同學在做開發時，對於頁面進入/離開、曝光坑位可以做到無感知，即不用關心何時去觸發，做到了簡單易用和無侵入性。

展望

此外，針對頁面進入/離開這個場景，由於閑魚是基於Flutter Boost混合棧的方案，因此我們的解決方案還不夠通用。不過未來隨著閑魚上的Flutter頁面越來越多，我們後續也會去實現基於Flutter原生的方案。

在閑魚做數據驅動業務是一件非常重要且有意義事，而埋點直接影響著數據採集，埋點的丟失和錯誤將會讓我們在大海上航行時失去燈塔的指引。在這裡大家都習慣著用數據來指導工作方向，試驗->取數據分析->調整實驗->再取數據分析->再調整實驗。如此循環著，只為找到最適合用戶的那一個設計。如果你認可我們的工作方法論，歡迎加入閑魚！

推薦閱讀：