資安

Flutter IM跨端架構設計和實現

作者:閒魚技術——祈晴

1. 閒魚IM現狀

閒魚IM框架構建於2016-2017年,期間多次迭代升級導致歷史包袱累積多,後經IM界面Flutter化,造成架構更復雜,開發層面總結閒魚當前架構主要存在如下幾個問題:

  • 研發效率較低:當前架構開發需求涉及到Android/iOS雙端的邏輯代碼以及Flutter的UI界面代碼,定位問題往往只能從Flutter UI表相追查到Native邏輯漏洞;
  • 架構層次較差:架構設計上分層不清晰,業務邏輯夾雜在核心的邏輯層致使代碼變更風險大;
  • 性能測試略差:核心數據源存儲Native內存,需經Flutter Plugin將數據源序列化上拋Flutter側,在大批量數據源情況下性能表現較差;

從輿情層面總結閒魚IM當前架構的主要問題如下:

  • 定位問題困難:線上輿情反饋千奇百怪,測試始終無法復現相關場景,因此很多時候只能靠現象猜測本質;
  • 疑難雜症較多:架構不穩定性造成出現的問題反覆出現,當前疑難雜症主要包括未讀紅點計數,iPhone5C低端機器架構,以及多媒體發送等多個問題;
  • 問題差異性大:Android和iOS兩端邏輯代碼差異大,包括現存埋點邏輯都不盡相同,因此排查問題根源時候雙端都會有不同問題根因,解決問題方案也不相同;

2.業界跨端方案

為解決當前IM痛點,閒魚今年特起關於IM架構升級項目,重在解決客戶端中雙端一致性痛點,初步設想方案就是實現跨端統一的Android/iOS邏輯架構;在當前行業內跨端方案可初步歸類如下圖架構,在GUI層面的跨端方案有Weex,ReactNative,H5,Uni-APP等,其內存模型大多需要通過橋接到Native模式存儲;在邏輯層面的跨端方案大致有C/C++等與虛擬機無關語言實現跨端,當然彙編語言也可行;此外有兩個獨立於上述體系之外的架構就是Flutter和KMM(谷歌基於Kotlin實現類似Flutter架構),其中Flutter運行特定DartVM,將內存數據掛載其自身的isolate中;
undefined

考慮閒魚是Flutter的前沿探索者,方案上優先使用Flutter;然而Flutter的isolate更像一個進程的概念(底層實現非使用進程模式),相比Android,同一進程場景中,Android的Dalvik虛擬機多個線程運行共享一個內存Heap,而DartVM的Isolate運行隔離各自的Heap,因而isolate之間通訊方式比較繁瑣(需經過序列化反序列化過程);整個模型如下圖所示:
undefined

若按官方混合架構實現Flutter應用,開啟多個FlutterAcitivty/FlutterController,底層會生成多個Engine,對應會存在多個isolate,而isolate通訊類似於進程通訊(類似socket或AIDL),這裡借鑑閒魚FlutterBoost的設計理念,FlutterIM架構將多個頁面的Engine共享,則內存模型就天然支持共享讀取,原理圖如下:

undefined

3.Flutter IM架構設計

3.1 新老架構對比

如下圖是一個老架構方案,其核心問題主要集中於Native邏輯抽象差,其中邏輯層面還設計到多線程併發使得問題倍增,Android/iOS/Flutter交互繁雜,開發維護成本高,核心層耦合較為嚴重,無插拔式概念;
undefined

考慮到歷史架構的問題,演進如下新架構設計
undefined

架構從上至下依次為業務層分發層邏輯層以及數據源層,數據源層來源於推送或網絡請求,其封裝於Native層,通過Flutter插件將消息協議數據上拋到Flutter側的核心邏輯層,處理完成後變成Flutter DB的Enitity實體,實體中掛載一些消息協議實體;核心邏輯層將繁雜數據扁平化打包掛載到分發層中的會話內存模型數據或消息內存模型數據,最後通過觀察者模式的訂閱分發到業務邏輯中;Flutter IM重點集中改造邏輯層和分發層,將IM核心邏輯和業務層面數據模型進行封裝隔離,核心邏輯層和數據庫交互後將數據封裝到分發層的moduleData中,通過訂閱方式分發到業務層數據模型中;此外在IM模型中DB也是重點依賴的,個人對DB數據庫管理進行全面封裝解,實現一種輕量級,性能佳的Flutter DB管理框架;

3.2 DB存儲模型

Flutter IM架構的DB存儲依賴數據庫插件,目前主流插件是Sqflite,其存儲模型如下:
undefined
依據上圖Sqflite插件的DB存儲模型會有2個等待隊列,一個是Flutter層同步執行隊列,一個是Native層的線程執行隊列,其Android實現機制是HandlerThread,因此Query/Save讀寫在會同一線程隊列中,導致響應速度慢,容易造成DB SQL堆積,此外缺失緩存模型,於是個人定製如下改進方案
undefined
Flutter側通過表的主鍵設計查詢時候會優先從Entity Cache層去獲取,若緩存不存在,則通過Sqflite插件查詢,同時改造Sqflite插件成支持sync/Async同步異步兩種方式操作,對應到Native側也會有同步線程隊列和異步線程隊列,保證數據吞吐率;但是這裡建議查詢使用異步,存儲使用同步更穩妥,主要怕出現多個相同的數據元model同一時間進入異步線程池中,存儲先後順序無法有效的保證;

3.3 ORM數據庫方案

IM架構重度依賴DB數據庫,而當前業界還沒有一個完備的數據庫ORM管理方案,參考了Android的OrmLite/GreenDao,個人自行設計一套Flutter ORM數據庫管理方案,其核心思想如下:
undefined
由於Flutter不支持反射,因此無法直接像Android的開源數據庫方式操作,但可通過APT方式,將Entity和Orm Entity綁定於一身,操作OrmEntity即操作Entity,整個代碼風格設計也和OrmLite極其相似,參考代碼如下:

undefined

3.4 IM內存數據模型

FlutterIM架構在內存數據模型主要劃分為會話和消息兩個顆粒度,會話內存數據模型交託於SessionModuleData,消息內存數據模型交託於MessageModuleData;會話內存數據有一個根節點RootNotice,然後其掛載PSessionMessageNotice(這裡PSessionMessageNotice是ORM映射的會話DB表模型)子節點集合;消息內存數據會有一個MessageConatiner容器管理,其內部掛載此會話中的PMessage(PMessage是ORM映射的消息DB表模型)消息集合;

依據上一章節,PSessionMessageNotice設計了一個OrmEnitity Cache,考慮到IM中會話數是有限的,因此PSessionMessageNotice都是直接緩存到Cache中,這種做法的好處是各地去拿會話數據元時候都是緩存中同一個對象,容易保證多次重複讀寫的數據一致性;而PSessionMessageNotice考慮到其數量可以無限多的特殊性,因此這裡將其掛載到MessageContainer的內存管理中,在退出會話的時機會校驗容器中PMessage集合的數量,適當縮容可以減少內存開銷,模型如下圖所示:
undefined

3.5 狀態管理方案

Flutter IM狀態管理方案比較簡單,對數據源Session/Message維度使用觀察者模式的訂閱分發方式實現,架構類似於EventBus模式,頁面級的狀態管理無論使用fish-redux,scopeModel或者provider幾乎影響面不大,核心還是需保留一種插拔式抽象更重要;架構如下圖:
undefined

3.6 IM同步模型方案

如下是當前現狀的消息同步模型,模型中存在ACCS Thread/Main Thread/Region Thread等多線程併發場景,導致易出現多線程高併發的問題;native的推送和網絡請求同步的隔離方案通過Lock的鎖機制,並且通過隊列降頻等方式處理,流程繁瑣且易出錯。整體通過Region Version Gap去判斷是否有域空洞,進而執行域同步補充數據。
undefined
改進的同步模型如下,在Flutter側天然沒多線程場景,通過一種標記位的轉化同步異步實現類似Handler消息隊列,架構清晰簡約了很多,避免鎖帶來的開銷以及同步問題,
undefined

4.進展以及性能對比

  • 針對架構層面:在FlutterIM架構中,重點將雙端邏輯差異性統一成同一份Dart代碼,完全磨平Android/iOS的代碼差異性帶來的問題,降低開發維護,測試迴歸,視覺驗收的一半成本,極大提高研發效率;架構上進行重構分層,實現一種解耦合,插拔式的IM架構;同時Native到Flutter側的大量數據上拋序列化過程改造程Flutter引用傳遞,解決極限測試場景下的私聊卡頓問題;
  • 針對線上輿情:補齊UT和TLog的集團日誌方式做到可追蹤,可排查;另外針對於很多現存的疑難雜症重點集中專項解決,比如iphone5C的架構在Flutter側統一規劃,未讀紅點計數等問題也在架構模型升級中修復,此外多媒體音視頻發送模塊進行改造升級;
  • 性能數據對比:當IM架構的邏輯層和UI層都切換成Flutter後,和原先架構模式初步對比,整體內存水位持平,其中私聊場景下小米9測試結構內存下降40M,功耗降低4mah,CPU降低1%;極限測試場景下新架構內存數據相比於舊架構有一個較為明顯的改觀,主要由於兩個界面都使用Flutter場景下,頁面切換的開銷降低很多;

5.展望

JS跨端不安全,C++跨端成本有點高,Flutter會是一個較好選擇;彼時閒魚FlutterIM架構升級根本目的從來不是因Flutter而Flutter,是由於歷史包袱的繁重,代碼層面的維護成本高,新業務的擴展性差,人力配比不協調以及疑難雜症的輿情持續反饋等等因素造成我們不得不去探索新方案。經過閒魚IM超複雜業務場景驗證Flutter模式的邏輯跨端可行性,閒魚在Flutter路上會一直保持前沿探索,最後能反饋到生態圈;總結一句話,探索過程在於你勇於邁出第一步,後面才會不斷驚喜發現

Leave a Reply

Your email address will not be published. Required fields are marked *