Flutter Worker —— 閒魚這樣實現“邏輯跨平臺”

閒魚技術發表於2021-03-11

作者:閒魚技術——鹿緣

閒魚社群主要頁面採用Native實現,部分使用Flutter和Weex承接。帖子、話題等固定資料結構的處理,點贊、評論等使用者互動和狀態同步,這些資料邏輯大部分是重複的,而且在多技術棧實現性價極低。由此我們想,能否在端上實現這樣的一套工具,解放勞動力的同時,擺脫對服務端BFF層的依賴,保證研發效能。 抽象地看,實際上我們需要的正是一個邏輯跨平臺工具。邏輯跨平臺概念由來已久,也有一些很優秀的方案可以參考:

•C++語言在Objective-C/Java等Native語言都有成熟介面可以呼叫,這使得C++有天然的跨平臺優勢。同時不可否認的,C++入門門檻會比較高,導致後期維護成本大。

•KMM是JetBrains推出的用於跨平臺移動開發SDK,提供了一個語言級別的邏輯跨平臺解決方案,可以將直接程式碼編譯為與目標平臺完全相同的格式。

結合團隊內現有的一些技術基建,最終我們使用Dart完成了這一設計,在不同平臺保證資料和邏輯處理的一致性,節約人力資源的同時保證使用者體驗。取名Flutter Worker。

整體架構設計

在進行整體的設計之前,首先限定worker的業務場景:目標是提供一個多端可複用的邏輯處理中心,端上發起資料請求,所有的邏輯處理在FlutterWorker收口,執行完成返回回撥給端上。設想中,在worker寫Handler只需要關注邏輯處理,對於資料的傳入和在端上的接收,開發者只需要指定型別,worker會自動把資料轉化成該型別。

由此,在整體的架構設計中,我們主要考慮一下幾個方面:

1.FlutterWorker需要一個穩定的執行環境,由於涉及到資料處理等可能會比較耗時的操作,需要保證不影響UI介面的繪製。2.處理後的資料要供給多端使用,資料結構必須對齊。3.提供足夠的切面,方便接入方擴充。4.為了保證執行時穩定可靠,需要新增監控及時發現問題,並且在上線前時,對效能進行測試評估。

整體的架構圖如下:

image.png執行容器層:容器是worker執行的基礎,在保證效能的前提下,要儘可能的利用閒魚現有的技術基建。

狀態管理層:worker在這裡完成資料的儲存和狀態的同步。端上儲存狀態資料,通過訂閱狀態訊息來接收資料的變動。考慮到狀態管理層在目前沒有業務的強需求,這部分僅停留在Demo階段還未落地,後面不再進行闡述。

資料處理層:包含了worker所有的中間層資料處理部分,主要包括Model物件同步、資料轉換和資料型別同步。基礎資料型別在Dart語言中天然支援,在iOS端Androiddr端都有對應的型別,因此,worker工作主要在後兩者。

監控層:worker線上上執行,需要有監控來保障,及時發現問題及時響應。

下面對各個模組進行詳細的介紹。

執行容器層

FlutterWorker的執行環境強依賴FlutterEngine和Isolate,從這個角度來考慮,對以下三種方案做了梳理和對比。

image.png

值得一提的是,隨著Flutter2.0推出,我們在更新日誌中注意到有一項對多開Flutter Engine例項記憶體消耗的優化。據官方文件稱,額外Flutter引擎的靜態記憶體佔用量降低了約 99%,使每個例項的佔用量大約為180KB。結合原始碼來看,這裡是新提供了FlutterEngineGroup類來建立Flutter Engine。

image.png

相較於原來的API,FlutterEngineGroup 生成的FlutterEngine具有常用共享資源(例如 GPU 上下文、字型度量和隔離執行緒的快照)的效能優勢,從而加快首次渲染的速度、降低延遲並降低記憶體佔用。

同時 EngineGroup 本身和其生成的 FlutterEngine不需要持續保活,只要有 1 個可用的FlutterEngine,就可以隨時在各個 FlutterEngine 之間共享資源。EngineGroup銷燬後,已生成的FlutterEngine也不受影響,只是無法繼續在現有共享的基礎上建立新引擎。

雖然現在FlutterEngineGroup還不是一個穩定API,但是這為FlutterWorker提供了另一種可能。綜合考慮,目前實現選擇了方案3來實現。

資料處理層

從使用者呼叫開始,worker的資料流圖如下圖所示:

image.png

資料在三端的流通,是通過呼叫NatiaveWorker,執行到對應的WorkerHandler,處理完成後再以非同步的方式回撥到Native方法。中間主要涉及Model物件同步和資料轉換過程,worker對這裡分別實現了處理庫。

Model物件同步

worker首先要實現的是,是OringinDataModel ==> TargetDataModel。TargetDataModel的定義在 iOS/Android/Flutter 三端的表現形式要保持一致,直接用程式碼生成是最好的選擇。這裡參考一些硬體協議,指定IDL格式來生成三端Model並匯入工程。封裝的dartGen庫可以解析這些yaml節點,生成我們需要的胖Model。

image.png

方便開發者使用,dartGen打包成了cli工具。模仿GsonFormat外掛,json資料在IDE中可以方便轉成對應的dartGen可以解析的yaml協議。對於其他生成Model的需求,可以以很小的代價修改模板,定製化高。

資料轉換

通過Flutter的MethodChannel向Native傳輸資料,需要經過一層messager編碼,而且編碼資料為基礎型別。所以在BinaryMessager的基礎上,封裝了WorkerBinaryMessenger方便做定製化處理。

iOS端和Android端有成熟的model轉換庫(YYModel和FastJson)。在Dart這裡,基於fish_serializable同樣做了一些定製處理,在生成的Model裡提供toJson和fromJson方法等,保證各種型別資料,包括Map和List等內包泛型類,能夠很方便地進行轉換。

監控方案設計

每個監控方案都有其業務場景的侷限性,在目前階段,主要考慮邏輯一致性。worker內單次的邏輯閉環類似tcp握手和揮手的過程,應用內的資料流轉類似訊息佇列,其傳遞過程如圖:截圖2020-10-26 下午4.20.33.png

由此我們確定workerMonitor執行的流程圖如下:image.png

效能監控

在該模式下的主流監控方案,會根據時間切片來觀察 發起方/接收方的佇列資料情況,時間切片有兩種方式,第一種是設定定時器,第二種是在每次有資料呼叫時處理。

切片方案

優點

缺點

定時器切片

切片實現簡單,切片內資料精準

效能損耗大,會有很多的無效統計

每次呼叫切片

效能損耗小

切片內資料為平均值
丟失應用內最後一段切片資料
首段資料阻塞時無法監控

另外上報的方式也分為實時上報和聚合上報。考慮到目前worker的使用場景有閒時和忙時的明顯區分,並且端上的長駐的頻繁的定時上報任務對ui繪製會有一定影響,最終採用每次資料呼叫時統計佇列內資料,同時在每次呼叫後增加超時定時器,如果有下次呼叫則取消超時定時器。

指標

線上上監控指標建設方面,參考rabbitmq監控,先定義初期需要觀測的指標。初期核心關注訊息丟失的情況和訊息時延長的情況。由此我們確定指標如下:

指標.png

Exception監控

參考ui引擎對crash的監控,會在入口函式處統一接受異常資訊以及異常堆疊,然後統一上報處理。這裡在閒魚公眾號Flutter高可用相關文章中有詳細介紹。

可行性驗證

最後實現完成,呼叫程式碼及對應的Handler示例如下:

•iOS端:

image.png

•Android端:

image.png

•Handler:

image.png為了測試我們的方案能否達到上線標準,在會玩首頁場景下做暴力測試來驗證。對比正常Native程式碼和worker處理資料,測試多次併發訪問/有序訪問條件下CPU、記憶體以及時延等表現。

通過多次對比試驗,FlutterWorker方案在常見和高壓的請求場景下短期記憶體和cpu水位增量少於30M,長期記憶體和cpu水位增量小於5M,並且時延低於原有方案的5%。

三端接入後,資料處理只需要投入一個人力就可供多端使用,大量減少了重複工作,提升了研發效能。

總結和展望

當前跨平臺是移動開發的趨勢之一,各個公司、團隊各有建樹,百家爭鳴。究其根本目的都是想提升研發效率,降低維護成本。各個方案都各有自己的獨特優勢,應該理性分析團隊和業務的現狀,選擇適合的方案。

Flutter Worker從邏輯跨平臺的視角切入,取得了一些不錯的效果。不過我們目前只完成了小部分的工作,仍有很多未完善的地方,在未來主要會從下面幾個方面繼續深入研究:

1.MethodChannel優化。資料通道的通訊強依賴MethodChannel,從目前測試結果來其效能表現可以cover目前的業務場景,但長遠來看,通道會成為worker效能瓶頸。從dart_native庫得到啟發,以型別對映指標的方式來替代原生的通道是一條可行的路。2.單元測試。邏輯處理函式有明確的輸入和輸出,寫單測的效率很高。而且快速迭代的產品,很多是在原有的邏輯基礎上新增新的邏輯,寫單測的價效比較高。3.前端容器支援。先行版本只支援了iOS、Android和Flutter,對於Weex和H5前端頁面並沒有很好的支援,未來期望能夠提供優雅的方式接入前端容器。

這是閒魚在Flutter探索道路上做的一點小嚐試,歡迎大家保持關注。

相關文章