10分鐘讀懂阿里巴巴高階專家在Flutter Live2018的分享
作者：閒魚技術-宗心
12月4日，google flutter團隊宣佈第一個flutter正式版本釋出。次日，Flutter Live Beijing 會議上，google flutter團隊邀請了在這一技術方案中重要的合作伙伴閒魚團隊分享這半年以來的通過flutter產出的業務結果以及對應的技術挑戰。
本文根據Flutter Live Beijing嘉賓閒魚客戶端團隊負責人於佳（宗心）的演講內容進行整理，從flutter的優勢和挑戰引出閒魚這半年來針對flutter基礎設施進行重新的構建，定義，以及優化的過程，最後是這半年來對社群的一些貢獻和未來的規劃。
Flutter的優勢與挑戰
眾所周知，Flutter提供了一套解決方案，既能用原生ARM程式碼直接呼叫的方式來加速圖形渲染和UI繪製，又能同時執行在兩大主流移動作業系統上，其畫素級別的還原，保證了不同平臺的UI強一致性。同時其提供了一整套機制（hot reload/attach Debug）保證開發的高效，基於此閒魚團隊在眾多跨平臺方案中選擇了Flutter作為其未來主要的開發方案。
從4月份開始嘗試在業務側接入flutter到現在，閒魚在線上已經有10+的頁面使用了flutter進行開發，其中覆蓋了核心主鏈路釋出和詳情。
閒魚目前是市場上最大的閒置交易社群，作為一款有巨大使用者體量的C端創新類產品，我們對體驗以及研發迭代效率都有比較高的要求。在享受flutter帶來的收益的過程中，同樣會面臨技術轉型過程中的一些挑戰。主要的挑戰來源於以下的三個方面
- 工程體系
在現有工程體系下如何將flutter體系融入，並保持團隊不同技術棧（Android/iOS/Flutter）的同學能各自獨立高效進行開發。
- 業務架構
如何提供一套flutter之上的業務架構，保證上層程式碼的統一標準，同時儘可能的使得程式碼的複用度及隔離性更好。
- 基礎中介軟體
如何保證不同技術棧背後使用的基礎能力是一致的（底層統一使用具有相同優化策略的圖片庫/音視訊庫），且在這個過程中如何解決flutter融入後產生的問題。
面對這些挑戰，閒魚團隊在下半年開始了針對基礎設施的改造與重建。
基礎設施重建之路
工程體系
工程體系部分，首當其衝需要考慮的是不同技術棧同學的協同問題，舉例說明，我們的詳情和釋出頁面是flutter的，而首頁以及搜尋部分目前暫時採用native進行開發。這就需要考慮到flutter的環境要對開發native的同學透明，甚至在native同學沒有安裝flutter環境的情況下，依然可以保持原來的方式進行開發native頁面。
如圖中所示，以iOS為例，我們針對flutter的框架flutter.framewrok和業務程式碼App.framework通過持續整合服務進行打包並自動上傳至雲端的pod repo上，native同學只需在Podfile內指定對應的兩個庫的版本即可，同理，針對flutter的plugin程式碼，同樣打包上傳至pod repo即可。
這套體系整體不復雜，需要說明的是，由於多人開發flutter工程，因此打包是一件非常頻繁的事情，因此我們這半年構建了持續整合體系來幫助大家將打包上傳等整個體系做成一鍵式服務，另外，由於原有iOS平臺的flutter產物是需要依賴我們的native主工程的程式碼的，這種預設的打包方式，程式碼量巨大，造成持續整合時間在10-20分鐘不等，因此在這個過程中，閒魚團隊通過直接基於xcode_backend.sh + insert_dylib的自定義指令碼完成了不依賴native主工程原始碼的打包，將持續整合時間降至2分半。同理在android上面，也進行了一些基礎的改造，感興趣的同學可以給我們留言，我們會根據大家的需求程度在後續安排貢獻給flutter社群。
另外一部分比較重要的內容是混合棧相關的，由於flutter沒有提供flutter到混合工程的最佳實踐，所以我們在上半年自建了一整套混合棧的體系，這裡主要是分享一些混合棧的關鍵思考，在混合棧的實現過程中，需重點測試驗證dart這一側widget的生命週期，並簡化堆疊的管理（目前閒魚的做法是將堆疊管理統一交由native進行控制，簡化Dart層API），並需要考慮如何相容Dart上層的比如Navigtor API的呼叫。整體這部分閒魚團隊還在驗證當中，總之，這部分看似簡單，但實際是比較深的坑，需要重點優化。另外，截至發文時間前，我們跟google flutter團隊就混合棧交換了一些看法，flutter團隊後續如果可以提供多flutterview，單flutter engine的基礎能力，就可以使得閒魚現有的混合棧實現成本整體大幅度降低，後續大家有什麼特別好的建議，也歡迎跟我們進行交流。
業務架構
今年下半年由於有更多的業務遷移至flutter，這意味著更多的團隊成員開始了Dart側的研發。很快我們發現團隊的程式碼風格，層次結構都比較混亂，bug也層出不窮，因此我們需要找到一種可以保證大家研發規範，同時確保多人協同過程中，程式碼既能更好的複用，又可以在適當的場景下做到相互隔離的這麼一種方案。
在經過社群的多個框架庫的實踐和比較以後，不管是flex還是redux都不能完全解決我們的問題。最後我們選擇了自己進行設計和實現，我們對框架進行基礎分層以後，將重點最終落在了基於單一資料來源的元件化框架上面，因此我們產生了自己的框架fishRedux，我們嚴格參考標準js的redux規範和原始碼（redux的設計三原則）進行了完整的dart側的實現，並在此基礎上提供擴充套件能力用於我們的元件化開發。
如圖所示，component將redux中的view，reducer，middleware以及我們的擴充套件能力effect進行組裝，從而可以在不同的頁面進行元件的複用，當然，全域性依然遵循redux的單一資料來源的原則，但我們將邏輯本身通過更細粒度的拆解，保證了這些邏輯在不同的component組裝下都可以儘可能的進行復用。
基於這種結構，我們可以將任意的component進行掛載和拼裝，通過更多小粒度的元件，產生不同場景下的複雜頁面。
另外，針對於component的多層組裝，大家可以細看下dependents這個欄位，通過基於這個欄位的組裝，在我們提供的這段程式碼裡面，實際上是提供了一個詳情頁面的插槽的功能，詳情頁面目前在閒魚有近10種不同的組合，在這個場景下，可以在保證元件可以服用的同時，做到不同流程下的程式碼隔離。我們只要針對dependents的components裡面進行替換，就可以很容易的達到在詳情頁面插入不同widget以及邏輯的效果。
fishRedux框架目前已經接近修改的尾聲，目前還有部分微調和文件的補充，明年4月份前，我們有計劃進行該框架的開源，為後續業務架構提供一個新的標準，大家敬請期待。
基礎中介軟體
在阿里集團內部，已經產出了較多的基礎中介軟體，因此如何複用這個中介軟體到flutter側是一個新的挑戰，針對於傳統的比如網路庫，crash收集等中介軟體，由於不涉及到UI的複用，相對容易，但針對音視訊，圖片庫等這類的中介軟體，雖然flutter提供了flutterTexture的方案，但依然不是特別完美。
我們在做音視訊及圖片庫的複用過程中，主要的問題在於flutter原生提供的機制，針對圖片的渲染存在GPU到CPU，然後CPU再到GPU的這樣一個過程，如圖所示。根本原因在於不同的glContext無法共享texture。因此，我們目前採取的方案是修改flutter引擎，並暴露出glContext的shareGroup（以iOS為例）。目前整個方案已經上線。
由於該改動目前在閒魚自己fork的engine裡面，因此目前將我們之前踩到的一些坑同步給大家，如果大家有在flutter和native側同時使用音視訊的情況，建議特別注意ppt中的前兩點，否則會造成flutter側或者native側音視訊的錯亂。當然如果按照閒魚團隊的提供的修改方案進行engine改造後，也可以通過第三點，對native設定跟flutter相同的sharegroup來解決這個問題。在flutter live Beijing結束之後，我也將該方案正式介紹給google flutter團隊，希望後續能將類似的功能融入flutter的官方實現。
閒魚與flutter社群
閒魚這半年，對於flutter社群，也有一些小小的貢獻。我們針對flutter的方案進行整理並在各個技術社群進行傳播。另外我們將已有的一些問題和解決方案提供給google flutter官方團隊，直接或者間接的推動了flutter的整體進度，並改變了這個技術未來的部分走向。我為自己的團隊感到由衷的驕傲，但同時我意識到，要想讓flutter成為終端未來的主流技術，依然任重道遠，因此我們後續也會將目前的一些相對穩定的框架和解決方案，逐步開源到社群，我們的要求是，至少閒魚團隊需要在線上有應用和驗證。目前我們已經有一些初步的demo和小工具放在上面，大家感興趣的可以往我們的github上提issue，我們後續會逐步開放更多的程式碼。最近會公佈的比較重要的框架會是fishRedux，因此請大家持續關注我們。
總結與展望
我們首先帶大家回顧了flutter帶來的優勢以及在閒魚的實際例子，並引出在複雜工程下的一些挑戰。我們針對這些挑戰，在下半年進行了整個體系的重新建設，初步完成了
- 隔離的混合工程體系
- 統一標準的業務架構
- 高效複用基礎中介軟體設施
本次的分享，其實只是我們目前團隊的一部分內容，我們基於flutter和dart還有更多的技術方案目前在預研和研發中，所以沒有在這次live中進行宣講。在後續跟google flutter團隊的溝通中也瞭解到，他們對我們的多個方案都有較大的興趣。對於未來來說，一方面，除了本文分享的內容以外，我們自己在程式碼自動生成/Dart Server/線上問題自動回放/國際化/動態模版等/持續整合等多個方面都在持續關注和調研。另一方面，在flutter 1.0公佈後，類似hummingbrid這一類全新的方案也有機會讓flutter具有全終端制霸的可能性，我們也會持續跟進和進行嘗試。Anyway，依然希望有更多的同學可以加入我們一起完善flutter的生態，同時通過新的技術手段，讓天下沒有閒置。來閒魚一起改變世界吧，少年！