本文由阿里閑魚技術(shù)團隊祈晴分享，本次有修訂和改動，感謝作者的技術(shù)分享。

1、內(nèi)容概述

本文總結(jié)了阿里閑魚技術(shù)團隊使用Flutter在對閑魚IM進行移動端跨端改造過程中的技術(shù)實踐等，文中對比了傳統(tǒng)Native與現(xiàn)在大熱的Flutter跨端方案在一些主要技術(shù)實現(xiàn)上的差異，以及針對Flutter技術(shù)特點的具體技術(shù)實現(xiàn)，值得同樣準備使用Flutter開發(fā)IM的技術(shù)同行們借鑒和參考。

學(xué)習(xí)交流：

- 即時通訊/推送技術(shù)開發(fā)交流5群：215477170?[推薦]

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK

（本文同步發(fā)布于：http://www.52im.net/thread-3615-1-1.html）

2、閑魚IM現(xiàn)狀

閑魚IM的移動端框架構(gòu)建于2016至2017年間，期間經(jīng)過多次迭代升級導(dǎo)致歷史包袱累積多，后面又經(jīng)歷IM界面的Flutter化，從而造成了客戶端架構(gòu)愈加復(fù)雜。

從開發(fā)層面總結(jié)閑魚IM移動端當前架構(gòu)主要存在如下幾個問題：

• 1）研發(fā)效率較低：當前架構(gòu)涉及到Android/iOS雙端的邏輯代碼以及Flutter的UI代碼，定位問題往往只能從Flutter UI表相倒查到Native邏輯層；

• 2）架構(gòu)層次較差：架構(gòu)設(shè)計上分層不清晰，業(yè)務(wù)邏輯夾雜在核心的邏輯層致使代碼變更風(fēng)險大；

• 3）性能測試略差：核心數(shù)據(jù)源存儲Native內(nèi)存，需經(jīng)Flutter Plugin將數(shù)據(jù)源序列化上拋Flutter側(cè)，在大批量數(shù)據(jù)源情況下性能表現(xiàn)較差。

從產(chǎn)品層面總結(jié)閑魚IM移動端當前架構(gòu)的主要問題如下：

• 1）定位問題困難：線上輿情反饋千奇百怪，測試始終無法復(fù)現(xiàn)相關(guān)場景，因此很多時候只能靠現(xiàn)象猜測本質(zhì)；

• 2）疑難雜癥較多：架構(gòu)的不穩(wěn)定性造成出現(xiàn)的問題反復(fù)出現(xiàn)，當前疑難雜癥主要包括未讀紅點計數(shù)、iPhone5C低端機以及多媒體發(fā)送等多個問題；

• 3）問題差異性大：Android和iOS兩端邏輯代碼差異大，包括埋點邏輯都不盡相同，排查問題根源時雙端都會有不同根因，解決方案也不相同。

3、業(yè)界的移動端跨端方案

為解決當前IM的技術(shù)痛點，閑魚今年特起關(guān)于IM架構(gòu)升級項目，重在解決客戶端中Andriod和iOS雙端一致性的痛點，初步設(shè)想方案就是實現(xiàn)跨端統(tǒng)一的Android/iOS邏輯架構(gòu)。

在當前行業(yè)內(nèi)跨端方案可初步歸類如下圖架構(gòu)：

在GUI層面的跨端方案有Weex、ReactNative、H5、Uni-APP等，其內(nèi)存模型大多需要通過橋接到Native模式存儲。

在邏輯層面的跨端方案大致有C/C++等與虛擬機無關(guān)語言實現(xiàn)跨端，當然匯編語言也可行。

此外有兩個獨立于上述體系之外的架構(gòu)就是Flutter和KMM（谷歌基于Kotlin實現(xiàn)類似Flutter架構(gòu)），其中Flutter運行特定DartVM，將內(nèi)存數(shù)據(jù)掛載其自身的isolate中。

考慮閑魚是Flutter的前沿探索者，方案上優(yōu)先使用Flutter。然而Flutter的isolate更像一個進程的概念（底層實現(xiàn)非使用進程模式），相比Android，同一進程場景中，Android的Dalvik虛擬機多個線程運行共享一個內(nèi)存Heap，而DartVM的Isolate運行隔離各自的Heap，因而isolate之間通訊方式比較繁瑣（需經(jīng)過序列化反序列化過程）。

整個模型如下圖所示：

若按官方混合架構(gòu)實現(xiàn)Flutter應(yīng)用，開啟多個FlutterAcitivty/FlutterController，底層會生成多個Engine，對應(yīng)會存在多個isolate，而isolate通訊類似于進程通訊（類似socket或AIDL），這里借鑒閑魚FlutterBoost的設(shè)計理念，F(xiàn)lutterIM架構(gòu)將多個頁面的Engine共享，則內(nèi)存模型就天然支持共享讀取。

原理圖如下：

4、閑魚IM基于Flutter的架構(gòu)設(shè)計

4.1 新老架構(gòu)對比

如下圖所示：是一個老架構(gòu)方案，其核心問題主要集中于Native邏輯抽象差，其中邏輯層面還設(shè)計到多線程并發(fā)使得問題倍增，Android/iOS/Flutter交互繁雜，開發(fā)維護成本高，核心層耦合較為嚴重，無插拔式概念.

考慮到歷史架構(gòu)的問題，演進如下新架構(gòu)設(shè)計：

如上圖所示，架構(gòu)從上至下依次為：

• 1）業(yè)務(wù)層；

• 2）分發(fā)層；

• 3）邏輯層；

• 4）數(shù)據(jù)源層。

數(shù)據(jù)源層來源于推送或網(wǎng)絡(luò)請求，其封裝于Native層，通過Flutter插件將消息協(xié)議數(shù)據(jù)上拋到Flutter側(cè)的核心邏輯層，處理完成后變成Flutter DB的Enitity實體，實體中掛載一些消息協(xié)議實體。

核心邏輯層將繁雜數(shù)據(jù)扁平化打包掛載到分發(fā)層中的會話內(nèi)存模型數(shù)據(jù)或消息內(nèi)存模型數(shù)據(jù)，最后通過觀察者模式的訂閱分發(fā)到業(yè)務(wù)邏輯中。

Flutter IM重點集中改造邏輯層和分發(fā)層，將IM核心邏輯和業(yè)務(wù)層面數(shù)據(jù)模型進行封裝隔離，核心邏輯層和數(shù)據(jù)庫交互后將數(shù)據(jù)封裝到分發(fā)層的moduleData中，通過訂閱方式分發(fā)到業(yè)務(wù)層數(shù)據(jù)模型中。

此外在IM模型中DB也是重點依賴的，個人對DB數(shù)據(jù)庫管理進行全面封裝解，實現(xiàn)一種輕量級，性能佳的Flutter DB管理框架。

4.2 DB存儲模型

Flutter IM架構(gòu)的DB存儲依賴數(shù)據(jù)庫插件，目前主流插件是Sqflite。

其存儲模型如下：

依據(jù)上圖Sqflite插件的DB存儲模型會有2個等待隊列：

• 一個是Flutter層同步執(zhí)行隊列；

• 一個是Native層的線程執(zhí)行隊列。

其Android實現(xiàn)機制是HandlerThread，因此Query/Save讀寫在會同一線程隊列中，導(dǎo)致響應(yīng)速度慢，容易造成DB SQL堆積，此外缺失緩存模型。

于是個人定制如下改進方案：

Flutter側(cè)通過表的主鍵設(shè)計查詢時候會優(yōu)先從Entity Cache層去獲取，若緩存不存在，則通過Sqflite插件查詢。

同時改造Sqflite插件成支持sync/Async同步異步兩種方式操作，對應(yīng)到Native側(cè)也會有同步線程隊列和異步線程隊列，保證數(shù)據(jù)吞吐率。但是這里建議查詢使用異步，存儲使用同步更穩(wěn)妥，主要怕出現(xiàn)多個相同的數(shù)據(jù)元model同一時間進入異步線程池中，存儲先后順序無法有效的保證。

4.3 ORM數(shù)據(jù)庫方案

IM架構(gòu)重度依賴DB數(shù)據(jù)庫，而當前業(yè)界還沒有一個完備的數(shù)據(jù)庫ORM管理方案，參考了Android的OrmLite/GreenDao，個人自行設(shè)計一套Flutter ORM數(shù)據(jù)庫管理方案。

其核心思想如下：

由于Flutter不支持反射，因此無法直接像Android的開源數(shù)據(jù)庫方式操作，但可通過APT方式，將Entity和Orm Entity綁定于一身，操作OrmEntity即操作Entity，整個代碼風(fēng)格設(shè)計也和OrmLite極其相似。

參考代碼如下：

4.4 IM內(nèi)存數(shù)據(jù)模型

基于Flutter的IM移動端架構(gòu)在內(nèi)存數(shù)據(jù)模型主要劃分為會話和消息兩個顆粒度：

• 1）會話內(nèi)存數(shù)據(jù)模型交托于SessionModuleData：會話內(nèi)存數(shù)據(jù)有一個根節(jié)點RootNotice，然后其掛載PSessionMessageNotice（這里PSessionMessageNotice是ORM映射的會話DB表模型）子節(jié)點集合。

• 2）消息內(nèi)存數(shù)據(jù)模型交托于MessageModuleData：消息內(nèi)存數(shù)據(jù)會有一個MessageConatiner容器管理，其內(nèi)部掛載此會話中的PMessage(PMessage是ORM映射的消息DB表模型)消息集合。

依據(jù)上一章節(jié)，PSessionMessageNotice設(shè)計了一個OrmEnitity Cache，考慮到IM中會話數(shù)是有限的，因此PSessionMessageNotice都是直接緩存到Cache中。

這種做法的好處是各地去拿會話數(shù)據(jù)元時候都是緩存中同一個對象，容易保證多次重復(fù)讀寫的數(shù)據(jù)一致性。而PSessionMessageNotice考慮到其數(shù)量可以無限多的特殊性，因此這里將其掛載到MessageContainer的內(nèi)存管理中，在退出會話的時機會校驗容器中PMessage集合的數(shù)量，適當縮容可以減少內(nèi)存開銷。

模型如下圖所示：

4.5 狀態(tài)管理方案

基于Flutter的IM移動端架構(gòu)狀態(tài)管理方案比較簡單，對數(shù)據(jù)源Session/Message維度使用觀察者模式的訂閱分發(fā)方式實現(xiàn)，架構(gòu)類似于EventBus模式，頁面級的狀態(tài)管理無論使用fish-redux、scopeModel或者provider幾乎影響面不大，核心還是需保留一種插拔式抽象更重要。

架構(gòu)如下圖：

4.6 IM同步模型方案

當前現(xiàn)狀的消息同步模型：

如上圖所示是，模型中存在ACCS Thread/Main Thread/Region Thread等多線程并發(fā)場景，導(dǎo)致易出現(xiàn)多線程高并發(fā)的問題。

native的推送和網(wǎng)絡(luò)請求同步的隔離方案通過Lock的鎖機制，并且通過隊列降頻等方式處理，流程繁瑣且易出錯。整體通過Region Version Gap去判斷是否有域空洞，進而執(zhí)行域同步補充數(shù)據(jù)。

改進的同步模型如下：

如上圖所示，在Flutter側(cè)天然沒多線程場景，通過一種標記位的轉(zhuǎn)化同步異步實現(xiàn)類似Handler消息隊列，架構(gòu)清晰簡約了很多，避免鎖帶來的開銷以及同步問題。

5、本次改造進展以及性能對比

1）針對架構(gòu)層面：

在基于Flutter的IM架構(gòu)中，重點將雙端邏輯差異性統(tǒng)一成同一份Dart代碼，完全磨平Android/iOS的代碼差異性帶來的問題。

帶來的好處很明顯：

• 1）降低開發(fā)維護、測試回歸、視覺驗收的一半成本，極大提高研發(fā)效率；

• 2）架構(gòu)上進行重構(gòu)分層，實現(xiàn)一種解耦合，插拔式的IM架構(gòu)；

• 3）同時Native到Flutter側(cè)的大量數(shù)據(jù)上拋序列化過程改造程Flutter引用傳遞，解決極限測試場景下的私聊卡頓問題。

2）針對線上輿情：

• 1）補齊UT和TLog的集團日志方式做到可追蹤，可排查；

• 2）針對于很多現(xiàn)存的疑難雜癥重點集中專項解決，比如iphone5C的架構(gòu)在Flutter側(cè)統(tǒng)一規(guī)劃；

• 3）未讀紅點計數(shù)等問題也在架構(gòu)模型升級中修復(fù)；

• 4）此外多媒體音視頻發(fā)送模塊進行改造升級。

3）性能數(shù)據(jù)對比：

當IM架構(gòu)的邏輯層和UI層都切換成Flutter后，和原先架構(gòu)模式初步對比，整體內(nèi)存水位持平。

其中：

• 1）私聊場景下小米9測試結(jié)構(gòu)內(nèi)存下降40M，功耗降低4mah，CPU降低1%；

• 2）極限測試場景下新架構(gòu)內(nèi)存數(shù)據(jù)相比于舊架構(gòu)有一個較為明顯的改觀（主要由于兩個界面都使用Flutter場景下，頁面切換的開銷降低很多）。

6、未來展望

JS跨端不安全，C++跨端成本有點高，F(xiàn)lutter會是一個較好選擇。彼時閑魚FlutterIM架構(gòu)升級根本目的從來不是因Flutter而Flutter，是由于歷史包袱的繁重，代碼層面的維護成本高，新業(yè)務(wù)的擴展性差，人力配比不協(xié)調(diào)以及疑難雜癥的輿情持續(xù)反饋等等因素造成我們不得不去探索新方案。

經(jīng)過閑魚IM超復(fù)雜業(yè)務(wù)場景驗證Flutter模式的邏輯跨端可行性，閑魚在Flutter路上會一直保持前沿探索，最后能反饋到生態(tài)圈。

總結(jié)一句話，探索過程在于你勇于邁出第一步，后面才會不斷驚喜發(fā)現(xiàn)。

（原文鏈接：點此進入，本次有修訂和改動）

附錄：更多文章匯總

[1] 更多阿里團隊的文章分享：

《阿里釘釘技術(shù)分享：企業(yè)級IM王者——釘釘在后端架構(gòu)上的過人之處》

《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲方案探討》

《阿里技術(shù)分享：深度揭秘阿里數(shù)據(jù)庫技術(shù)方案的10年變遷史》

《阿里技術(shù)分享：阿里自研金融級數(shù)據(jù)庫OceanBase的艱辛成長之路》

《來自阿里OpenIM：打造安全可靠即時通訊服務(wù)的技術(shù)實踐分享》

《釘釘——基于IM技術(shù)的新一代企業(yè)OA平臺的技術(shù)挑戰(zhàn)(視頻+PPT) [附件下載]》

《阿里技術(shù)結(jié)晶：《阿里巴巴Java開發(fā)手冊(規(guī)約)-華山版》[附件下載]》

《重磅發(fā)布：《阿里巴巴Android開發(fā)手冊(規(guī)約)》[附件下載]》

《作者談《阿里巴巴Java開發(fā)手冊(規(guī)約)》背后的故事》

《《阿里巴巴Android開發(fā)手冊(規(guī)約)》背后的故事》

《干了這碗雞湯：從理發(fā)店小弟到阿里P10技術(shù)大?！?/p>

《揭秘阿里、騰訊、華為、百度的職級和薪酬體系》

《淘寶技術(shù)分享：手淘億級移動端接入層網(wǎng)關(guān)的技術(shù)演進之路》

《難得干貨，揭秘支付寶的2維碼掃碼技術(shù)優(yōu)化實踐之路》

《淘寶直播技術(shù)干貨：高清、低延時的實時視頻直播技術(shù)解密》

《阿里技術(shù)分享：電商IM消息平臺，在群聊、直播場景下的技術(shù)實踐》

《阿里技術(shù)分享：閑魚IM基于Flutter的移動端跨端改造實踐》

?

[2] 更多IM開發(fā)綜合文章：

《新手入門一篇就夠：從零開發(fā)移動端IM》

《移動端IM開發(fā)者必讀(一)：通俗易懂，理解移動網(wǎng)絡(luò)的“弱”和“慢”》

《移動端IM開發(fā)者必讀(二)：史上最全移動弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)》

《從客戶端的角度來談?wù)勔苿佣薎M的消息可靠性和送達機制》

《現(xiàn)代移動端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請求速度、弱網(wǎng)適應(yīng)、安全保障》

《移動端IM中大規(guī)模群消息的推送如何保證效率、實時性？》

《移動端IM開發(fā)需要面對的技術(shù)問題》

《開發(fā)IM是自己設(shè)計協(xié)議用字節(jié)流好還是字符流好？》

《IM消息送達保證機制實現(xiàn)(一)：保證在線實時消息的可靠投遞》

《IM消息送達保證機制實現(xiàn)(二)：保證離線消息的可靠投遞》

《如何保證IM實時消息的“時序性”與“一致性”？》

《一個低成本確保IM消息時序的方法探討》

《IM單聊和群聊中的在線狀態(tài)同步應(yīng)該用“推”還是“拉”？》

《IM群聊消息如此復(fù)雜，如何保證不丟不重？》

《談?wù)勔苿佣?IM 開發(fā)中登錄請求的優(yōu)化》

《移動端IM登錄時拉取數(shù)據(jù)如何作到省流量？》

《淺談移動端IM的多點登錄和消息漫游原理》

《完全自已開發(fā)的IM該如何設(shè)計“失敗重試”機制？》

《通俗易懂：基于集群的移動端IM接入層負載均衡方案分享》

《微信對網(wǎng)絡(luò)影響的技術(shù)試驗及分析（論文全文）》

《開源IM工程“蘑菇街TeamTalk”的現(xiàn)狀：一場有始無終的開源秀》

《如約而至：微信自用的移動端IM網(wǎng)絡(luò)層跨平臺組件庫Mars已正式開源》

《子彈短信光鮮的背后：網(wǎng)易云信首席架構(gòu)師分享億級IM平臺的技術(shù)實踐》

《微信技術(shù)分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》

《自已開發(fā)IM有那么難嗎？手把手教你自擼一個Andriod版簡易IM (有源碼)》

《融云技術(shù)分享：解密融云IM產(chǎn)品的聊天消息ID生成策略》

《IM開發(fā)基礎(chǔ)知識補課(六)：數(shù)據(jù)庫用NoSQL還是SQL？讀這篇就夠了！》

《適合新手：從零開發(fā)一個IM服務(wù)端（基于Netty，有完整源碼）》

《拿起鍵盤就是干：跟我一起徒手開發(fā)一套分布式IM系統(tǒng)》

《適合新手：手把手教你用Go快速搭建高性能、可擴展的IM系統(tǒng)(有源碼)》

《IM里“附近的人”功能實現(xiàn)原理是什么？如何高效率地實現(xiàn)它？》

《IM“掃一掃”功能很好做？看看微信“掃一掃識物”的完整技術(shù)實現(xiàn)》

《IM消息ID技術(shù)專題(一)：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》

《IM消息ID技術(shù)專題(二)：微信的海量IM聊天消息序列號生成實踐（容災(zāi)方案篇）》

《IM消息ID技術(shù)專題(三)：解密融云IM產(chǎn)品的聊天消息ID生成策略》

《IM消息ID技術(shù)專題(四)：深度解密美團的分布式ID生成算法》

《IM消息ID技術(shù)專題(五)：開源分布式ID生成器UidGenerator的技術(shù)實現(xiàn)》

《IM消息ID技術(shù)專題(六)：深度解密滴滴的高性能ID生成器(Tinyid)》

《IM開發(fā)寶典：史上最全，微信各種功能參數(shù)和邏輯規(guī)則資料匯總》

《IM開發(fā)干貨分享：我是如何解決大量離線消息導(dǎo)致客戶端卡頓的》

《零基礎(chǔ)IM開發(fā)入門(一)：什么是IM系統(tǒng)？》

《零基礎(chǔ)IM開發(fā)入門(二)：什么是IM系統(tǒng)的實時性？》

《零基礎(chǔ)IM開發(fā)入門(三)：什么是IM系統(tǒng)的可靠性？》

《零基礎(chǔ)IM開發(fā)入門(四)：什么是IM系統(tǒng)的消息時序一致性？》

《IM開發(fā)干貨分享：如何優(yōu)雅的實現(xiàn)大量離線消息的可靠投遞》

《IM開發(fā)干貨分享：有贊移動端IM的組件化SDK架構(gòu)設(shè)計實踐》

《一套億級用戶的IM架構(gòu)技術(shù)干貨(下篇)：可靠性、有序性、弱網(wǎng)優(yōu)化等》

《IM掃碼登錄技術(shù)專題(一)：微信的掃碼登錄功能技術(shù)原理調(diào)試分析》

《IM掃碼登錄技術(shù)專題(二)：市面主流的掃碼登錄技術(shù)原理調(diào)試分析》

《IM掃碼登錄技術(shù)專題(三)：通俗易懂，IM掃碼登錄功能詳細原理一篇就夠》

《理解IM消息“可靠性”和“一致性”問題，以及解決方案探討》

《阿里技術(shù)分享：閑魚IM基于Flutter的移動端跨端改造實踐》

>>?更多同類文章 ……

本文已同步發(fā)布于“即時通訊技術(shù)圈”公眾號。

▲ 本文在公眾號上的鏈接是：點此進入。同步發(fā)布鏈接是：http://www.52im.net/thread-3615-1-1.html