最近無埋點技術很是流行，抽空研究了下諸葛IO，talkingData以及百分點這些業內知名公司的無埋點SDK，抽取其中重要的資訊供大家參考：

1、首先什麼是無埋點呢，其實所謂無埋點就是開發者無需再對追蹤點進行埋碼，而是脫離程式碼，只需面對應用介面圈圈點點即可追加隨時生效的事件資料點。

無埋點的好處

其實無埋點並不是完全不用寫程式碼，而是儘可能的少寫程式碼。開發者將SDK整合到專案中，配置並初始化SDK之後，接下來就可以進行視覺化操作。這個可以不依賴開發者，一些實施人員都是通過後臺的配製，就達到埋點的配製，還有新增埋點改動都是很方便的實現。最後就是配製和程式碼，可以很靈活地擴充套件，動態地更新。

2、上面我們寫道無埋點要進行視覺化操，參考百分點、talkingData採用相對簡單可行的辦法是對當前的螢幕進行截圖，截圖完了以後做一些處理。做一些壓縮，然後傳到服務端，服務端進行展現，就把螢幕截圖展現出來。螢幕截圖做完了，下一步，需要在管理介面進行配置，對於可點選的元件進行配置，就需要把這些介面框起來展現給使用者。下面是擷取的talkingData的視覺化操作為例，為大家展示視覺化埋點的流程：

專案嵌碼之後，進入視覺化連結頁面，搖一搖連線裝置：

搖一搖，連線裝置

連結成功之後，平臺獲取當前介面截圖：

平臺自動獲取連線裝置當前介面

為要統計的介面元素命名事件，新增追蹤點，至此埋點操作完成：

選擇介面中的元素來追加事件

這裡需要指出一下，無埋點只是針對一些簡單的操作統計，如按鈕點選的次數、時間等。如果是比較複雜的應用場景，例如支付事件，需要統計商品名稱、價格、數量等，這就需要通過埋點來收集詳細的引數。

3、無埋點實現方式：

整個技術裡面比較關鍵的一點是怎麼拿到螢幕控制元件資訊。這一塊兒主要就是三個問題。第一，就是獲取時機。第二，就是拿控制元件什麼資訊，什麼資訊是需要用到的。第三，就是比較關鍵的，如何生成控制元件的唯一ID，ID是在程式內部生成。需要保證在不同的手機上面，這些ID是一樣的。還要保證每一次啟動ID都是不變。

首先是Android：

然後，接下來我們可以看一下iOS，同樣的，也是面臨三個問題：

iOS無埋點的核心技術是利用蘋果的runtime機制，把系統事件、點選事件的指標替換成我們自己的函式來監測使用者的操作，我們在自己的函式中採集併發送需要的資料。

4、遇到的問題和解決辦法

第四部分，講一下我們在實現無埋點技術的時候，遇到了什麼坑？以及採用什麼方法來解決這些坑。

長連線斷開的問題，我們之前是設計每隔5秒傳送一次截圖，一般不會產生斷開。但是，後面做了一些優化，我們不會每隔5秒就發，這樣就會導致這個鏈路長時間沒有資料。然後，我們解決方法也是採取了業界通用的方法，發一個心跳，通過發一個心跳來保證這個鏈路一直是活著的。

第二個問題就是搖一搖遇到的問題，我們遇到的問題是這樣的，你拿著手機搖一搖，什麼時候連線成功呢？你得給使用者一個反饋，要不使用者就是一直搖下去，我們後來想的方法是，搖成功給他一個振動，振動了，使用者有反饋，就知道這個連線成功了，不需要搖了。然後，就是帶來另外一個問題。有時候運動當中，又會產生一些誤操作，就是導致手機會振一下。這個怎麼解決呢？我們就想了一下，可以通過給服務端有一個互動，管理介面裡面發現有一個請求過來要連了會有一個確認的按鈕，使用者確認之後，SDK收到確認訊息以後，我們再去振動。這樣的話，既可以給使用者反饋，也不會說在它誤操作情況下振動。這樣就不會造成誤操作，也不會無緣無故地進行振動。

介面傳輸的優化，因為在整個配製過程當中，傳輸資料量最大的就是螢幕的截圖。怎麼把這個優化一下？就可以更好地提升我們的體驗度，還有流暢性。圖片採用jpeg格式，把圖片質量選擇0.6，剛好是可以看清楚的。然後，也最大限度地降低了這個圖片大小。

然後，整個傳輸效率，有這樣一個問題。我在當前介面，預設就是5秒傳一次。我點了一下，我在當前一個列表介面，點了一下切換到詳情介面。最壞的情況下就是等5秒，加上網路傳輸效果，管理介面就看到新的螢幕。這種體驗是很差的，因為實時性太差。所以，這一塊做了一個優化。儘量讓它實時傳過去，我們在螢幕切換的時候，主動發一次截圖。這樣的話，等的時間就是網路傳輸的時間，不用等5秒固定的時間。這一塊使用者體驗上面就是更流暢一些。

有的時候螢幕介面沒有任何的變化的，這個時候每隔5秒傳一次沒有必要的。所以，我們把螢幕截圖做一個md5進行保留，傳輸時對比md5，當切換到下一個的時候，我們就發新的螢幕截圖。這樣就會減少很多不必要的螢幕的傳輸。然後，也會節省很多的流量。

控制元件ID重複的問題。前面說過我們的ID生成規則可以解決90%的問題，但是，有一些問題還是解決不了。生成ID重複，重複的話就會產生一個什麼樣的效果和問題？同樣兩個按紐，一個註冊，對於註冊定義了一個埋點，就是註冊點選，使用者實際操作的時候點登陸的時候也是發過來一個註冊點選訊息。這樣就是統計不準，因為這種比較的特殊，我們採用的解決方案，通過服務端發一些特殊配製。把這些配製裡面，因為這兩個button裡的text不一樣，一個是註冊，一個是登陸。我們把text資訊放在ID的這個生成規則裡面，最終生成兩個不同的ID，也是可以解決這個問題。

還有一個難點通過視覺化埋點的事件名稱會先通過平臺傳到伺服器，伺服器再傳給所有使用者APP中的SDK，SDK進行判別是哪個介面的哪個事件被動態埋點了，然後進行統計，併發送資料到後臺進行統計分析。判斷某個介面的某個事件應該會比較棘手，在這裡先做一個標記。

當然在寫SDK的過程中肯定還有很多的坑，我會在以後的時間裡一一記錄下來，同時也歡迎大家提出自己的見解。

主要參考：以上是之前找的資料，時間久了就忘了出處，故沒有貼上作者資訊，但這些資訊給自己在實踐的過程中提供了很多的指導，這裡多謝作者，以後找到出處一定補上。

終於找到來源了，嘿嘿嘿：http://chuansong.me/n/952687251048#10006-weixin-1-52626-6b3bffd01fdde4900130bc5a2751b6d1

作者：woniu 連結：https://www.jianshu.com/p/6f47fc648e69 來源：簡書 簡書著作權歸作者所有，任何形式的轉載都請聯絡作者獲得授權並註明出處。