開源項目專題系列
（八）
1.開源項目名稱：magpie
2.github地址：
https://github.com/wuba/magpie
3.簡介：Magpie Workflow是一個Flutter開發的工具流，用於實現獨立Flutter模塊的創建，開發，編譯，打包，上傳流程；旨在簡化Flutter混合開發的複雜度，成為連接開發者與Flutter的橋樑，因此稱為Magpie Workflow。Magpie Workflow於2020年4月份開源。
全文大綱如下：
- Flutter混編現狀
- Magpie解決方案
- Flutter容器隔離
- 踩坑與規劃
Flutter混編現狀
在過去的2019年，Flutter技術持續火熱。各大公司都在加碼投入Flutter技術的落地，閒魚、快手以及頭條等也已開始進行工程方面的深度定製。可以預見在2020年，Flutter生態將持續發展、壯大。
在開始之前，我們先拋出幾個問題：
圖1 思考
- 為什麼要引入Flutter技術？
- 如何將Flutter落地到業務？
- 如何支撐Flutter並行研發？
針對Flutter的技術優勢，大家可以從官方介紹得到解答。他所具備的性能體驗，研發效率，多端一致性以及開源可控等特性，都吸引著廣大開發者。
但是，Flutter並不是萬金油；就目前來說，每個團隊是否採用該技術棧，影響因子很多，我們需要結合自身的業務和訴求加以考慮。
1. Native與Flutter
通過Flutter技術，從零開始打造一款產品，併產出體驗一致的多端應用，基本上我們只需要遵循Flutter官方的指引說明。這種情況下，相對來說交叉少，沒有什麼技術包袱需要考慮。
在混合開發層面則複雜得多，大多數的團隊在使用Flutter時，走的都是混合開發的方向。即在現有的Android/iOS應用基礎上，部分業務通過Flutter開發。這樣可以最大限度的保障現有業務的穩定，也可以實現基礎能力的複用。
他帶來的問題也是明顯的，混合開發帶來工程結構組織，性能等系列問題，我們面臨第一個技術選型：
採用哪種混合開發方式來實現業務的混合開發？
截止2019年末，Flutter開發社區中主要的有三個流派來進行混合開發：
圖2 混合開發模式
- 官方推出的Add to app功能，正式支持的版本為**1.12+**以上；
- Flutter Boot混合開發方案；
- 其他私有的自研方案，由於未開源/受眾少，不再展開。
無論哪種方案，我們在確定技術方案時，需要考慮到現有業務，以及我們的工程模式和研發效率問題。
2. 痛點與方向
在Flutter實踐過程中，有一些痛點成為了我們的攔路虎。
圖3 痛點
當嘗試原生混合Flutter的時候，你會發現：
編譯鏈更復雜了
為了開發Flutter，需要Flutter編譯鏈，Android編譯鏈，還有iOS的Xcode編譯鏈。
源碼工程更復雜了
類似的，一個工程中三端代碼的出現，讓人難以心靜自然涼。
不穩定
我們早期曾經嘗試過Add to app，但是發現他並不完善，構建過程會導致文件被刪除，比如.android文件。
這些問題在大型工程中顯得更加膈應，我們急需解決他們，於是團隊沉浸到了Flutter源碼研究當中。
3. 工程模式
從歷史的角度來看，更優雅的方案應該做到工程化，端與端的隔離。我們回顧下原生開發的情況：
圖4 工程模式
小型工程：只需要團隊集中火力到Native側，週期性迭代；
大型工程：如果引入混合開發，比如RN/Hybrid，那麼除了Native團隊，還會有業務的RN團隊/Hybrid團隊，最後產出業務維度的bundle。
如果把Flutter也按照這種模式迭代，很多問題就迎刃而解了。
圖5 Flutter工程模式
Magpie解決方案
在Flutter工程化過程中，我們自研了Magpie解決方案，整體上Magpie Workflow是一個Flutter開發的工具流，實現獨立Flutter模塊的創建，開發，編譯，打包，上傳流程。
我們的初衷在於簡化Flutter混合開發的複雜度，成為連接開發者與Flutter的橋樑，因此稱為Magpie Workflow。
小百科: 在英文中，“Magpie Bridge”代表“鵲橋”，也就是中國古老的愛情神話《牛郎織女》裡面，由喜鵲們匯成的一座橋。
1. 研發背景
結合前面我們提到的混合編譯的現狀。我們還有一些研發的考量。首先我們看一下Flutter的編譯問題。
正如你知道的，Flutter有一套熱重載機制，包括Hot reload和Hot restart，這兩把利器讓我們編寫Dart時，效率倍增，相比Native開發形式，幾乎是御風而行，Android的Instant Run也有類似體驗，但是不在一個級別。
然而，如果你進行Cold reload,即觸發整個工程的構建，這個時候是非常難忍受的，你的Native工程根本沒有改變，但是他卻需要完整的assemble構建出安裝包，如果你的Native工程本來就很龐大那麼這個體驗會無限放大。
我們整理了一張圖表，按粗粒度對照了Native開發，混合開發，以及並行開發的編譯耗時。
圖6 研發背景
可以看到，在Native與Flutter混合開發時，時間是需要在Native基礎上疊加的。他的Cold reload時間會很長，很長。
我們期望的是實現一種flutter的並行開發方式，剝離Native，從而減少不必要的編譯耗時。
另一個問題，是如何進行可視化的分離開發，你可能用過很多命令工具，但是你應該不會希望在開發Flutter過程中需要去記憶很多命令名字，參數之類的吧。當然不排除極客開發者，這類高效的開發人員可能對會大量命令愛不釋手。但是從大概率上來說，人是視覺動物，我們會更習慣使用可視化的方法來操作。
如果一個GUI的工具，即簡潔，又有顏，會不會更容易被開發者接受。
圖7 可視化
2. 技術架構
現在我們一起來看一下我們自研的Magpie解決方案。還記得前面我們介紹過的Add to app和Flutter Boot嗎，我們做一下橫向對比，從直觀上了解一下差異點。
圖8 橫向對比
我們在研發Magpie時，針對現有的混合開發方案的問題做了定向優化。在工程源碼和編譯環境上面做了多視角的隔離，是的Flutter業務開發者和Native平臺開發者能夠專注在各自的重心。
同時重點支持了並行開發，實現了Flutter業務和Native原生的並行開發。得益於隔離方案，我們實現了Cold reload的更快速度。同時由於我們採用了dart技術棧，使用Magpie解決方案，不需要安裝額外的編譯環境。
整個Magpie技術架構基於分層設計思想，包括三部分，分別是：
- 腳手架工具CLI
- 可視化的Workflow Service
- 用於App接入的Magpie SDK
圖9 Magpie架構圖一
圖10 Magpie架構圖二
Flutter容器隔離
這一節，我們從使用者的角度，來看看怎麼使用Magpie。
1. Magpie上手
圖11 Magpie開發模式
上圖涵蓋了工程創建，編譯，運行，發佈等環節。
- 通過我們提供的腳手架命令，進行模板工程創建
- 通過start命令，啟動可視化的Workflow頁面
- 在Workflow中操作，如編譯，發佈等
圖12 Magpie工作流程
腳手架包括兩個核心職能：創建工程，啟動Workflow。除此之外也包含其他一些命令，整體構成了cli的指令集。
圖13 腳手架指令集
2. Workflow使用
我們將開發過程涉及的操作，設計為了界面操作。這個靈感來自於ReactNative開發社區的Expo。
當我們啟動項目後，項目便與Workflow產生了關聯，我們在前端頁面中進行開發。
圖14 Workflow功能
- 可以找到需要連接使用的設備；
- 以JIT的形式編譯Flutter Module；
- 將模塊Attach到App中進行預覽和調試；
- 以AOT的形式編譯Flutter Module；
- 可選的將AOT產物上傳到Maven；
- 如果使用過程出現了問題，別慌，在日誌中發現線索，或反饋給我們。
圖15 Workflow產物
後續規劃
在研發Magpie的過程中，我們也遇到了一些問題。
JS轉義後運行時崩潰
在Debug模式下開發正常，但是release之後的js代碼中由於class的引用方式差異，會出現類定義的不同，從而引起崩潰。
Flutter組件體驗偏移動端
目前Flutter提供的基礎Widget如果運用到PC上，效果比較勉強，很多H5/CSS常見效果有缺失。比如文本複製能力，目錄選擇。
Flutter Web生態
目前Flutter Web處於Beta狀態，正如官方的建議，不建議使用到商業生產環境中。但是整體來說，可用性還是比較強的，我們通過較少的調整，利用Flutter Web搭建了整個Workflow的前端頁面。
圖16 開發踩坑
在Flutter的工程實踐上，需要投入大量的人力。長遠來看，我們期望將Magpie打造為一個完整的持續交付平臺。在開發階段，測試階段，開發部署，發佈部署這四個關鍵環節都還有很多的工作等待我們。
圖17 後續規劃
小結
最後一點，58自研的Magpie解決方案是開源的。這意味著，如果你感興趣，可以拿來主義用起來，過程中遇到任何問題，或建議，歡迎到github反饋：
https://github.com/wuba/magpie
限於筆者對Flutter的研究深度，文中不正確之處，望不吝指正：）
吳朝彬，58同城 Android資深開發工程師，主要負責58同城App的相關研發工作。
與項目成員零距離交流？
掃碼加入項目群
一切應有盡有
如群已滿，可添加“58技術小秘書”微信 : jishu-58
添加小秘書微信後由小秘書拉您進項目交流群
END
閱讀更多 58技術 的文章
