Flutter是開源的UI工具包，其能夠幫助開發者通過一套代碼庫高效建構多平台精美應用，支援移動、Web、桌面和嵌入式平台。在AliFlutter 系列第二場直播中，阿裡巴巴閑魚無線技術專家梁治峰為大家分享了閑魚在Flutter中研發架構應用和探索，從分别從三個方向介紹Flutter一體化研發模式、Flutter動态化能力、Flutter互動能力。
演講嘉賓簡介：梁治峰（花名：玄川），阿裡巴巴無線技術專家，閑魚買家鍊路用戶端負責人，主導閑魚Flutter化的落地和研發架構演進。
本文内容根據演講視訊以及PPT整理而成。
觀看回放
http://mudu.tv/watch/5466337本次分享的主題主要包括以下五個方面：
一、閑魚Flutter研發架構使用現狀
二、Flutter研發架構下一代模式
三、Flutter研發架構下動态能力
四、Flutter研發架構下互動能力
五、後續規劃和展望
一、閑魚Flutter研發架構使用現狀
閑魚是一個側重于電商業務的平台，是以随着業務的不斷增長，系統的邏輯複雜度也在不斷提升。因為屬于電商業務，是以對于流量和營運的資料具有較高的需要，是以在閑魚的體系中也需要具備動态性的能力，并且還需要通過增加特效的能力來增加使用者的感覺，豐富使用者的體驗。
二、Flutter研發架構下一代模式
一體化模式
下圖中左側是傳統的用戶端-伺服器架構。在這樣的CS架構下，對于用戶端開發者而言，往往都會經曆相似的痛點。當産品的需求過來，可能用戶端的開發同學并不能自己完成，而需要牽扯到服務端的開發，可能需要對于協定進行補充或者添加更多的接口能力。而對于後端開發同學而言，面對一個需求也可能需要領域服務的支援。這樣一來，一個貌似很簡單的需求，卻需要從用戶端到後端再到領域服務的互相協調，進而會影響需求的排期問題。而如果用戶端也可以寫服務端的代碼，這樣的問題是否就能夠被解決掉呢？
在目前閑魚所給予的FaaS架構下的一些場景中也存在上述痛點。如下圖所示的是傳統基于FaaS的模式，可以看出使用FaaS能夠将邏輯和UI徹底進行分離，但是在端上的邏輯部分，無外乎兩種，一種是資料的拉去和推送，另外一種是資料的主賬号。在後端也會有類似的邏輯，隻不過此時不是用戶端找服務端要資料，而是服務端找各個領域層要所需要的資料，然後進行資料的加工，再将資料以面向用戶端協定的部分進行主賬号推送。而上述兩個部分存在着一定的邏輯割裂，并且也存在一定的重複工作，因為資料轉化被執行了兩次。那麼，是否能夠将上述兩種邏輯合二為一，并且讓端上的同學進行開發，同時将邏輯後端化呢？結合如今Serverless的能力，可以做到在輕量級能力下支援多語言的開發。
基于上述的背景，閑魚在今年實作了一體化的研發解決方案。在雲側相容了集團通用的Gaia容器化能力，用Dart語言實作了容器化的部分。之是以使用Dart是因為這部分與Flutter對應。阿裡巴巴希望用戶端寫後端的情況與Flutter使用一體化的語言來完成，屏蔽兩者之間的差異。在端側研發了Nexus一體化插件，将現在面向Action的部分可以實作端側與雲側的一體化。這樣的好處在于在端側叫Action，在雲側也叫Action，而在端上進行開發的時候并沒有感覺雲側Action的存在，這就是Nexus的核心作用。此外，現在面向于通信協定其實就是面向于API接口的一部分，這樣能夠實作端上的高性能和邏輯内聚。
這裡簡單介紹一下一體化架構的具體落地場景。對于下圖所示的閑魚下單的頁面而言，在原有模式下可能需要5個請求接口，這部分請求接口可能部分在端上，部分在雲上，并且通過一條資訊流進行合并。這種情況下如果需要修改某種狀态就會非常複雜。在改造完成之後就将原來的5個請求接口全部實作Action協定化，這樣的好處在于雲端的模型統一了，無論是對于雲還是用戶端都在寫同樣的邏輯，隻不過這樣的邏輯部署到了雲上。其次，還屏蔽掉了協定的具體部分，隻留下了協定名稱。第三點好處在于實作了邏輯的歸一，所有的邏輯都實作了雲端化，大家在書寫這樣的邏輯時不會存在割裂，最終書寫的邏輯都是面向雲模型的狀态。第四個優點是備援代碼将會大大減少。而最大的好處在于形成了很好的業務的閉環，讓用戶端開發也可以應用開發的部分工作。
三、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多個量行限制是對于性能的考究。反觀安卓的布局部分，相對比較少，大約為4、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，也就是将現在的簡單容器布局進行特性更新。
四、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上局部重新整理能力，是以無論是實作粒子還是實作骨骼的動畫，性能表現都非常不錯。
回顧本文内容，首先為大家分享了Flutter側在布局方面的突破，Flutter這樣的開源架構具有足夠的能力能夠讓大家在其布局側進行進一步深挖。此外，還和大家分享了閑魚在Flutter互動領域的突破，能夠很好地将UI和特效進行融合。第三個突破就是閑魚在Dart側的突破，将Dart語言實作了雲端開發和關聯，形成了邏輯後移的開發架構。而單點技術難以形成全面的合力，是以在後面與大家分享了将現有能力組合的情況産生不同的體系。假設将FaaS遠端的動态能力結合Nexus一體化能力、DX基于UI的表達能力，似乎就可以通過SSR寫完整的UI部分。同理，FaaS結合Candy也能夠實作互動編排的能力，将互動能力在FaaS端進行表達。
關注「淘系技術」微信公衆号，一個有溫度有内容的技術社群~