前言 最近閱讀 Catcher、BugSnag、Rollbar 三個 Flutter 異常監控開源框架，文章鏈接如下： Flutter 異常監控 - 壹 | 從 Zone 說起 Flutter 異常監控 - 貳 | 框架 Catcher 原理分析 Flutter 異常監控 - 叄 | 從 bugsn ...
前言
最近閱讀 Catcher、BugSnag、Rollbar 三個 Flutter 異常監控開源框架，文章鏈接如下：
Flutter 異常監控 - 貳 | 框架 Catcher 原理分析
Flutter 異常監控 - 叄 | 從 bugsnag 源碼學習如何追溯異常產生路徑
Flutter 異常監控 - 肆 | Rollbar 源碼賞析
這篇文章將從實現功能，優缺點，設計思想等方面做個總結，方便開發中技術選型。
需求列表
羅列下認為比較重點需求,並不表示框架所有需求只有這些。
功能對比
所有上述需求主要體現在異常產生到發送過程中，大致包括如下幾個方面
| Catcher | Bugsnag | Rollbar | |
|---|---|---|---|
| 自定義 UI 顯示異常 | 是(4 種報告模式) | 不支持 | 不支持 |
| 異常處理線程 | main isolate | 對端決定 | 子 isolate |
| 自定義包裝過程 | 部分支持 | 不支持 | 支持 |
| 異常存儲 | 不支持 | 對端存儲 | Dart 側存儲 |
| 自定義上報處理程式 | 6 種 | 1 種（自研） | 1 種（自研） |
| 異常路徑生成追溯 | 不支持 | 自動 + 手動 | 手動 |
| 是否純 Dart 實現 | Dart | 對端+Dart | Dart |
| 對端異常處理 | 不支持 | 支持 | 部分支持 |
| 是否有自研後臺 | 無 | 有 | 有 |
| 支持平臺 | 全平臺 | android,ios | android,ios |
框架的好與壞
如果問哪個最牛逼，我只能說：“沒有不好的框架，只有亂用的人”。誰又不是個（某人心中的）寶寶呢？不同場景下誰都是自己的王者。
正確食用方式：
| 應用場景 | |
|---|---|
| Catcher | 如果對異常 UI 顯示和自定義上報要求很高，且支持全平臺，可以選 Catcher。 |
| Bugsnag | 如果對端各平臺 SDK 有深耕和技術積累，可以參考 Bugsnag 來統一 Dart 端介面設計和自動埋點。 |
| Rollbar | 如果側重功能可插拔，對 UI 性能要求高，重度 Dart 用戶且未來需要支持全平臺，可以選 Rollbar。 |
論變與不變
設計模式中最重要的原則是開閉原則，23 種設計模式都是以開閉原則為核心。
開閉原則：“對擴展開放，對修改關閉。” ，其中關鍵是識別需求中的變與不變，封裝變化隔離不變。
用 Rollbar 框架舉例：
拿復用代碼來說，變化的是多平臺及多平臺中不同的網路和存儲實現，不變的是各平臺都需要實現這套異常網路上報和存儲邏輯。隔離不變，就是將網路和存儲放在 Dart 側，封裝變化，將不同平臺捕獲異常方式封裝起來放到各自對應平臺目錄實現，這樣就達到了復用代碼目的。
這塊可以看下Flutter 異常監控 - 肆 | Rollbar 源碼賞析 中的代碼復用分析，這裡就不贅述了。
拿線程式控制制來說，變化的是在哪個線程，不變的是線上程中做的事情。Rollbar 中抽象 Notifier 來對線程式控制制，隔離不變，從 Config 中獲取 Wrangler，Sender，Telemetry 來對異常事件進行操作，先存儲再包裝最後發送，這些是異常處理的標準流程，封裝變化，將線程切換封裝在 Notifier 中。
Flutter 異常誰來上報
這三個開源項目，總結下來分兩個流派：
- 自力派純 Dart 實現，啥都是自己乾，比如 Catcher 和 Rollbar
- 借力派，Flutter 側負責搜集 Flutter 異常，收集好解析好，給對端 SDK 負責上報，典型代表有 bugsnag 和 Sentry。
有人會說，管它白貓黑貓抓到老鼠就是好貓，只要能上報後臺看到結果不就 OK 了，管那麼多幹嘛，領導又不在乎這個。回答 Flutter 異常誰上報的實質是回答下麵三個問題：
Flutter 與宿主的關係
你認為 Flutter 是掌控全局（ios android ,window，web…)的大佬還是跟隨其他平臺的小弟？
從創建一個新的 Flutter 項目伊始 Flutter 官方就給出了答案，flutter create 命令結束，可看到 ios 和 android。。。 目錄，這些目錄理解成差異目錄，表示同一個功能對應不同平臺的實現是什麼，然後將實現填充在其中。
沒錯 Flutter 是掌控全局的人，他定義了一套統一的 Dart 側介面供各平臺差異實現，各差異目錄作用是為處理差異化功能而非因宿主已有現成功能方便橋接用。
顯然，按 Flutter 是大佬的思路，站在多平臺統一的上帝視角來看，Flutter 異常範圍是包括其他平臺異常的，比如其他平臺的 OOM 等而非單純考慮 Dart 側異常。
代碼復用問題
用一個場景來說明問題：如果按照不同平臺維度建立項目，相同項目則對應不同平臺，如果按照 Flutter 來建立項目就是一個。
那麼問題來了，是在安卓端和 ios 端分別建立一套數據存儲異常呢，還是將不同平臺異常收攏到 Flutter 平臺來統一管理和上報？
顯然考慮到代碼復用和人力成本，大可將其他平臺異常拋都給 Flutter 側來處理和上報，存儲和上報都可復用，後臺也一套代碼。
遷移成本
很多開源庫喜歡將 flutter 作為小弟角色，異常都給到對端，這樣導致的問題也很明顯，安卓和 ios 兩個後臺異常系統都會出現 flutter 異常數據，預設存儲兩份上報兩次，比如 Bugsnag，這時肯定有人會說 Bugsnag 垃圾，強依賴對端，通用性不行，復用性不行。
但我們需要看到更深層次原因：遷移成本。
軟體開發本來就是一個迭代過程，是先有安卓和 ios 再有 Flutter ，人家已經在各自平臺有穩定的 crash-sdk 了，推翻不用重新弄一套的行為太過激進，勢必存在原來上報系統的重構和遷移，穩定性先不論，平白就增加了很多開發和測試的人力成本，不划算，直接橋接到原來功能豈不更好。
如圖，人家就是每個平臺都已經有 SDK 了，而且 star 上 bugsnag-android 比 bugsnag-flutter 多得多，這叫先來後到，穩。
一種異常框架設計思路
依賴反轉是不錯的思路，子平臺將異常收集傳遞給 Flutter 統一管理和上報。管理和上報本來就是各端通用能力，沒必要浪費人力各端重覆實現，異常的情況每個平臺介面都不一樣，這種差異化的 api 就應該由各個平臺來實現，剛好契合 Flutter 中目錄分治理念。
有點像代碼設計的思路，如果是通用的代碼需要提取處理作為公共使用，如果有差異部分就應該分到各個子類中取實現。lib 中負責是各個平臺公共部分，存在差異的是各個平臺捕獲異常的 api 方式。
讀源碼在讀什麼
看需求，當前整個框架實現了哪些功能，跟自己想到的需求實現方式上有什麼不同。
其次就是看不足，看不足可以對框架理解更深。如 Catcher 的局限性是它不支持異常的本地序列化斷網了就發送不了，而且沒自己後臺，僅僅側重於 Adapter 角色；Bugsnag 又太依賴對端，支持異常序列化斷網仍可發送，但不是 Flutter 本身實現而是對端能力，Bugsnag 的擴展性相對於 Catcher 來說就差很多，包括多平臺的適配上來說比不上 Catcher，但它有自己後臺有盈利能力。
最後是看設計，如 Rollbar 中對類設計模塊抽象精準且優美，單一原則和開閉原則做得很好。Catcher 中對 UI 顯示和處理程式的開閉也做得很好，有時候看大佬們的設計思想只會覺得”編程即藝術”。
如果覺得文章對你有幫助，點贊、收藏、關註、評論，一鍵四連支持，你的支持就是我創作最大的動力。
❤️ 歡迎關註公眾號：碼里特別有禪 原創技術文章第一時間推送！ ❤️
如果覺得文章對你有幫助，點贊、收藏、關註、評論，一鍵四連支持，你的支持就是我創作最大的動力。
❤️ 本文原創聽蟬 公眾號：碼里特別有禪 歡迎關註原創技術文章第一時間推送 ❤️
