前言
最近閱讀 Catcher、BugSnag、Rollbar 三個 Flutter 例外監控開源框架，文章鏈接如下：
Flutter 例外監控 - 壹 | 從 Zone 說起
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 顯示和處理程式的開閉也做得很好，有時候看大佬們的設計思想只會覺得”編程即藝術”，
如果覺得文章對你有幫助，點贊、收藏、關注、評論，一鍵四連支持，你的支持就是我創作最大的動力，
?? 歡迎關注公眾號：碼里特別有禪 原創技術文章第一時間推送！ ??
如果覺得文章對你有幫助，點贊、收藏、關注、評論，一鍵四連支持，你的支持就是我創作最大的動力，
?? 本文原創聽蟬 公眾號：碼里特別有禪 歡迎關注原創技術文章第一時間推送 ??
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/541788.html
標籤：其他