閒魚研發框架應用和探索

簡介： Flutter是開源的UI工具包，其可以幫助開發者經過一套代碼庫高效構建多平臺精美應用，支持移動、Web、桌面和嵌入式平臺。在AliFlutter 系列第二場直播中，阿里巴巴閒魚無線技術專家梁治峯爲你們分享了閒魚在Flutter中研發框架應用和探索，從分別從三個方向介紹Flutter一體化研發模式、Flutter動態化能力、Flutter互動能力。

Flutter是開源的UI工具包，其可以幫助開發者經過一套代碼庫高效構建多平臺精美應用，支持移動、Web、桌面和嵌入式平臺。在AliFlutter 系列第二場直播中，阿里巴巴閒魚無線技術專家梁治峯爲你們分享了閒魚在Flutter中研發框架應用和探索，從分別從三個方向介紹Flutter一體化研發模式、Flutter動態化能力、Flutter互動能力。

演講嘉賓簡介：梁治峯（花名：玄川），阿里巴巴無線技術專家，閒魚買家鏈路客戶端負責人，主導閒魚Flutter化的落地和研發框架演進。

本文內容根據演講視頻以及PPT整理而成。
觀看回放http://mudu.tv/watch/5466337

本次分享的主題主要包括如下五個方面：
1、閒魚Flutter研發框架使用現狀
2、Flutter研發框架下一代模式
3、Flutter研發框架下動態能力
4、Flutter研發框架下互動能力
5、後續規劃和展望

1、閒魚Flutter研發框架使用現狀

閒魚是一個側重於電商業務的平臺，所以隨着業務的不斷增加，系統的邏輯複雜度也在不斷提高。由於屬於電商業務，因此對於流量和運營的數據具備較高的須要，所以在閒魚的體系中也須要具有動態性的能力，而且還須要經過增長特效的能力來增長用戶的感知，豐富用戶的體驗。

2、Flutter研發框架下一代模式

一體化模式

下圖中左側是傳統的客戶端-服務器架構。在這樣的CS架構下，對於客戶端開發者而言，每每都會經歷類似的痛點。當產品的需求過來，可能客戶端的開發同窗並不能本身完成，而須要牽扯到服務端的開發，可能須要對於協議進行補充或者添加更多的接口能力。而對於後端開發同窗而言，面對一個需求也可能須要領域服務的支持。這樣一來，一個貌似很簡單的需求，卻須要從客戶端到後端再到領域服務的相互協調，進而會影響需求的排期問題。而若是客戶端也能夠寫服務端的代碼，這樣的問題是否就可以被解決掉呢？

在目前閒魚所給予的FaaS框架下的一些場景中也存在上述痛點。以下圖所示的是傳統基於FaaS的模式，能夠看出使用FaaS可以將邏輯和UI完全進行分離，可是在端上的邏輯部分，無外乎兩種，一種是數據的拉去和推送，另一種是數據的主帳號。在後端也會有相似的邏輯，只不過此時不是客戶端找服務端要數據，而是服務端找各個領域層要所須要的數據，而後進行數據的加工，再將數據以面向客戶端協議的部分進行主帳號推送。而上述兩個部分存在着必定的邏輯割裂，而且也存在必定的重複工做，由於數據轉化被執行了兩次。那麼，是否可以將上述兩種邏輯合二爲一，而且讓端上的同窗進行開發，同時將邏輯後端化呢？結合現在Serverless的能力，能夠作到在輕量級能力下支持多語言的開發。

基於上述的背景，閒魚在今年實現了一體化的研發解決方案。在雲側兼容了集團通用的Gaia容器化能力，用Dart語言實現了容器化的部分。之因此使用Dart是由於這部分與Flutter對應。阿里巴巴但願客戶端寫後端的狀況與Flutter使用一體化的語言來完成，屏蔽二者之間的差別。在端側研發了Nexus一體化插件，將如今面向Action的部分能夠實現端側與雲側的一體化。這樣的好處在於在端側叫Action，在雲側也叫Action，而在端上進行開發的時候並無感知雲側Action的存在，這就是Nexus的核心做用。此外，如今面向於通訊協議其實就是面向於API接口的一部分，這樣可以實現端上的高性能和邏輯內聚。

這裏簡單介紹一下一體化框架的具體落地場景。對於下圖所示的閒魚下單的頁面而言，在原有模式下可能須要5個請求接口，這部分請求接口可能部分在端上，部分在雲上，而且經過一條信息流進行合併。這種狀況下若是須要修改某種狀態就會很是複雜。在改造完成以後就將原來的5個請求接口所有實現Action協議化，這樣的好處在於雲端的模型統一了，不管是對於雲仍是客戶端都在寫一樣的邏輯，只不過這樣的邏輯部署到了雲上。其次，還屏蔽掉了協議的具體部分，只留下了協議名稱。第三點好處在於實現了邏輯的歸一，全部的邏輯都實現了雲端化，你們在書寫這樣的邏輯時不會存在割裂，最終書寫的邏輯都是面向雲模型的狀態。第四個優勢是冗餘代碼將會大大減小。而最大的好處在於造成了很好的業務的閉環，讓客戶端開發也能夠應用開發的部分工做。

3、Flutter研發框架下動態能力

閒魚本質上主要是一個電商業務平臺，其在於流量側具備強運營時效的特性，不少的運營活動或者決策須要獲得及時的響應，若是在這種狀況下不具備動態性就會陷入被動。完整的動態性包括了邏輯動態性和UI動態性，可是在流量側部分更加註重UI動態性，輕邏輯重UI。接下來將與你們分享在Flutter側如何使用這樣一個微能力的解決方案。

動態模板

動態模板在阿里巴巴整個集團內部都是一套比較成熟的解決方案。首先，經過DX平臺編輯模板，編輯成二進制文件並生成模板下載連接，以後模板下載解壓，進行表達式或者事件的註冊，並對於數據進行綁定解析，使得組件獲得渲染。藉助於集團動態模板的成熟方案，所須要解決的就是在Flutter側如何知足DSL的UI表達，來實現UI佈局。

核心問題-Layout

熟悉安卓或者Flutter的人會發現這兩部分的UI表達實際上是格格不入的，那麼如何在Flutter側實現一套安卓UI佈局呢？其實完整的UI表達是樣式+佈局+內容組合實現的。根據Flutter的源碼能夠看出，在其佈局表達裏面，樣式、佈局、內容三個要素表達是完全分離的。相反而言，在安卓的DSL的架構裏面，樣式和佈局是結合的，內容部分是分離的。若是將安卓的部分也進行拆分能夠一一映射到Flutter中，雖然描述部分能夠很容易地作映射，可是核心困難在於佈局部分，主要是關於大小的抽象性描述，所以須要瞭解在Flutter側是如何表達佈局的約束的。

其實在Flutter側主要有兩種對於佈局的約束設計，分別是盒子模型和條子模型，而以上兩種都是感性描述的約束性佈局。除此以外，還提供了30多個佈局的容器部分。這是由於基於上面的感性描述的約束佈局狀況下，Flutter可能會存在大量的冗餘代碼，在約束佈局狀況下就會顯得特別複雜。另一部分在於性能部分，感性描述遠遠沒有大於量行描述，所以Flutter提供的30多個量行約束是對於性能的考究。反觀安卓的佈局部分，相對比較少，大約爲四、5個，因此這裏的問題就是如何將安卓的佈局部分使用Flutter的佈局來表達或者描述。若是想要使用特性來作映射是很困難的，若是退而求其次，使用共性部分的盒子模型和條子模型彷佛能夠表達。

佈局表達

若是在端側已經完成對於動態模板樹形結構的解析以後，就可以很容易地將樹形結構的節點實現以下圖所示的一拆三結構。第一層是裝飾層結構，中間層能夠基於自低向上和自頂向下的計算規則從新計算出大小，最後一部分則是將內容想要表達的葉子界面進行Backup。爲了實現安卓這樣的佈局結構阿里巴巴引入了安卓的Spec Model模型，其很主要的做用就是表達當須要作依賴於內容適配等狀況下，可使用Min_width的最大估算來預估大小部分，再從自底向上來計算出實際的Size。動態模板在Flutter側的實現主要解決的就是這樣的側重點部分。

業務效果

整套方案通過閒魚一全年的打磨以後，已經有大量的業務上線和應用了。不管是卡片仍是其餘佈局部分，都可以使用Flutter UI實現。

性能參考

動態性部分每每會和性能存在必定的博弈。在閒魚的實踐中獲得的實際結果代表，使用動態模板的DSL來表達的性能還能夠接受，線上的實際效果大約在55幀左右，相比於正常使用Flutter原生的60幀僅僅存在可被接受的一點差距。

性能的下一步探索

雖然目前的方案和Flutter原生僅存在5幀的差距，可是若是可以進一步優化，仍是有可能達到原生的性能要求的。下圖中分別展示了使用Flutter原生和DX寫的卡片佈局，能夠直觀地發如今Flutter原生使用了大量的高階型特性表達，在DX中則基本都是常見的容器佈局，而且樹形結構的深度層次遠遠大於Flutter原生。DX中使得長度變大的部分在於裝飾性的佈局部分，所以能夠嘗試地探索在DSL的表達部分將Padding在容器層進一步縮短結構，可能會提升FPS，也就是將如今的簡單容器佈局進行特性升級。

4、Flutter研發框架下互動能力

背景與現狀

在電商領域的業務裏面，不少業務想要經過遊戲化的方式創造更有表現力的交互體驗，創造新的業務玩法和價值。傳統的UI表達方式，越日後就會越受限，所以須要將UI和遊戲引擎的邊界打破，讓UI具備遊戲的豐富動效能力，也讓遊戲引擎具備UI的豐富控件能力。在傳統APP的框架下，所可以作的無外乎嫁接遊戲引擎，而這樣的遊戲引擎和原來的APP是格格不入，也是不相通的，其可以帶來的最大效果就是開闢一個獨立的頁面來承載遊戲，但這樣的方式彷佛不是所想要達到的設計理念。在Flutter側，今年推出了Flame這個遊戲框架，其解決了單邊引用的過程。Flame使得在Flutter框架裏面能夠將遊戲的控件進行合攏，可是沒法實如今遊戲裏面合攏UI界面，所以提供了單邊能力。Flame雖然沒有徹底解決雙邊打通的訴求，可是仍是提供了很好的思路。

核心問題-融合

目前而言，所須要解決的核心問題就是將UI和遊戲引擎融合。Flame的表現形式其實就是將完整的遊戲封裝在起來，可以很好地將遊戲插入到UI中。假如將Flame遊戲引擎的表達也用相似於RenderObject樹形結構的表達，就會造成兩棵Flutter體系下的樹結構，可以很好地進行融合比對。閒魚在這樣的思路下進行了新的探索和嘗試，從新設計了一套互動遊戲引擎，彌補了Flame不能知足的需求問題。

Candy總體設計

Candy是符合ECS標準的，與Flutter高度融合的原生開發高性能互動開發框架。Candy在架構設計上徹底按照ECS的標準；在接口設計上對齊了阿里巴巴集團的互動EVA，使得集團內部在使用時不會對於接口感到陌生；在應用能力上，Candy徹底融入了Flutter的繪製體系；在擴展能力上，Candy保留了遊戲子系統化能力的補充，可以知足UED主流能力，使得不一樣公司或者行業開發者可以更好地使用本身所熟悉的工具體系。

效果

在閒魚中，簽到、換取閒魚幣等經常使用的按鈕在遊戲中使用了Flutter的遊戲控件，可以很是簡單地將遊戲以Widget形式插入到Flutter頁面中，而這對於使用者而言不會產生任何感知。此外，對於傳統應用的開發者，也可以很輕鬆地將具備動畫能力、遊戲能力的控件外透，而且與UI進行融合。

效果-骨骼

目前，閒魚的內部方案可以很好地實現龍骨的動畫。正是由於在子系統中保留了這樣的能力，因此若是將來有其餘方案也能夠按照ECS標準進行主流格式的實現。

效果-調試

值得一提的是由於引擎和UI不分家，使得在調試工具的使用過程當中可以更好地看出遊戲或者動畫頁面的佈局狀況，下降了調試工做的難度。

性能參考

基於Render層的設計使得咱們享受到了Flutter引擎側對於Canvas的優化，也享受到了在Flutter Framework上局部刷新能力，所以不管是實現粒子仍是實現骨骼的動畫，性能表現都很是不錯。

5、後續規劃和展望

回顧本文內容，首先爲你們分享了Flutter側在佈局方面的突破，Flutter這樣的開源框架具備足夠的能力可以讓你們在其佈局側進行進一步深挖。此外，還和你們分享了閒魚在Flutter互動領域的突破，可以很好地將UI和特效進行融合。第三個突破就是閒魚在Dart側的突破，將Dart語言實現了雲端開發和聯動，造成了邏輯後移的開發框架。而單點技術難以造成全面的協力，所以在後面與你們分享了將現有能力組合的狀況產生不一樣的體系。假設將FaaS遠端的動態能力結合Nexus一體化能力、DX基於UI的表達能力，彷佛就能夠經過SSR寫完整的UI部分。同理，FaaS結合Candy也可以實現互動編排的能力，將互動能力在FaaS端進行表達。