真機無法顯示wx-open-launch-weapp標簽的 ，請先完成簽名校驗，校驗完成 后，標簽才會顯示！
真機無法顯示wx-open-launch-weapp標簽的 ，請先完成簽名校驗，校驗完成 后，標簽才會顯示！
真機無法顯示wx-open-launch-weapp標簽的 ，請先完成簽名校驗，校驗完成 后，標簽才會顯示！
本文由阿里閑魚技術團隊祈晴分享，本次有修訂和改動，感謝作者的技術分享。
1、內容概述本文總結了阿里閑魚技術團隊使用Flutter在對閑魚IM進行移動端跨端改造過程中的技術實踐等，文中對比了傳統Native與現在大熱的Flutter跨端方案在一些主要技術實現上的差異，以及針對Flutter技術特點的具體技術實現，值得同樣準備使用Flutter開發IM的技術同行們借鑒和參考。
學習交流：
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》- 開源IM框架源碼：買粉絲s://github.買粉絲/JackJiang2011/MobileIMSDK
（本文同步發布于：買粉絲://買粉絲.52im.買粉絲/thread-3615-1-1.買粉絲）
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核心邏輯和業務層面數據模型進行封裝隔離，核心邏輯層和數據庫交互后將數據封裝到分發層的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）性能數據對比