開源專案專題系列

（八）

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容器隔離踩坑與規劃

在開始之前，我們先丟擲幾個問題：

圖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編譯鏈。

原始碼工程更復雜了

類似的，一個工程中三端程式碼的出現，讓人難以心靜自然涼。

不穩定

這些問題在大型工程中顯得更加膈應，我們急需解決他們，於是團隊沉浸到了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的相關研發工作。

想了解更多開源專案資訊？

與專案成員零距離交流？

掃碼加入專案群

一切應有盡有

END