Flutter持續化集成上的演進之路

做者：騰訊 - 小德（koudleren 任曉帥）

存在的問題

爲了使用Flutter，剛開始的時候爲了快速上線，採用將Flutter和Native代碼混合開發的模式，具體的工程目錄以下：

能夠明顯的看到工程目錄很亂，android目錄下有多個代碼目錄，lib目錄下是dart代碼，images目錄下是Flutter所用到的圖片等資源，並且居然還包含了iOS的代碼。如此混亂的目錄給咱們帶來了四個問題：

1. 須要對Native工程進行了大量的改造

爲了將Flutter集成到Native工程裏，對Flutter和Native的目錄和編譯腳本都進行了大量的改造，對原來Native的工程影響比較大。

2. 不開發Flutter的同窗也必須得配置Flutter的SDK

由於Flutter的開發須要Flutter SDK的環境，可是團隊內並非全部人都作Flutter的開發，若是要求每一個人都安裝Flutter SDK的環境，無疑帶來了額外的開發成本。

3. 沒法作持續集成

由於Flutter編譯須要Flutter的編譯環境，可是現有的持續集成的環境沒有Flutter的環境，使得Flutter沒法作到持續集成。

4. 本地編譯環境沒法統一

由於第三點的緣由，Flutter是本地編譯的，但是每一個人Flutter SDK的環境很不容易統一，例如SDK版本的差別或者系統的差別，會致使Flutter編譯產物不一致，從而影響現網的表現，出現iOS和Android表現不一致的狀況，甚至會由於SDK版本不匹配形成App的crash。

改進開發模式

針對上面的問題，咱們轉而採用了以下的開發模式：

1. Flutter工程和Native工程分開

將Flutter和Native剝離，Flutter是單獨的工程，Native也是單獨的工程，這樣從工程上面就將Flutter和Native完全分開，二者互不影響，Native工程不在須要改造，單獨打開Native工程也不須要配置Flutter SDK的環境。在Flutter工程裏編譯Flutter的產物，而後集成到Native工程裏。

2. 本地開發，服務端構建

在本地開發Flutter，可是將編譯構建的工做交給服務端來作，由於服務端的Flutter SDK的環境是惟一的並且可控的，這樣無論有幾個開發者，本地環境有多複雜，Flutter的構建都在服務端，保證了Flutter構建產物的一致性。

3. Flutter構建產物自動同步

在服務端觸發Flutter的編譯，若是編譯成功，會自動將最新的Flutter產物同步到Native工程裏，保證Native的工程裏的Flutter產物是穩定的並且是最新的，能夠及時看到最新的更改的Flutter頁面。

這裏持續集成服務是用QCI搭建的。

改進後的效果

通過以上的改造，工程目錄以下：

能夠明顯看到工程目錄清晰了不少，fluttersdk目錄下是Flutter的構建產物，對於原來的Native工程來講就是一個module，flutternew目錄下是Flutter的業務代碼，flutternew依賴fluttersdk，flutternew也是Native工程的一個module。通過改造，能夠達到以下的效果：

1. 實現Flutter對原來Native工程的非侵入式集成

Flutter只是Native工程的一個module，和其餘Native的module是平級的，Naitvie也不須要關心Flutter model的環境，對原來的Native工程沒有影響。

2. 保證Flutter編譯環境的惟一性

由於Flutter的編譯都是在服務端進行的，這樣就保證了Flutter編譯環境的惟一性，iOS和Android都是在同一份代碼同一個編譯環境下構建的，也就保證了Flutter產物的穩定性。

3. 實現了Flutter的持續集成

Flutter的代碼提交以後，會自動觸發Flutter的構建，能夠很容易知道這次的變動是否有問題，最新的Flutter構建產物也會自動同步到Native的工程裏。

結語

通過改進Flutter的開發模式，目前已經實現了對Flutter的敏捷開發和持續集成,實現了多團隊協做遠程構建產出的模式。