前言最近阅读了Catcher、BugSnag、Rollbar三个Flutter异常监控开源框架，文章链接如下：Flutter异常监控-一|从Zone-2谈Flutter异常监控|FrameworkCatcher原理分析Flutter异常监控-3|从bugsnag源码FlutterExceptionMonitoring-4|了解如何追踪异常产生路径Rollbar源代码鉴赏技术选择正在开发中。列在需求列表中，被认为是比较重要的需求，但不代表框架的所有需求都只有这些。功能对比以上所有需求主要体现在从异常产生到发送的过程中，大致包括以下几个方面CatcherBugsnagRollbar自定义UI显示异常是（4种上报方式）不支持异常处理线程mainisolatepeerdecisionsub-isolatecustomization的一部分不支持打包过程。不支持异常存储。不支持对等存储。飞镖侧存储。自定义报表处理程序6种1种（自研）1种（自研）异常路径生成溯源不支持自动+手动是否纯Dart实现DartPeer+DartDartPeer异常处理不支持部分支持是有没有自研后台？否是支持平台全平台android、iosandroid、ios框架好坏如果你问哪个最好，我只能说：“没有不好的框架，只有被滥用的人”。谁不是婴儿（在某人的心目中）？每个人在不同的场景下都是自己的王者。正确吃法：应用场景Catcher如果你对UI异常显示和自定义上报要求高，支持全平台，可以选择Catcher。如果Bugsnag在各平台的SDK上有深厚的耕耘和技术积累，可以参考Bugsnag统一Dart端接口设计和自动埋点。如果Rollbar主打可插拔功能，对UI性能要求高，是Dart重度用户，未来需要支持全平台，可以选择Rollbar。变化与不变的设计模式中最重要的原则就是开闭原则，所有23种设计模式都是基于开闭原则。开闭原则：“对扩展开放，对修改关闭”。关键是识别需求的变化和不变性，隔离包装的变化。以Rollbar框架为例：以复用代码为例，变化的是多平台和多平台中不同的网络和存储实现，不变的是每个平台都需要实现这一套exception网络报告和存储逻辑。隔离性不变，即网络和存储放在Dart端，对变化进行封装。将不同平台的异常捕获方法进行封装，放在相应的平台目录下实现，从而达到代码复用的目的。这块可以看Flutter异常监控中的代码复用分析-四|Rollbar源码欣赏，这里就不赘述了。以线程控制为例，改变的是在哪个线程中，不变的是在线程中做了什么。在Rollbar中抽象Notifier来控制线程，保持隔离不变，从Config中获取Wrangler、Sender、Telemetry来操作异常事件，先存储再打包最后发送，这些是异常处理、封装变化、切换线程的标准流程封装在通知程序中。谁来向这三个开源项目报告Flutter的异常？总结起来可以分为两派：独立派实现纯Dart，什么都自己做，比如Catcher、Rollbar，Flutter这边负责收集Flutter异常。负责向对端SDK汇报，典型代表有bugsnag和Sentry。有人会说，白猫黑猫抓老鼠就是好猫。只要能上报到后台看到结果就OK了。何必费那么大劲，领导不管。回答谁报告Flutter异常的本质是回答以下三个问题：Flutter与宿主的关系。你觉得Flutter是掌控大局（iosandroid,window,web...）的老大哥还是跟随其他平台的小弟？从创建一个新的Flutter项目开始，Flutter官方就给出了答案。fluttercreate命令结束后，可以看到ios和android。..目录，这些目录理解为差异目录，表示不同平台对应的相同功能的实现，然后填写实现。没错，Flutter才是掌控全局的。他为各个平台的不同实现定义了一套统一的Dart端接口。每个差异目录的作用是处理差异化的功能，而不是为了方便桥接，因为宿主已有功能。显然，按照Flutter是大佬的思路，从多平台统一的上帝的角度来看，Flutter异常的范围包括了其他平台的异常，比如其他平台的OOM，而不是简单的考虑Dart端例外。代码复用的问题用一个场景来说明问题：如果项目按照不同的平台维度构建，同一个项目对应不同的平台，如果项目按照Flutter构建，就是一个。那么问题来了，我们是应该在Android端和ios端建立一套数据存储异常，还是将不同平台的异常收集到Flutter平台统一管理和上报？显然，考虑到代码复用和人工成本，可以将其他平台的异常抛给Flutter端进行处理和上报。存储和报表都可以复用，后台也有一套代码。迁移成本很多开源库喜欢把flutter当小弟用，所有的异常都发给对端。由此带来的问题也很明显。Android和ios后台异常系统都会有flutter异常数据，默认存储两次，上报两次。比如Bugsnag，这个时候肯定会有人说Bugsnag是垃圾，强依赖peer，不通用，不可复用。但我们需要看到更深层次的原因：迁移成本。软件开发本质上是一个迭代的过程，先是Android和ios，然后是Flutter。他们在各自的平台上已经有了稳定的crash-sdk。推翻不用做一套新的行为太过激进，而且原有的上报系统结构和迁移势必会出现问题，不顾稳定性，简直增加了很多开发和测试的人力成本，这不符合成本效益。直接桥接到原来的功能不是更好吗。如图，每个平台都已经有SDK了，star上的bugsnag-android比bugsnag-flutter多很多，号称先到先得，稳定。依赖倒置是一个异常框架设计思想的好主意。子平台将异常收集传递给Flutter统一管理和上报。管理和报表本来就是每一端的通用能力，没有必要浪费每一端的人力去重复实现。异常情况下，各个平台接口不同。这种差异化的API应该由各个平台来实现，刚好符合Flutter中的目录分类。治理理念。有点像代码设计的思路。如果是普通代码，则需要将其提取和处理以供公众使用。如果有差异，就应该分成各个子类来实现。lib负责各个平台通用的部分，不同的是各个平台捕获异常的API方法。你看源码看什么需求，整个框架目前实现了哪些功能，跟你想的实现需求的方式有什么不同。二是看到不足，可以让你对框架有更深的理解。比如Catcher的局限性在于不支持异常的本地序列化，断网时无法发送，没有自己的后台，只专注于Adapter的作用；它不是Flutter本身的实现，而是点对点的能力。与Catcher相比，Bugsnag的扩展性差很多，包括多平台适配，但它有自己的背景和盈利能力。最后，看设计。比如Rollbar中类设计模块的抽象严谨漂亮，单体原则和开闭原则都做得很好。Catcher中UI显示和处理程序的打开和关闭也做得很好。有时候，看着大佬们的设计思路，只会觉得“编程就是艺术”。如果您觉得文章对您有帮助，点赞，收藏，关注，评论，一键四连支持，您的支持就是我创作最大的动力。??欢迎关注公众号：编程黑板报第一时间推送原创技术文章！??
