前言
最近閱讀 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 顯示和處理程式的開閉也做得很好，有時候看大佬們的設計思想只會覺得”程式設計即藝術”。
如果覺得文章對你有幫助，點贊、收藏、關注、評論，一鍵四連支援，你的支援就是我創作最大的動力。
❤️ 歡迎關注公眾號：碼裡特別有禪 原創技術文章第一時間推送！ ❤️
如果覺得文章對你有幫助，點贊、收藏、關注、評論，一鍵四連支援，你的支援就是我創作最大的動力。
❤️ 本文原創聽蟬 公眾號：碼裡特別有禪 歡迎關注原創技術文章第一時間推送 ❤️