本文由阿里閑魚技術團隊祈晴分享，本次有修訂和改動，感謝作者的技術分享。
1、內容概述
本文總結了阿里閑魚技術團隊使用Flutter在對閑魚IM進行移動端跨端改造過程中的技術實踐等，文中對比了傳統Native與現在大熱的Flutter跨端方案在一些主要技術實現上的差異，以及針對Flutter技術特點的具體技術實現，值得同樣準備使用Flutter開發IM的技術同行們借鑒和參考。
學習交流：
（本文同步發布于：http://www.52im.net/thread-3615-1-1.html）
2、閑魚IM現狀
閑魚IM的移動端框架構建于2016至2017年間，期間經過多次迭代升級導致歷史包袱累積多，后面又經歷IM界面的Flutter化，從而造成了客戶端架構愈加復雜。
從開發層面總結閑魚IM移動端當前架構主要存在如下幾個問題：
- 1）研發效率較低：當前架構涉及到Android/iOS雙端的邏輯代碼以及Flutter的UI代碼，定位問題往往只能從Flutter UI表相倒查到Native邏輯層；
- 2）架構層次較差：架構設計上分層不清晰，業務邏輯夾雜在核心的邏輯層致使代碼變更風險大；
- 3）性能測試略差：核心數據源存儲Native內存，需經Flutter Plugin將數據源序列化上拋Flutter側，在大批量數據源情況下性能表現較差。
從產品層面總結閑魚IM移動端當前架構的主要問題如下：
- 1）定位問題困難：線上輿情反饋千奇百怪，測試始終無法復現相關場景，因此很多時候只能靠現象猜測本質；
- 2）疑難雜癥較多：架構的不穩定性造成出現的問題反復出現，當前疑難雜癥主要包括未讀紅點計數、iPhone5C低端機以及多媒體發送等多個問題；
- 3）問題差異性大：Android和iOS兩端邏輯代碼差異大，包括埋點邏輯都不盡相同，排查問題根源時雙端都會有不同根因，解決方案也不相同。
3、業界的移動端跨端方案
為解決當前IM的技術痛點，閑魚今年特起關于IM架構升級項目，重在解決客戶端中Andriod和iOS雙端一致性的痛點，初步設想方案就是實現跨端統一的Android/iOS邏輯架構。
在當前行業內跨端方案可初步歸類如下圖架構：
在GUI層面的跨端方案有Weex、ReactNative、H5、Uni-APP等，其內存模型大多需要通過橋接到Native模式存儲。
在邏輯層面的跨端方案大致有C/C++等與虛擬機無關語言實現跨端，當然匯編語言也可行。
此外有兩個獨立于上述體系之外的架構就是Flutter和KMM（谷歌基于Kotlin實現類似Flutter架構），其中Flutter運行特定DartVM，將內存數據掛載其自身的isolate中。
考慮閑魚是Flutter的前沿探索者，方案上優先使用Flutter。然而Flutter的isolate更像一個進程的概念（底層實現非使用進程模式），相比Android，同一進程場景中，Android的Dalvik虛擬機多個線程運行共享一個內存Heap，而DartVM的Isolate運行隔離各自的Heap，因而isolate之間通訊方式比較繁瑣（需經過序列化反序列化過程）。
整個模型如下圖所示：
若按官方混合架構實現Flutter應用，開啟多個FlutterAcitivty/FlutterController，底層會生成多個Engine，對應會存在多個isolate，而isolate通訊類似于進程通訊（類似socket或AIDL），這里借鑒閑魚FlutterBoost的設計理念，FlutterIM架構將多個頁面的Engine共享，則內存模型就天然支持共享讀取。
原理圖如下：
4、閑魚IM基于Flutter的架構設計
4.1 新老架構對比
如下圖所示：是一個老架構方案，其核心問題主要集中于Native邏輯抽象差，其中邏輯層面還設計到多線程并發使得問題倍增，Android/iOS/Flutter交互繁雜，開發維護成本高，核心層耦合較為嚴重，無插拔式概念.
考慮到歷史架構的問題，演進如下新架構設計：
如上圖所示，架構從上至下依次為：
- 1）業務層；
- 2）分發層；
- 3）邏輯層；
- 4）數據源層。
數據源層來源于推送或網絡請求，其封裝于Native層，通過Flutter插件將消息協議數據上拋到Flutter側的核心邏輯層，處理完成后變成Flutter DB的Enitity實體，實體中掛載一些消息協議實體。
核心邏輯層將繁雜數據扁平化打包掛載到分發層中的會話內存模型數據或消息內存模型數據，最后通過觀察者模式的訂閱分發到業務邏輯中。
Flutter IM重點集中改造邏輯層和分發層，將IM核心邏輯和業務層面數據模型進行封裝隔離，核心邏輯層和數據庫交互后將數據封裝到分發層的moduleData中，通過訂閱方式分發到業務層數據模型中。
此外在IM模型中DB也是重點依賴的，個人對DB數據庫管理進行全面封裝解，實現一種輕量級，性能佳的Flutter DB管理框架。
4.2 DB存儲模型
Flutter IM架構的DB存儲依賴數據庫插件，目前主流插件是Sqflite。
其存儲模型如下：
依據上圖Sqflite插件的DB存儲模型會有2個等待隊列：
- 一個是Flutter層同步執行隊列；
- 一個是Native層的線程執行隊列。
其Android實現機制是HandlerThread，因此Query/Save讀寫在會同一線程隊列中，導致響應速度慢，容易造成DB SQL堆積，此外缺失緩存模型。
于是個人定制如下改進方案：
Flutter側通過表的主鍵設計查詢時候會優先從Entity Cache層去獲取，若緩存不存在，則通過Sqflite插件查詢。
同時改造Sqflite插件成支持sync/Async同步異步兩種方式操作，對應到Native側也會有同步線程隊列和異步線程隊列，保證數據吞吐率。但是這里建議查詢使用異步，存儲使用同步更穩妥，主要怕出現多個相同的數據元model同一時間進入異步線程池中，存儲先后順序無法有效的保證。
4.3 ORM數據庫方案
IM架構重度依賴DB數據庫，而當前業界還沒有一個完備的數據庫ORM管理方案，參考了Android的OrmLite/GreenDao，個人自行設計一套Flutter ORM數據庫管理方案。
其核心思想如下：
由于Flutter不支持反射，因此無法直接像Android的開源數據庫方式操作，但可通過APT方式，將Entity和Orm Entity綁定于一身，操作OrmEntity即操作Entity，整個代碼風格設計也和OrmLite極其相似。
參考代碼如下：
4.4 IM內存數據模型
基于Flutter的IM移動端架構在內存數據模型主要劃分為會話和消息兩個顆粒度：
- 1）會話內存數據模型交托于SessionModuleData：會話內存數據有一個根節點RootNotice，然后其掛載PSessionMessageNotice（這里PSessionMessageNotice是ORM映射的會話DB表模型）子節點集合。
- 2）消息內存數據模型交托于MessageModuleData：消息內存數據會有一個MessageConatiner容器管理，其內部掛載此會話中的PMessage(PMessage是ORM映射的消息DB表模型)消息集合。
依據上一章節，PSessionMessageNotice設計了一個OrmEnitity Cache，考慮到IM中會話數是有限的，因此PSessionMessageNotice都是直接緩存到Cache中。
這種做法的好處是各地去拿會話數據元時候都是緩存中同一個對象，容易保證多次重復讀寫的數據一致性。而PSessionMessageNotice考慮到其數量可以無限多的特殊性，因此這里將其掛載到MessageContainer的內存管理中，在退出會話的時機會校驗容器中PMessage集合的數量，適當縮容可以減少內存開銷。
模型如下圖所示：
4.5 狀態管理方案
基于Flutter的IM移動端架構狀態管理方案比較簡單，對數據源Session/Message維度使用觀察者模式的訂閱分發方式實現，架構類似于EventBus模式，頁面級的狀態管理無論使用fish-redux、scopeModel或者provider幾乎影響面不大，核心還是需保留一種插拔式抽象更重要。
架構如下圖：
4.6 IM同步模型方案
當前現狀的消息同步模型：
如上圖所示是，模型中存在ACCS Thread/Main Thread/Region Thread等多線程并發場景，導致易出現多線程高并發的問題。
native的推送和網絡請求同步的隔離方案通過Lock的鎖機制，并且通過隊列降頻等方式處理，流程繁瑣且易出錯。整體通過Region Version Gap去判斷是否有域空洞，進而執行域同步補充數據。
改進的同步模型如下：
如上圖所示，在Flutter側天然沒多線程場景，通過一種標記位的轉化同步異步實現類似Handler消息隊列，架構清晰簡約了很多，避免鎖帶來的開銷以及同步問題。
5、本次改造進展以及性能對比
1）針對架構層面：
在基于Flutter的IM架構中，重點將雙端邏輯差異性統一成同一份Dart代碼，完全磨平Android/iOS的代碼差異性帶來的問題。
帶來的好處很明顯：
- 1）降低開發維護、測試回歸、視覺驗收的一半成本，極大提高研發效率；
- 2）架構上進行重構分層，實現一種解耦合，插拔式的IM架構；
- 3）同時Native到Flutter側的大量數據上拋序列化過程改造程Flutter引用傳遞，解決極限測試場景下的私聊卡頓問題。
2）針對線上輿情：
- 1）補齊UT和TLog的集團日志方式做到可追蹤，可排查；
- 2）針對于很多現存的疑難雜癥重點集中專項解決，比如iphone5C的架構在Flutter側統一規劃；
- 3）未讀紅點計數等問題也在架構模型升級中修復；
- 4）此外多媒體音視頻發送模塊進行改造升級。
3）性能數據對比：
當IM架構的邏輯層和UI層都切換成Flutter后，和原先架構模式初步對比，整體內存水位持平。
其中：
- 1）私聊場景下小米9測試結構內存下降40M，功耗降低4mah，CPU降低1%；
- 2）極限測試場景下新架構內存數據相比于舊架構有一個較為明顯的改觀（主要由于兩個界面都使用Flutter場景下，頁面切換的開銷降低很多）。
6、未來展望
JS跨端不安全，C++跨端成本有點高，Flutter會是一個較好選擇。彼時閑魚FlutterIM架構升級根本目的從來不是因Flutter而Flutter，是由于歷史包袱的繁重，代碼層面的維護成本高，新業務的擴展性差，人力配比不協調以及疑難雜癥的輿情持續反饋等等因素造成我們不得不去探索新方案。
經過閑魚IM超復雜業務場景驗證Flutter模式的邏輯跨端可行性，閑魚在Flutter路上會一直保持前沿探索，最后能反饋到生態圈。
總結一句話，探索過程在于你勇于邁出第一步，后面才會不斷驚喜發現。
（原文鏈接：點此進入，本次有修訂和改動）
附錄：更多文章匯總
[1] 更多阿里團隊的文章分享：
《阿里釘釘技術分享：企業級IM王者——釘釘在后端架構上的過人之處》
《現代IM系統中聊天消息的同步和存儲方案探討》
《阿里技術分享：深度揭秘阿里數據庫技術方案的10年變遷史》
《阿里技術分享：阿里自研金融級數據庫OceanBase的艱辛成長之路》
《來自阿里OpenIM：打造安全可靠即時通訊服務的技術實踐分享》
《釘釘——基于IM技術的新一代企業OA平臺的技術挑戰(視頻+PPT) [附件下載]》
《阿里技術結晶：《阿里巴巴Java開發手冊(規約)-華山版》[附件下載]》
《重磅發布：《阿里巴巴Android開發手冊(規約)》[附件下載]》
《作者談《阿里巴巴Java開發手冊(規約)》背后的故事》
《《阿里巴巴Android開發手冊(規約)》背后的故事》
《干了這碗雞湯：從理發店小弟到阿里P10技術大牛》
《揭秘阿里、騰訊、華為、百度的職級和薪酬體系》
《淘寶技術分享：手淘億級移動端接入層網關的技術演進之路》
《難得干貨，揭秘支付寶的2維碼掃碼技術優化實踐之路》
《淘寶直播技術干貨：高清、低延時的實時視頻直播技術解密》
《阿里技術分享：電商IM消息平臺，在群聊、直播場景下的技術實踐》
《阿里技術分享：閑魚IM基于Flutter的移動端跨端改造實踐》
[2] 更多IM開發綜合文章：
《新手入門一篇就夠：從零開發移動端IM》
《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的“弱”和“慢”》
《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》
《從客戶端的角度來談談移動端IM的消息可靠性和送達機制》
《現代移動端網絡短連接的優化手段總結：請求速度、弱網適應、安全保障》
《移動端IM中大規模群消息的推送如何保證效率、實時性？》
《移動端IM開發需要面對的技術問題》
《開發IM是自己設計協議用字節流好還是字符流好？》
《IM消息送達保證機制實現(一)：保證在線實時消息的可靠投遞》
《IM消息送達保證機制實現(二)：保證離線消息的可靠投遞》
《如何保證IM實時消息的“時序性”與“一致性”？》
《一個低成本確保IM消息時序的方法探討》
《IM單聊和群聊中的在線狀態同步應該用“推”還是“拉”？》
《IM群聊消息如此復雜，如何保證不丟不重？》
《談談移動端 IM 開發中登錄請求的優化》
《移動端IM登錄時拉取數據如何作到省流量？》
《淺談移動端IM的多點登錄和消息漫游原理》
《完全自已開發的IM該如何設計“失敗重試”機制？》
《通俗易懂：基于集群的移動端IM接入層負載均衡方案分享》
《微信對網絡影響的技術試驗及分析（論文全文）》
《開源IM工程“蘑菇街TeamTalk”的現狀：一場有始無終的開源秀》
《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》
《子彈短信光鮮的背后：網易云信首席架構師分享億級IM平臺的技術實踐》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《自已開發IM有那么難嗎？手把手教你自擼一個Andriod版簡易IM (有源碼)》
《融云技術分享：解密融云IM產品的聊天消息ID生成策略》
《IM開發基礎知識補課(六)：數據庫用NoSQL還是SQL？讀這篇就夠了！》
《適合新手：從零開發一個IM服務端（基于Netty，有完整源碼）》
《拿起鍵盤就是干：跟我一起徒手開發一套分布式IM系統》
《適合新手：手把手教你用Go快速搭建高性能、可擴展的IM系統(有源碼)》
《IM里“附近的人”功能實現原理是什么？如何高效率地實現它？》
《IM“掃一掃”功能很好做？看看微信“掃一掃識物”的完整技術實現》
《IM消息ID技術專題(一)：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《IM消息ID技術專題(二)：微信的海量IM聊天消息序列號生成實踐（容災方案篇）》
《IM消息ID技術專題(三)：解密融云IM產品的聊天消息ID生成策略》
《IM消息ID技術專題(四)：深度解密美團的分布式ID生成算法》
《IM消息ID技術專題(五)：開源分布式ID生成器UidGenerator的技術實現》
《IM消息ID技術專題(六)：深度解密滴滴的高性能ID生成器(Tinyid)》
《IM開發寶典：史上最全，微信各種功能參數和邏輯規則資料匯總》
《IM開發干貨分享：我是如何解決大量離線消息導致客戶端卡頓的》
《零基礎IM開發入門(一)：什么是IM系統？》
《零基礎IM開發入門(二)：什么是IM系統的實時性？》
《零基礎IM開發入門(三)：什么是IM系統的可靠性？》
《零基礎IM開發入門(四)：什么是IM系統的消息時序一致性？》
《IM開發干貨分享：如何優雅的實現大量離線消息的可靠投遞》
《IM開發干貨分享：有贊移動端IM的組件化SDK架構設計實踐》
《一套億級用戶的IM架構技術干貨(下篇)：可靠性、有序性、弱網優化等》
《IM掃碼登錄技術專題(一)：微信的掃碼登錄功能技術原理調試分析》
《IM掃碼登錄技術專題(二)：市面主流的掃碼登錄技術原理調試分析》
《IM掃碼登錄技術專題(三)：通俗易懂，IM掃碼登錄功能詳細原理一篇就夠》
《理解IM消息“可靠性”和“一致性”問題，以及解決方案探討》
《阿里技術分享：閑魚IM基于Flutter的移動端跨端改造實踐》
>> 更多同類文章 ……
本文已同步發布于“即時通訊技術圈”公眾號。
▲ 本文在公眾號上的鏈接是：點此進入。同步發布鏈接是：http://www.52im.net/thread-3615-1-1.html