MTFlexbox自動化埋點探索

1. 背景

跨平臺動態化技術是目前移動互聯網領域的重點關注方向,它既能節約人力,又能實現業務快速上線的需求。通過十年的發展,美團App已經變成了一個承載衆多業務的超級平臺,衆多的業務方對業務形態的快速迭代和更新提出了愈來愈高的要求。傳統移動端」靜態「的開發方式存在一系列問題,好比包體積增加過快、線上Bug修復困難、發版週期長等,已經不能知足高速發展的業務須要。所以,美團平臺自研了一套跨平臺動態化方案——MTFlexbox。html

目前,MTFlexbox已經普遍應用於美團首頁、搜索、外賣等多個業務場景,而且已穩定運行兩年有餘。在MTFlexbox規範下,只須要寫一份佈局文件,就能夠適用多端。在實際開發中,客戶端開發同窗開發佈局的同時也要添加好埋點信息,幫助產品同窗來評估上線後的效果。但現有佈局埋點存在成本太高、準確率較低等痛點,爲了解決這些問題,咱們充分了解數據組開發人員和產品對數據統計的訴求,結合對MTFlexbox原理的深刻理解,圍繞MTFlexbox的埋點上報作了不少持續、有針對性的自動化工做,幫助多個項目的效率獲得了顯著提高。本文主要介紹美團在MTFlexbox自動化埋點方向所進行的一些探索,但願對你們可以有所幫助。前端

2. MTFlexbox介紹

2.1 MTFlexbox原理

MTFlexbox是美團內部一套很是成熟的跨平臺動態化解決方案,遵循了CSS3中提出的Flexbox規範,抹平了多平臺的差別。MTFlexbox首先按照Flexbox的規範,定義了一套三端統一的XML佈局文件,並將佈局文件上傳至後臺;客戶端下載帶有佈局文件的JSON數據後,解析佈局並綁定JSON數據,最終交由Native渲染成視圖。MTFlexbox的總體架構圖以下所示: git

MTFlexbox架構圖

若是要用一句話來解釋MTFlexbox的原理,就是按照約定的規則將XML內容映射成Native佈局。從Android開發者的角度想,能夠認爲是把傳統XML佈局文件由內置改爲從網絡下發,實現展現樣式動態改變的效果。上圖第一層是MTFlexbox須要的輸入,包括XML佈局文件和展現的業務數據。其中XML佈局文件中包括UI標籤和埋點信息,每一種類型的埋點信息都做爲一種屬性和某一個UI標籤相綁定。展現的業務數據能夠經過後臺下發或者寫死在本地。爲了將XML文件與具體的View進行解耦,MTFlexbox在XML與View之間增長了一層Node層,即先將XML解析成Node樹,再將Node樹解析成View樹。MTFlexbox共有3層緩存:對XML文件的緩存、對Node節點的緩存、對View的緩存。其中緩存View指的是緩存一個XML建立的View,一般只會緩存rootView。在Node樹生成了View樹並綁定JSON數據後,纔會最終渲染成Native控件。github

2.2 MTFlexbox適用場景

MTFlexbox基本上支持Native上經常使用的基礎控件的展現,對有UI定製化的需求支持度很高。但MTFlexbox的XML佈局須要在運行前編寫完成,只支持簡單的三元表達式,邏輯能力有限。所以,MTFlexbox特別適合佈局樣式複雜、變更頻繁但交互簡單的業務場景。例如美團App首頁、搜索結果頁等。這些業務場景都具有如下兩個特色:json

面向多業務方:各業務方有本身的個性化豐富樣式,且不一樣時期可能須要不一樣的樣式。後端

交互簡單:點擊跳轉完成流量輸送的簡單交互。數組

下面是MTFlexbox使用場景的一些截圖:緩存

2.3 MTFlexbox自動化埋點前期工做

在美團實際的業務場景中,卡片的點擊、曝光和加載數據是分析一個新產品形態上線效果好壞的最基本方式之一。相對應的,客戶端的數據採集方式是洞察對於模塊的點擊、曝光和加載事件,而後結合上下文環境,好比頁面標識、模塊標識等,最後使用埋點上報工具和業務字段一塊兒進行上報。MTFlexbox做爲模塊級別的動態佈局UI展現框架,對於數據採集方式的支持也是必不可少的。MTFlexbox針對數據採集的方式,作了如下兩件事:bash

制定了一套雙端統一的埋點標準化規範。網絡

埋點類型定義成Tag標籤屬性,寫入佈局文件中。

MTFlexbox結合美團自研的客戶端數據上報工具,定義了多個專門針對埋點的特有屬性字段,主要類型以下:

客戶端開發人員在編寫佈局文件時,能夠根據具體的產品需求,對不一樣控件的標籤添加埋點屬性,而且寫入須要上報的業務字段。這樣能夠達到與Native埋點相同的效果,而且雙端只須要配置一份埋點。以see-mge4-report埋點爲例,佈局埋點代碼以下:

<Container style="width:360pt;justify-content:center;" >
    <Var name="see_MGE4" type="json">
            {
            "bid":"xxxxx",
            "cid":"yyyyy",
            "lab":{
                "isDynamic":true,
                "gather_index":"{extra.gather_index}",
                "index":"{extra.index}"
                }
            }
    </Var>
    <Container 
              see-mge4-report="{see_MGE4}"
              click-url="{business.iUrl}"
              visibility="{{display.itemDynamic.imageUrl}?visible:displaynone}" >

            <Img style="width:331pt;height:106pt;justify-content:center;"
                border-radius="5pt"
                scale-type="center-crop"
                src="{display.itemDynamic.imageUrl}"
                background="#FFF8F8F8" />
    </Container>
</Container>
複製代碼

2.4 MTFlexbox動態化研發流程

MTFlexbox動態化研發流程

從上述MTFlexbox動態化研發流程圖中能夠看出,數據需求和產品需求須要客戶端開發人員在同一份佈局文件中耦合在一塊兒去實現,並且埋點屬性和佈局控件相綁定。這就致使在埋點過程當中會出現不少問題,總結以下:

埋點成本太高

  • 溝通成本較高:對於一個新的產品需求,首先產品須要將埋點需求提給數據組,數據同窗理解了產品需求後產出埋點文檔;而後產品、數據同窗、客戶端開發同窗三方進行需求評審和埋點評審,溝通埋點須要上報的字段和時機等細節。不少時候,一次溝通不到位,還須要反覆溝通或者從新溝通,直到產品、數據同窗和客戶端開發人員三方對需求和埋點的理解一致爲止。平均一個5PD(5PD指5個工做日)的需求須要消耗數據同窗和客戶端開發人員各1PD的時間來進行理解和溝通。

  • 開發成本太高:客戶端開發人員在編寫XML佈局文件時,每每要花30%左右的時間進行手動埋點和自測校驗。

埋點線上事故多

  • 因整個埋點缺少自動化的埋點校驗和預警機制,一旦開發人員出現人爲的失誤,致使錯埋、漏埋現象,都有可能引起嚴重的線上故障。例如,客戶端開發人員手動埋點時,出現人爲失誤引入了錯誤數據;產品驗收階段須要修改佈局樣式,客戶端開發人員會出現」僅修改佈局而遺漏埋點「的問題。

鑑於MTFlexbox存在埋點成本太高和線上問題較多的突出問題,咱們迫切的但願經過一些手段來最大程度的規避和解決這類問題。埋點成本太高的緣由在於MTFlexbox將佈局和埋點耦合在一塊兒編寫,客戶端開發人員須要作的事情過於」雜「和」多「。找到了這個痛點,很容易想到將埋點上報和佈局編寫解耦,讓客戶端開發人員只負責編寫佈局,數據同窗只負責埋點配置,以此下降開發和溝通成本;同時經過自動化埋點校驗手段提高埋點準確率,優化流程,減小線上事故的產生。基於此,產出咱們理想的佈局和埋點解耦以後的動態化研發流程,以下圖所示:

新的動態化流程

3. 業內自動化埋點方案調研與參考

3.1 美團外賣前端無痕埋點實踐

外賣團隊在他們原有代碼埋點方案的基礎上,演化出了一套輕量的、聲明式的前端埋點方案。詳細內容能夠參考博客:《美團點評前端無痕埋點實踐》。此方案經過聲明式埋點的方式實現了埋點代碼與業務邏輯的解耦,而且支持對通用的業務數據的自動化上報。但此方案不能徹底實現自動化埋點,而且實現成本較高。

3.2 Mixpanel

Mixpanel是一個已經商業化的可視化埋點方案,採用了截屏的方式在IDE中完成控件的圈選操做,體驗較好值得咱們借鑑。不過該方案主要面向非技術人員,不支持上報業務字段數據。

3.3 HubbleData

HubbleData是網易開發的一個洞察用戶行爲的數據分析系統,提供一套完整的數據解決方案。

網易對XPath作了優化,主要體如今View索引的計算上:

  • 原始XPath計算方式:每一個ViewGroup下的全部View做爲一個數組,索引從0開始。例如上圖Button控件的XPath標識爲:LinearLayout[0]/FrameLayout[0]/RelativeLayout[1]/Button[1]

  • 網易XPath計算方式:每一個ViewGroup下的全部View先按控件類型分類,而後再把每一個類型中的控件按照數組的方式,從0開始。例如上圖Button控件的XPath標識爲:LinearLayout[0]#rootView/FrameLayout[0]/RelativeLayout[0]#container/Button[0]#btn

可是網易的此次優化,並無解決因爲同類型控件位置變動而引起的埋點錯誤問題,根源在於控件惟一標識不夠準確。同時網易的修改僅限控件的一些固有屬性,並無蒐集到更有價值的業務數據。

結合上述四種方案的優缺點,自動化埋點須要具有的幾個條件,即:簡潔直接的流程、友好可視化的前端配置界面、業務字段的可配置化、埋點有效性的檢測。咱們的方案就是基於這幾個目標而誕生的。

4. 咱們的方案

總體流程

MTFlexbox自動化埋點的核心流程,分爲如下五步:

  1. 客戶端開發人員根據設計稿開發XML樣式文件,自測經過後將XML樣式文件與接口數據上傳至MTFlexbox管理後臺。

  2. MTFlexbox管理後臺自動鏈接遠程移動設備,併發送佈局處理命令。遠程移動設備將佈局渲染結束後,抓取截圖和佈局層級信息(包括控件父子關係、控件位置、大小等信息)並上傳至管理後臺。

  3. 前端頁面從後臺拿到DPath路徑信息、座標信息和截圖信息,提供一套可視化的界面供數據同窗進行模塊內任一控件的埋點圈選配置。數據同窗根據自身的需求,從目錄樹中圈選出本身但願配置埋點的控件。以下圖所示,右側模塊中會出現紅圈將選中的控件標出。

    目錄樹圈選控件

  4. 選中某個控件以後,數據同窗對該控件進行埋點配置,元素類型支持當前元素和同類元素。其中同類元素能夠節省數據同窗對於同一種類型的控件的屢次配置。對於已經圈選出的控件,列表中會詳細展現出相關的信息,並附上控件對於的位置截圖,可以方便數據RD定位埋點的控件具體位置。

    埋點配置

  5. MTFlexbox管理後臺根據前端上報的埋點信息,生成包含業務埋點的XML樣式文件,供C端業務方後臺調用。

<?xml version="1.0" encoding="UTF-8"?>
<Container>
    <Var auto-mge="true" name="ff510aa110844bb78c0b86fb04b26460" type="json">
        {
            "bid" : "xxxxx",
            "cid" : "sssss",
            "lab" : {
                "index" : "{_index}",
            }
        }
    </Var>
    
    <!-- 整個容器 -->
    <Container background="#FFFFFF" border-radius="10pt"
        click-mge4-report="{ff510aa110844bb78c0b86fb04b26460}"
        click-url="{_iUrl}" padding-left="10pt" padding-right="10pt">
        <!-- 左半部分 -->
        <Container style="flex-direction:column;justify-content:flex-start;margin-top:15pt;">
複製代碼
  1. 當客戶端請求業務後臺時,業務後臺將包含業務埋點的XML樣式文件下發給客戶端,客戶端根據配置完成埋點信息上報。

5. 總結與展望

目前MTFlexbox自動化埋點方案已經使用在美團首頁、大搜等業務中,總體埋點成本下降了80%,上線後且無埋點故障。在此埋點方案的實現過程當中,咱們也踩了不少在設計之初沒有預想到的坑,遇到了一些難點,詳細設計問題和解決方案稍後的博客中的詳細介紹,敬請關注美團技術團隊公衆號。

目前,咱們基於MTFlexbox實現了View與埋點的自動化綁定,後期咱們規劃經過規範標準化後臺下發的數據,包括業務數據和埋點數據,進而實現埋點數據的動態化下發和自動化綁定,進一步節省在埋點配置階段和測試階段的人力投入。

6. 參考資料

  1. 網易HubbleData之Android無埋點實踐

  2. 商業化埋點實現方案mixpanel

  3. 美團點評前端無痕埋點實踐

做者簡介

葉梓、騰飛、田貝、張穎,美團終端業務研發團隊研發工程師。

招聘信息

美團終端業務研發團隊的職責是保障平臺業務高效、穩定迭代的同時,持續優化用戶體驗和研發效率。團隊負責的業務主要包括美團首頁、美團搜索等千萬級DAU高頻業務以及分享、帳號、音/視頻等基礎業務,支撐和對接外賣、酒店等30多個業務方。團隊經過動態化能力建設,加快業務上線速度,幫助產品(PM)快速驗證業務選型,作出業務決策;架構/服務標準化體系建設,提高先後端以及平臺與業務線的溝通、合做效率;業務監控和體驗優化,有效保障核心業務服務成功率的同時,提高用戶使用美團App過程當中的穩定性和流暢性。團隊開發技術棧包括Android、iOS、ReactNative、Flexbox等。

美團終端業務研發團隊是一個活力四射、對技術充滿激情的團隊,現誠聘Android、iOS工程師,歡迎有興趣的同窗投簡歷至tech@meituan.com。

相關文章
相關標籤/搜索