04 消息訂閱與發布和eventbus(android broadreceiver 運行在哪個進程)

邏輯層和數據庫交互后將數據封裝到分發層的moleData中，通過訂閱方式分發到業務層數據模型中。

此外在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）會話內存數據模型交托于SessionMoleData：會話內存數據有一個根節點RootNotice，然后其掛載PSessionMessageNotice（這里PSessionMessageNotice是ORM映射的會話DB表模型）子節點集合。2）消息內存數據模型交托于MessageMoleData：消息內存數據會有一個MessageConatiner容器管理，其內部掛載此會話中的PMessage(PMessage是ORM映射的消息DB表模型)消息集合。

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

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

模型如下圖所示：

4.5 狀態管理方案

基于Flutter的IM移動端架構狀態管理方案比較簡單，對數據源Session/Message維度使用觀察者模式的訂閱分發方式實現，架構類似于EventBus模式，頁面級的狀態管理無論使用fish-rex、s買粉絲peModel或者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的移動端跨端改造實踐》

《新手入門一篇就夠：從零開發移動端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生成器U

很赞哦!（85）