无特别说明,文中Rollbar统指Rollbar-flutter
Rollbar官方文档说是纯Dart实现,该特征意味着自带”代码复用”光环。
如图当接入端(Third-APP)调用Rollbar SDK时表示包含的网络(异常数据上传等)和存储(异常存储管理)可达到复用效果。
若Flutter异常监控框架非纯Dart实现(第三篇中Bugsnag),就存在代码无法复用问题,如图,Dart-Crash-SDK是这层壳依赖对端SDK,最终导致各平台(android,ios,…)都须对端SDK(android-crash-sdk, ios-crash-sdk,…)适配,导致网络和存储逻辑对端SDK都须各自实现一遍,严重逻辑重复。
由此在做软件多端架构设计时,Dart侧可理解成是多平台公共代码集合,如果存在多端逻辑功能代码完全可以抽离到Dart侧以复用,减少测试和人力成本。
前面两篇文章我们知道,捕获到原始异常后对其中的Error和StackTrace有相当部分的工作是对原始异常数据的包装再将包装类数据发送给对端或者后台,不同框架包装过程是不一样的,如下图中Catcher框架包装后类对象是Report,Bugsnag对异常进行两次包装,第一次是BugsnagError,第二次是BugsnagEvent。
这很好理解,因为对于同一事物不同框架的需求是不一样的,不同需求注定了不同的包装行为。 原始异常数据就像一条鱼,口味清淡的Catcher选择清蒸,重口味的Bugsnag选择红烧,不同框架就是不同口味的吃鱼人。而Rollbar 将包装行为抽象化,将原始的鱼以某种方式提供给你,让你享受自由烹饪乐趣。
异常产生后有很多耗时操作,如原始异常数据包装中存在读取额外字段,异常的存储,查询,加密,上报等。耗时操作都在main isolate 中做, 势必会影响到main isolate的UI 构建等行为,异常数据量比大时UI会有卡顿情况,就像图中情况,
Rollbar支持将异常耗时处理操作交给子isolate(crash isolate),让main isolate保持专注做UI构建等以提高应用的流畅度。
该需求与第三篇Flutter异常监控 - 叁 |从bugsnag源码学习如何追溯异常产生路径 相同
该需求目的是能完整记录用户操作的整个行为路径,这样达到清晰指导用户操作过程,对问题的定位很有帮助。可以理解成一个小型的埋点系统,只是该埋点系统只是针对异常来做的。
区别在代码层面实现,bugsnag中有自动添加和手动添加路径两种情况,Rollbar中只有手动添加,但是手动添加分类更加细化,比如图中将Breadcrumb构造过程被分成Breadcrumb.error、Breadcrumb.navigation、Breadcrumb.widget、Breadcrumb.log 对应不同图标事件。
话说,追溯异常生成路径需求是标配么? 目前看Bugsnag和Rollbar都有实现。
pubspec.yaml
dependencies:
rollbar_flutter: ^0.3.0-beta
flutter pub get
代码中配置:
import 'package:rollbar_flutter/rollbar.dart';
Future<void> main() async {
const config = Config(
//accessToken到https://rollbar.com/注册获取
accessToken: 'YOUR-ROLLBAR-ACCESSTOKEN',
package: 'rollbar_flutter_example');
await RollbarFlutter.run(config, () {
runApp(const MyApp());
});
}
Rollbar是Flutter异常框架,当然少不了读这类源码套路,直接拿出第三篇文章中的通用阅读路径, 按照如下流程一步步走:
这里主要涉及到isolate双向通信知识,不清楚可以看下这个帖子Flutte 指北 -> Isolate
至此流程图如下:
异常数据包装流程:
上面步骤中经过对Event二次封装,生成最终包装类为Payload, 最后该类转换成字符串发送到Rollbar后台。
上面分析可知线程切换通过Notifier实现,线程切换思路:通过Config配置自定义Notifier值来指定异常处理运行线程,AsyncNotifier是main UI isolate, IsolateNotifier会新建子线程执行异常相关操作。
abstract class Notifier {
// notifier version to be updated with each new release: [todo] automate
static const version = '0.4.0-beta';
static const name = 'rollbar-dart';
Sender get sender;
Wrangler get wrangler;
Telemetry get telemetry;
FutureOr<void> notify(Event event);
FutureOr<void> dispose();
}
默认初始化IsolatedNotifier.spwan 将产生一个新线程。
总结了几点好处:
综上将可能耗时都放到异步线程,可以提高主线程流畅性。
上面分析可知,包装过程通过Transformer来实现,自定义包装类思路:通过Config配置自定义Transformer值来实现自定义处理异常数据逻辑,可以进行加密等。
abstract class Transformer {
FutureOr<Data> transform(Data data, {required Event event});
}
Config默认实现是这个,如果想自定义数据包装过程,可以复写其中transform,对其中date和event操作。
class NoopTransformer implements Transformer {
const NoopTransformer(Config _);
@override
Data transform(Data data, {required Event event}) => data;
}
类功能抽象精准,清晰的职能分工:
Notifier
子类实现。Transformer
对象给了自定义和默认的转换方式。Wrangler
将提供最终真实数据并传输给sender。Sender
子类实现,可以扩展出httpSender等。Telemetry
对数据库的包装,可插入,查询 异常和异常路径对象。可插拔意味更自由的功能和更开闭的设计。Rollbar像堆积木一样,将包装,传输,发送,存储通过组合方式统一配置起来更具灵活性。
通过非空命名构造函数提供默认实现,模块直接是以组合配置,外部可设置和替换,满足开闭原则。
const Config({
this.notifier = IsolatedNotifier.spawn,
this.wrangler = DataWrangler.new,
this.transformer = NoopTransformer.new,
this.sender = PersistentHttpSender.new,
});
PS: 一直没想明白Dart中构造函数的多非空可选参数与构建者模式有啥不同,感觉前者完全可以替换构建者模式的场景,哪位大佬能告诉我应用场景区别?
考虑到篇幅原因,文章分析了主要流程,其实还有很多点值得学习和借鉴。如
Flutter异常监控 - 叁 | 从bugsnag源码学习如何追溯异常产生路径 - 掘金