本文主要介紹一下釘釘 Flutter 業(yè)務(wù)灰度過程中，在桌面端遇到并處理過的幾個 FlutterEngine 層面的 Bug。具體包含：

• Mac 端：
• Windows 端：

下面來為大家分別介紹一下。

FlutterEngine Mac 端問題

1.1 FlutterEngine 退出之后內(nèi)存泄漏問題

1 問題背景

Mac 端 FlutterViewController 在銷毀之后，其開辟的內(nèi)存并未并實際釋放，會出現(xiàn)內(nèi)存泄漏問題。此問題在 Flutter issue 中有一些討論，但一直未有明確定位。在釘釘 Mac 端 Flutter 業(yè)務(wù)灰度過程中也遇到此問題，如無法處理將直接影響 Dutter 在 Mac 端落地的可行性：

2 定位分析

一句話原因：

Mac 端 FlutterEngine 實現(xiàn)中對 weak property 使用不合理導(dǎo)致。FlutterViewController 強持有 FlutterEngine，后者持有一個指向 FlutterViewController 的 weak property。FlutterViewController 在 dealloc 流程中嘗試釋放 FlutterEngine，但是此時 FlutterEngine 中持有的 weak property 已經(jīng)無法正確訪問(nil)，導(dǎo)致釋放流程未能正常執(zhí)行，出現(xiàn)泄漏。

下面結(jié)合具體實現(xiàn)來為大家做一個簡單說明。

由于設(shè)計到 OC 和 C++ 對象生命周期管理問題， FlutterEngine 內(nèi)部對象持有關(guān)系略微特殊一些，大致如下圖所示：

• FlutterViewController 作為對外暴露的主要 Class，負(fù)責(zé)創(chuàng)建并持有 FlutterEngine 以及 FlutterView；
• FluterEngine 在初始化階段會自己強持有自己，并在 shutdown 時自我 Release；
• FlutterEngine 會創(chuàng)建并持有 FlutterRenderer，F(xiàn)lutterRenderer 會強持有 FlutterView；
• FlutterEngine 間接強持有 FlutterView；
• FlutterEngine 有一個指向 FlutterViewController 的弱引用指針。

正常情況下，F(xiàn)lutterViewController 退出之后，會通過調(diào)用 FlutterEngine 的 setViewController 傳入 nil 的方式，來觸發(fā) FlutterEngine shudown 動作。參考實現(xiàn)如下：

即正常情況下，F(xiàn)lutterViewController dealloc 之后應(yīng)該觸發(fā) 369 行代碼運行，進(jìn)而釋放 FlutterEngine 資源。但是實際運行情況缺不是這樣，在代碼運行到 359 行時，嘗試判斷 if (_viewController != controller) 時并未成立。通過上述代碼我們知道，controller 是外部傳入的對象此時為 nil；_viewController 作為一個 weak proptry，在 FlutterViewController 進(jìn)入 dealloc 流程之后也變?yōu)?nil。因而在此流程下，我們希望中的 shutDownEngine 方法并未被調(diào)用。

3 處理方案

問題定位之后處理方式就很簡單了，可以在 FlutterViewController dealloc 的時候手動觸發(fā) FlutterEngine shutDownEngine 方法。并且通過在上層通過 OC 動態(tài)特性 hook 實現(xiàn)、或者直接修改重新編譯 FlutterEngine 都可以。

但此處修改一定要謹(jǐn)慎，注意完整還原 FlutterEngine 中的 shutdown 流程，否則可能導(dǎo)致我們遇到的第二個問題：死鎖。

1.2 FlutterEngine shutdown 階段死鎖問題

1 問題背景

釘釘最初在處理上述「FlutterEngine 泄漏」問題時，采用了一種相對比較簡單的方案：在 FlutterViewController dealloc 方法中，手動調(diào)用 FlutterEngine 提供的 shutDownEngine 方法，手動觸發(fā)相關(guān)資源釋放。

通過此方案，F(xiàn)lutterViewController 退出之后內(nèi)存確實出現(xiàn)了下降，但是在灰度時發(fā)現(xiàn)偶爾會有整個頁面卡死的情況。通過對出現(xiàn)問題的鏈路進(jìn)行簡單分析以及配合暴力測試，我們在 debug 環(huán)境對問題做了還原。最終初確認(rèn) UI 線程與 Raster 線程出現(xiàn)死鎖，死鎖之后的線程狀態(tài)大致如下。

UI 線程狀態(tài)：

Raster 線程：

2 定位分析

一句話原因：

釘釘側(cè)調(diào)用 FlutterEngine shutDownEngine 方法不合理導(dǎo)致。shutDownEngine 之前，必須先調(diào)用 FlutterView 的 shutdown 方法來停止渲染流程。待渲染流程正常停止之后，才可進(jìn)入 FlutterEngine 資源釋放流程，否則即有可能出現(xiàn)上述死鎖問題。

因為此問題為釘釘調(diào)用不合理導(dǎo)致，具體異常原因不再深入分析，感興趣的同學(xué)可以根據(jù)上述線索自行查閱。

3 處理方案

在上層補全 FlutterEngine 釋放流程，在調(diào)用 FlutterEngine shutDownEngine 之前首先調(diào)用 FlutterView shutdown 停止 Raster 線程。

1.3 低版本 macOS OpenGL 析構(gòu)階段 Crash 問題

1 問題背景

此問題還是接兩個問題，在處理完問題1和問題2之后，參考 FlutterEngine shutdown 流程，釘釘會在 FlutterViewController 析構(gòu)之后做3件事情：

1. 將 FlutterRenderer 中綁定的 FlutterView 置為 nil；
2. 調(diào)用 FlutterView shutdown 方法；
3. 調(diào)用 FlutterEngine shutDownEngine 方法。

經(jīng)過一系列處理之后，測試發(fā)現(xiàn)內(nèi)存泄漏和死鎖問題基本得以根治。但是在內(nèi)部灰度過程中發(fā)現(xiàn)低版本 macOS 上會出現(xiàn) Crash，堆棧大致如下：

2 定位分析

一句話原因：

與問題2類似，此問題也是因為釘釘處理泄漏問題而引入。其大致由兩方面因素迭代導(dǎo)致。一方面因為重置 FlutterOpenGLRenderer 綁定的 FlutterView，導(dǎo)致在 embedder 層創(chuàng)建的 OpenGL 對象被提前釋放；另外一方面因為低版本 macOS OpenGL 實現(xiàn)不完善析構(gòu)流程中未能對關(guān)鍵鏈路做保護，進(jìn)而導(dǎo)致異常。

下面對異常相關(guān)代碼做一下簡答分析，避免其他同學(xué)再遇到類似問題。

1. 在 FlutterEngine setViewController 方法中，如果處于釋放流程，會調(diào)用 FlutterOpenGLRenderer setFlutterView 方法，并傳入 nil：

2. FlutterOpenGLRenderer setFlutterView 方法在入?yún)?nil 時，會釋放其內(nèi)部維護的 NSOpenGLContext 對象：

3. FlutterEngine 底層實現(xiàn)會在 GrDirectContext 對象析構(gòu)時執(zhí)行 flush，如果此時 OpenGL 相關(guān)對象已經(jīng)釋放，在低版本 macOS（10.11, 10.12）會出現(xiàn) Crash:

3 處理方案

由于出現(xiàn)問題的部分是由釘釘上層代碼觸發(fā)，處理相對比較簡單。最終我們在所有使用 OpenGL 渲染的 Mac 設(shè)備上(macOS 10.14 之前的版本)移除 FlutterView 置空動作。即最終 FlutterViewController 釋放階段只執(zhí)行以下兩個動作：

1. 調(diào)用 FlutterView shutdown 方法；
2. 調(diào)用 FlutterEngine shutDownEngine 方法。

FlutterEngine Windows 端問題

2.1 Win7 設(shè)備渲染模塊「Crash + 殘影」問題

1 問題背景

此問題背景略微有些復(fù)雜，如果細(xì)分來看的話，此問題應(yīng)該可以拆分為兩個子問題。

第一個問題是，在部分 Win7 設(shè)備上（x86 + x64）出現(xiàn) d3d11 導(dǎo)致的 Crash，堆棧大致如下：

由于遲遲無法定位導(dǎo)致此問題的具體原因、且 Flutter 官方表示他們對 Win7 設(shè)備的覆蓋度并不完善「參考」（https://github.com/flutter/flutter/issues/92650#issuecomment-961341821）。因此我們決定對 FlutterEngine 稍加定制，在 Win7 等陳舊設(shè)備上強制通過「軟解模式」來渲染 Flutter 頁面。

本以為通過此方式可以繞過此問題，但很不幸運的是此方案暴露了 FlutterEngine 里另外一個 Bug：通過「軟解模式」來渲染頁面時，F(xiàn)lutterViewController 關(guān)閉只有有一定概率會導(dǎo)致 Windows 桌面出現(xiàn)殘影。

2 定位分析

一句話原因：

此問題主要是因為 FlutterEngine 內(nèi)部 shutdown 流程中，未及時修改 FlutterWindowsEngine 指向 FlutterWindowsView 對象的指針，導(dǎo)致多線程場景下出現(xiàn)野指針；因為野指針導(dǎo)致raster 線程在 FlutterWindowsView 已經(jīng)銷毀情況下仍向其輸出繪制幀，進(jìn)而導(dǎo)致異常。

在定位時，我們通過增加輔助 log 的方式來加快問題定位過程。通過對關(guān)鍵節(jié)點補充日志，我們很快發(fā)現(xiàn)了可疑點：

上圖是出現(xiàn)問題之后關(guān)鍵節(jié)點輸出的日志。我們通過日志可以得到以下關(guān)鍵信息：

1. OnBitmapSurfaceUpdated 是 FlutterWindowsView 的成員函數(shù)。但是在輸出最后兩行 OnBitmapSurfaceUpdated 方法時，F(xiàn)lutterWindowsView 的析構(gòu)函數(shù)已被執(zhí)行（野指針）；
2. 最后一次執(zhí)行 OnBitmapSurfaceUpdated 時，渲染使用的 Window 句柄為 nullptr，即可供渲染的窗口（與 FlutterWindowsView 綁定）以被釋放。

因為最后渲染所使用 Window 句柄為 nullptr，進(jìn)而導(dǎo)致出現(xiàn)殘影問題。

補充說明：在調(diào)用 C++ 成員函數(shù)時，即使調(diào)用時 this 已經(jīng)為野指針，但只要成員函數(shù)中并未訪問到 this 對象，則不會出現(xiàn)內(nèi)存訪問異常(Crash)。

3 處理方案

修改 FlutterEngine 內(nèi)部實現(xiàn)，在 SoftwareRenderer 模式下 FlutterWindowsView 析構(gòu)時，置空 FlutterWindowsEngine 指向其的指針(因 GPU 模式會有異常輸出，暫未修改)：

通過此方式，可以保證在 FlutterWindowsView 銷毀之后 raster 線程中的任務(wù)不會再回調(diào)渲染接口：

2.2 FlutterPlugin 注冊階段野指針 Crash

1 問題背景

在釘釘 Flutter 版本「+面板」業(yè)務(wù) Windows 端一灰、二灰階段出現(xiàn)較多例 Crash，客戶端整體 Crash 率高達(dá) x%：

通過簡單分析，還原 Crash 堆棧大致如下：

從堆棧可以達(dá)到兩個比較重要的信息：

1. Crash 出現(xiàn)在 FlutterEngine 初始化階段，具體是在 Plugin 注冊時出現(xiàn)異常；
2. 導(dǎo)致 Crash 原因是野指針問題。

2 定位分析

一句話原因：

Flutter 為 Windows 平臺提供 wrapper 層代碼中，包含一個設(shè)計上為單例的對象 PluginRegistrarManager。PluginRegistrarManager 主要服務(wù)于 FlutterPlugin 注冊、設(shè)計上為一個單例，其內(nèi)部通過 map 維持了一個 FlutterEngine 指針與 Registrar 的映射關(guān)系，保證 Registrar 與 FlutterEngine 生命周期保持一致。但是因為 wrapper 層的代碼在構(gòu)建時被編入了 pulgin.dll，導(dǎo)致每一個 plugin.dll 中都包含一份 PluginRegistrarManager 實現(xiàn)副本，即「單例機制」失效。帶來的問題是 FlutterEngine 析構(gòu)時無法正確清除 PluginRegistrarManager 中的綁定關(guān)系，導(dǎo)致其內(nèi)部維護一個失效的指針地址，再次訪問時出現(xiàn) Crash。

下面簡單介紹一下分析過程。通過暴力測試，我們可以復(fù)現(xiàn)問題:

根據(jù)上圖可以確認(rèn)，出現(xiàn) Crash 是因為 FlutterEngine 對象野指針導(dǎo)致。進(jìn)一步定位插件注冊時 Engine 指針來源，最終可定位到 flutter::PluginRegistrarManager::GetInstance()->GetRegistrar() 方法中:

進(jìn)一步分析 PluginRegistrarManager 中的實現(xiàn)，可知 GetRegistrar 內(nèi)部需要 map + emplace 方法來維系 FlutterEngine 地址與 Registrar 關(guān)系：

其內(nèi)部會通過 FlutterDesktopPluginRegistrarSetDestructionHandler 將方法注冊到底層 Engine 對象中，其會在 FlutterEngine 析構(gòu)時被調(diào)用，進(jìn)而解除綁定關(guān)系：

問題即出現(xiàn)在此流程中， 如果 PluginRegistrarManager 并非真正的單例，且 FlutterEngine 只能維護一份有效的 OnRegistrarDestroyed 回調(diào) ，那么在 FlutterEngine 析構(gòu)時，有部分 PluginRegistrarManager 對象中保存的 FlutterEngine 地址不會被清除，再次使用時即會導(dǎo)致問題。

3 處理方案

修改 FlutterEngine wrapper 層 PluginRegistrarManager 實現(xiàn)，優(yōu)化「單例」實現(xiàn)方案。將單例生命周期周期管理下層到底層，wrapper 層僅負(fù)責(zé)提供相關(guān)服務(wù)。

具體可參考：

2.3 Flutter Window 可見性變化之后頁面白屏

1 問題背景

在 Windows 端 Flutter 頁面中，如果將 Flutter Window:

• 先通過 ShowWindow(flutter_wnd, SW_HIDE) 隱藏;
• 再通過 ShowWindow(flutter_wnd, SW_SHOWNORMAL) 顯示出來。

會發(fā)現(xiàn) Flutter 頁面內(nèi)容無法正常展示，畫布上為空白一片。如果在白屏之后通過 setState 或者 拖拽窗口等方式觸發(fā)  Flutter 頁面刷新，則內(nèi)容可被正常渲染。

2 定位分析

此問題相對比較明確，F(xiàn)lutter Windows 端實現(xiàn)存在 bug，在 Window 可見性發(fā)生變化之后，應(yīng)重新出發(fā) flush 將最新視圖繪制到對應(yīng)窗口，但是目前此流程并未實現(xiàn)，導(dǎo)致出現(xiàn)以上問題。

3 處理方案

此問題已經(jīng)提交issue，暫時釘釘側(cè)是通過上層補償?shù)姆绞絹砝@過此此問題。我們在 Native Window 可視性變化之后，手動通知 Flutter 側(cè)刷新當(dāng)前可見頁面，以此觸發(fā)重繪、規(guī)避問題。

總結(jié)

以上即為釘釘 Flutter 落地過程中桌面端處理的幾大主要問題。從我們實際體驗來看，雖然在 Flutter v2.10 版本已經(jīng)正式發(fā)布對 Windows 的支持。但僅從穩(wěn)定性角度來看，F(xiàn)lutter 在 Mac 端的表現(xiàn)無疑要優(yōu)于 WIndows。如果有其它團隊希望在使用 Flutter 在桌面單端做一下嘗試，我們優(yōu)先推薦選擇 Mac 端，其無論是上手門檻還是性能穩(wěn)定性表現(xiàn)，相比 Windows 端要更有優(yōu)勢。