千人千面錄製回放技術讓你 “看到” Flutter 使用者側問題

摘要： 0 1 釋出app後，開發者最頭疼的問題就是如何解決交付後的使用者側問題的還原和定位，是業界缺乏一整套系統 的解決方案的空白領域，閒魚技術團隊結合自己業務痛點在flutter上提出一套全新的技術思路解決這個問 題。 我們透過系統底層來捕獲ui事件流和業務資料的流動，並利用捕獲...

0 1

釋出app後，開發者最頭疼的問題就是如何解決交付後的使用者側問題的還原和定位，是業界缺乏一整套系統 的解決方案的空白領域，閒魚技術團隊結合自己業務痛點在flutter上提出一套全新的技術思路解決這個問 題。

我們透過系統底層來捕獲ui事件流和業務資料的流動，並利用捕獲到的這些資料通過事件回放機制來複現線上的問題。本文先介紹flutter觸控手勢事件原理，接著介紹裡面怎樣錄製flutter ui手勢事件，然後介紹怎樣還原回放flutter ui手勢事件，最後附上包括native錄製回放的整體框架圖。為了便於理解本文，讀者可以先閱讀我之前寫的關於native錄製和回放文章 《千人千面線上問題回放技術》

0 2

現在的app基本都會提供使用者反饋問題的入口，然而提供給使用者反饋問題一般有兩種方式：

• 直接用文字輸入表達，或者截圖

• 直接錄製視訊反饋

這兩種反饋方式常常帶來以下抱怨：

• 使用者：輸入文字好費時費力

• 開發1：看不懂使用者反饋說的是什麼意思？

• 開發2：大概看懂使用者說的是什麼意思了，但是我線下沒辦法復現哈

• 開發3：看了使用者錄製的視訊，但是我線下沒辦法重現，也定位不到問題

為了解決以上問題，我們用一套全新的思路來設計線上問題回放體系。

我們可以把Flutter中的手勢系統分兩層概念來理解。第一層概念為原始觸控資料(pointer)，它描述了螢幕上指標（例如，觸控，滑鼠和觸控筆）的時間，型別，位置和移動。 第二層概念為手勢，描述由一個或多個原始移動資料組成的語義動作。一般情況下單獨的原始觸控資料沒有任何意義。原始觸控資料是由系統傳給native，native再通過flutter view channel傳給flutter。

flutter接收native傳來的原始資料介面如下：

2 Flutter UI碰撞測試

當螢幕接收到觸控時，dart Framework會對您的應用程式執行碰撞測試，以確定觸控與螢幕相接的位置存在哪些檢視（renderobject）。 觸控事件然後被分發到最內部的renderobject上。 從最內部renderobject開始，這些事件在renderobject樹中向上冒泡傳遞，通過冒泡傳遞最後把所有的renderobject遍歷出來，從這個傳遞機制可想而知，遍歷出來renderobject列表裡的最後一個是WidgetsFlutterBinding（嚴格來講WidgetsFlutterBinding不是renderobject），後面會介紹到WidgetsFlutterBinding。

上面程式碼以 histTest()檢測當前觸控 pointer event 涉及到哪些檢視。最後通過dispatchEvent(event, result)來處理該事件。

上面的程式碼就是用來分別呼叫每個檢視（RenderObject）的手勢識別器獨自處理當前觸控事件（決定是否接收此事件）。

entry.target是每個widget對應的RenderObject,所有的RenderObject都需要實現（implements）HitTestTarget類的介面，HitTestTarget裡面有就有handleEvent這個介面，所以每個RenderObject都需要實現handleEvent這個介面， 這個介面就是用來處理手勢識別。

除了最後一個WidgetsFlutterBinding外，其他檢視RenderObject呼叫自己的handleEvent來識別手勢，其作用就是判斷當前手勢是否要放棄，如果不放棄則丟到一個路由器裡（這個路由器就是手勢競技場）最後由WidgetsFlutterBinding 呼叫handleEvent統一決議這些手勢識別器最終誰勝出，所以這裡WidgetsFlutterBinding.handleEvent其實就是統一處理介面，它的程式碼如下：

3 Flutter UI手勢決議

從上面的介紹可以得出一次觸控事件可能觸發多個手勢識別器。框架通過讓每個識別器加入一個“手勢競爭場”來決議使用者想要的手勢。“手勢競爭場”使用以下規則來決議哪個手勢勝出，非常簡單。

1. 在任何時候，任何識別器都可以自己宣佈失敗並主動離開“手勢競爭場”。如果在當前“競爭場”中只剩下一個識別器，那麼剩下來的就是贏家，贏家意味著獨自接收此觸控事件並做出響應動作

2. 在任何時候，任何識別器都可以自己宣佈勝利，並且最終就是它勝利，所有剩下的其他識別器都會失敗

4 Flutter UI手勢例子

下面示例表示螢幕window由ABCDEFKG檢視組成，其中A檢視是根檢視，即是最底下的檢視。紅圈表示觸控點位置，觸控落在G檢視的中間位置。

根據碰撞測試，遍歷出響應此觸控事件的檢視路徑： WidgetsFlutterBinding <— A <— C <— K <— G (其中GKCA是renderObject)

遍歷路徑列表後，開始呼叫各自的檢視（GKCA）entry.target.handleEvent來把自己識別器放到競技場裡參加決議，當然有些檢視由於根據自己的邏輯判斷主動放棄識別該觸控事件。這個處理過程如下圖

按G->K->C->A->WidgetsFlutterBinding順序分別呼叫handleEvent()方法，最後通過WidgetsFlutterBinding呼叫自己的handleEvent()介面來統一決議最終哪個手勢識別器勝出。

勝出的那個手勢識別器通過回撥方法回撥到上層業務程式碼，流程如下

錄製流程圖如下：

下面是滾動事件回放流程圖，其他型別手勢的回放原理一樣。

上面的預處理，識別消耗指的是在滾動開始時，手勢識別器要判斷是否符合滾動手勢所需要滾動的距離。

所以我們為了讓其控制元件滾動首先要生成一些觸控點資料，讓手勢識別器識別為滾動事件。這樣才能進行後續的滾動動作。

下面是滾動處理邏輯程式碼，如下：

上面程式碼大概處理邏輯：1.計算滾動方向，每個生成的觸控資料偏移單元 2.計算滾動的開始位置 3.生成滾動原始觸控資料列表 4.迴圈發射原始觸控資料，並計算是否滾動到指定的位置，如果還達不到指定的位置，則繼續補給

生成滾動原始觸控資料列表程式碼如下： 第一資料是down觸控資料，其他都是move觸控資料。up資料在這裡不需要生成，當滾動距離到目標位置後才另外生成up觸控資料。為什麼這樣設計？此處留給大家思考！

迴圈發射原始觸控資料，並判斷是否繼續補給程式碼如下：

我們以定時器不斷的往系統傳送觸控資料，每次傳送資料前都需要判斷是否已經達到目標位置。

0 6

問題回放整體框架圖

下圖包括native和flutter，包括ui和資料。

0 7

• 本文大概介紹了flutter ui手勢問題回放，核心部分由四部分組成，一是flutter手勢原理，二是flutter ui錄製，三是flutter ui回放，四是整個框架圖，由於篇幅有限，這四分部都介紹比較籠統，不夠詳細，請諒解！flutter錄製回放程式碼其實很多，我這裡只是附上比較重要，而且易於理解的程式碼。其他不重要或不易讀懂的程式碼都省掉了。

• 如果對裡面的技術點感興趣，你可以關注我們的公眾號。我們後續會單獨對裡面的技術點詳細深入的分析發文。

• 如果覺得上面有錯誤的地方，請指出。謝謝