敞开成长之旅！这是我参与「日新计划 12 月更文挑战」的第 7 天，点击检查活动详情
前言
最近阅读 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 显现和处理程序的开闭也做得很好，有时候看大佬们的规划思想只会觉得”编程即艺术”。
假如觉得文章对你有帮助，点赞、保藏、重视、谈论，一键四连支撑，你的支撑便是我创作最大的动力。
❤️ 欢迎重视公众号：码里特别有禅 原创技能文章第一时间推送！❤️
