共计 8684 个字符,预计需要花费 22 分钟才能阅读完成。
如果感觉文章对你有帮忙,点赞、珍藏、关注、评论,一键四连反对,你的反对就是我创作最大的能源。
❤️ 本文原创 听蝉 公众号: 码里特地有禅 欢送关注原创技术文章第一工夫推送 ❤️
前言
没错,继 Flutter 异样监控 | 框架 Catcher 原理剖析 之后,带着那颗动乱的好奇心我又捣鼓着想找其余 Flutter 异样监控框架读读,看能不能找到一些好玩的货色,于是在官网介绍第三方库里发现了这货 Bugsnag,大抵扫了下源码发现 flutter 侧主流程很简略没啥货色可看滴,因为这货强烈依赖对端能力,Flutter 异样捕捉之后就无脑抛给对端 SDK 本人啥都不干,抛开 Bugsnag 这种解决异样的形式不管,源码里却也有一些之我见的亮度值得借鉴和学习,比方本文次要介绍 Bugsnag 如何追溯异样门路的设计思维和实现,对异样捕捉的意识有不少帮忙。
Bugsnag
性能简介
在介绍可追溯异样门路设计之前,有必要先科普下 Bugsnag 是什么?让大佬们有一个大局观,毕竟前面介绍内容只是其中一个小的点。
Bugsnag 跟 Catcher 一样也是 Flutter 异样监控框架,Bugsnag-flutter 只是壳,次要作用有:
- 标准多平台 (安卓,ios) 异样调用和上报的接口。
- 拿到 flutter 异样相干数据传递给对端。
次要反对性能:
- dart 侧异样反对手动和主动上报。
- 反对上报数据序列化,有网环境下会持续上报。
- 反对记录用户导航步骤,自定义要害节点操作,网络异样主动上报。
这个框架的侧重点跟 Catcher 齐全不同,它不反对异样的 UI 客户端自定义显示,也不反对对异样的定制化解决。说白了就是你想看异样就只能登陆到 Bugsnag 后盾看到,后盾有套餐包含试用版和免费版(你懂滴)。
根本应用
void main() async => bugsnag.start(runApp: () => runApp(const ExampleApp()),
// 须要到 bugsang 后盾注册账号申请一个 api_key
apiKey: 'add_your_api_key_here',
projectPackages: const BugsnagProjectPackages.only({'bugsnag_example'}),
// onError callbacks can be used to modify or reject certain events
//...
);
class ExampleApp extends StatelessWidget {const ExampleApp({Key? key}) : super(key: key);
@override
Widget build(BuildContext context) {
return MaterialApp(navigatorObservers: [BugsnagNavigatorObserver()],
initialRoute: '/',
routes: {'/': (context) => const ExampleHomeScreen(),
'/native-crashes': (context) => const NativeCrashesScreen(),},
);
}
}
// Use leaveBreadcrumb() to log potentially useful events in order to
// understand what happened in your app before each error.
void _leaveBreadcrumb() async =>
bugsnag.leaveBreadcrumb('This is a custom breadcrumb',
// Additional data can be attached to breadcrumbs as metadata
metadata: {'from': 'a', 'to': 'z'});
import 'package:bugsnag_breadcrumbs_http/bugsnag_breadcrumbs_http.dart' as http;
void _networkFailure() async =>
http.post(Uri.parse('https://example.com/invalid'));
后盾成果展现
Flutter 异样显示页
bugsnag 后盾 Breadcrumbs 页显示内容:能够看到门路中蕴含了以后页面信息,申请信息和关键步骤,异样生成的门路和工夫点
异样捕捉框架浏览通用套路
在异样上报主流程之前,必要的通用套路不能忘,依照这个思路来追源码事倍功半,如下:
- Flutter 异样监控点
三把斧:FlutterError.onError,addErrorListener,runZonedGuarded 详见:不得不晓得的 Flutter 异样捕捉知识点:Zone 中 Zone 异样捕捉大节。
- 针对 Error 的包装类生成
咱们最好不要间接应用 onError 参数中的 error 和 stack 字段,因为为不便问定位个别原始 Error 会通过各种转换减少附加信息更容易还原异样现场,比方设施 id 等,比照 Catcher 中这个通过包装的对象叫 Report
- 操作包装类
下面最终生成的包装类对象会通过一些操作,操作次要三个方面:显示、存储、上报。拿 Catcher 来举例子,它蕴含了 UI 显示和上报两个。个别在我的项目中可能显示不那么重要,最重要的是存储和上报。
Bugsnag 次要流程源码简析
次要领略下”异样捕捉通用套路”大法有多香:
找监控点
这个流程中少了 addErrorListener,阐明 bugsnag 对 isolate 异样是监控不到滴。
Future<void> start({FutureOr<void> Function()? runApp,
//... Tag1 一堆额定参数
}) async {
//...
// 开始就想着用对端 SDK,这里当然少不了初始化通道
_runWithErrorDetection(
detectDartErrors,
() => WidgetsFlutterBinding.ensureInitialized(),
);
//...
await ChannelClient._channel.invokeMethod('start', <String, dynamic>{//... Tag2: 这里将 Tag1 处的额定参数传给了对端 SDK});
//Tag3:dart error 的解决类,其中全部都是通过 channel 来桥接的
final client = ChannelClient(detectDartErrors);
client._onErrorCallbacks.addAll(onError);
this.client = client;
_runWithErrorDetection(detectDartErrors, () => runApp?.call());
}
void _runWithErrorDetection(
bool errorDetectionEnabled,
FutureOr<void> Function() block,) async {if (errorDetectionEnabled) {
// 如许相熟的滋味,await runZonedGuarded(() async {await block();
}, _reportZonedError);
} else {await block();
}
}
// 最终_reportZonedError 会执行到_notifyInternal
void _notifyUnhandled(dynamic error, StackTrace? stackTrace) {_notifyInternal(error, true, null, stackTrace, null);
}
ChannelClient(bool autoDetectErrors) {if (autoDetectErrors) {FlutterError.onError = _onFlutterError;}
}
void _onFlutterError(FlutterErrorDetails details) {_notifyInternal(details.exception, true, details, details.stack, null);
//...
}
找包装类生成
Future<void> _notifyInternal(
dynamic error,
bool unhandled,
FlutterErrorDetails? details,
StackTrace? stackTrace,
BugsnagOnErrorCallback? callback,
) async {
final errorPayload =
BugsnagErrorFactory.instance.createError(error, stackTrace);
final event = await _createEvent(
errorPayload,
details: details,
unhandled: unhandled,
deliver: _onErrorCallbacks.isEmpty && callback == null,
);
//...
await _deliverEvent(event);
}
// 我说什么来着:连最根本的 Event 结构,都是在对端。Future<BugsnagEvent?> _createEvent(
BugsnagError error, {
FlutterErrorDetails? details,
required bool unhandled,
required bool deliver,
}) async {
final buildID = error.stacktrace.first.codeIdentifier;
//...
};
// 调用了对端通道办法来实现。final eventJson = await _channel.invokeMethod(
'createEvent',
{
'error': error,
'flutterMetadata': metadata,
'unhandled': unhandled,
'deliver': deliver
},
);
if (eventJson != null) {return BugsnagEvent.fromJson(eventJson);
}
return null;
}
操作包装类
原本认为此处要大干一场,后果兴冲冲给了对端。。。,什么都不想说,心田平静毫无波澜~~~
Future<void> _deliverEvent(BugsnagEvent event) =>
_channel.invokeMethod('deliverEvent', event);
次要源码流程看完了,上面来看下 Bugsnag 我感觉比拟好玩的需要和实现。
什么是可追溯异样门路
这个是我本人想的一个词,该需要目标是能残缺记录用户操作的整个行为门路,这样达到清晰领导用户操作过程,对问题的定位很有帮忙。能够了解成一个小型的埋点零碎,只是该埋点零碎只是针对异样来做的。
如下:异样产生流程,state 被胜利加载后用户先进入了主页,而后从主页进入了 native-crashes 页之后异样就产生了。对开发者和测试人员来说很容易复现通过如上门路来复现问题。
异样门路后盾显示成果
如何实现
前置常识
Bugsnag 中将可追溯的门路命名为 Breadcrumb,刚开始我不了解,这个单词英文意思: 面包屑,跟门路八竿子都扯不上关系,直到查维基百科才发现为什么这么命名,通过一片一片的面包屑能力找到回家的路。。。,老外们还真够有情怀的!
Breadcrumb 的命名的含意, 有没有察觉这个名字起得好形象!
页面门路 (英语:breadcrumb 或 breadcrumb trail/navigation),又称 面包屑导航,是在用户界面中的一种导航辅助。它是用户一个在程序或文件中确定和转移他们地位的一种办法。面包屑这个词来自糖果屋 这个童话故事;故事中,汉赛尔与葛丽特希图依附洒下的面包屑找到回家的路。
当然最终这些丢下的面包屑 (leaveBreadcrumb) 门路数据也是通过调用到对端 SDK 来实现:
Future<void> leaveBreadcrumb(
String message, {
Map<String, Object>? metadata,
BugsnagBreadcrumbType type = BugsnagBreadcrumbType.manual,
}) async {final crumb = BugsnagBreadcrumb(message, type: type, metadata: metadata);
await _channel.invokeMethod('leaveBreadcrumb', crumb);
}
这里次要关注下主动增加面包屑的场景。
如何增加门路
两种形式:
- 手动增加,通过调用 bugsnag.leaveBreadcrumb
- 主动增加,其中包含两个场景:导航栏跳转和 网络申请
如上两个场景的的实现原理波及到对利用性能的监控性能,重点剖析其中原理。
导航栏主动埋点实现原理
MaterialApp: navigatorObservers 来实现对页面跳转的监听,Bugsnag 中是通过自定义 BugsnagNavigatorObserver,并在其回调函数中监听导航行为手动调用 leaveBreadcrumb 办法上报导航信息给后盾从而达到监听页面的成果。
注意事项:
navigatorObservers 是创立导航器的观察者列表,将要察看页面跳转对象放在该列表中,页面中产生导航行为时候,就能够监听到。如果一个利用中有多个 MaterialApp 的状况,须要保障每个 MaterialApp:navigatorObservers 中都有 BugsnagNavigatorObserver 才行,不然某些 MaterialApp 中也监控不到。最好是一个利用对立一份 MaterialApp 缩小这种不必要的麻烦。
如下代码中
- Bugsnag 框架自定义了 BugsnagNavigatorObserver 对象, 该对象必须继承 NavigatorObserver 并实现其中回调函数方可放入到 MaterialApp:navigatorObservers 中,不是轻易什么对象都能够放到列表中的。
- 这样 Bugsnag 就具备了对整个接入利用导航的监控能力,页面进入或者页面退出行为都能够被监控到。
- 而后在步骤 2 回调中手动调用_leaveBreadcrumb 来实现对导航门路的监听。
- _leaveBreadcrumb 将数据传送给对端 SDK,SDK 传输数据给 bugsnag 后盾 Breadcrumb 页,也就是下面成果中出现的。
class ExampleApp extends StatelessWidget {const ExampleApp({Key? key}) : super(key: key);
@override
Widget build(BuildContext context) {
return MaterialApp(navigatorObservers: [BugsnagNavigatorObserver()],
//...
);
}
}
----[BugsnagNavigatorObserver]----->
// BugsnagNavigatorObserver extends NavigatorObserver
BugsnagNavigatorObserver({//...}) : _navigatorName = (navigatorName != null) ? navigatorName : 'navigator';
@override
void didReplace({Route<dynamic>? newRoute, Route<dynamic>? oldRoute}) {
_leaveBreadcrumb('Route replaced on', {if (oldRoute != null) 'oldRoute': _routeMetadata(oldRoute),
if (newRoute != null) 'newRoute': _routeMetadata(newRoute),
});
//...
}
//.... 其余回调函数
void _leaveBreadcrumb(String function, Map<String, Object> metadata) {if (leaveBreadcrumbs) {
bugsnag.leaveBreadcrumb(_operationDescription(function),
type: BugsnagBreadcrumbType.navigation,
metadata: metadata,
);
}
}
网络申请主动埋点实现原理
通过自定义 http.BaseClient 实现对默认 http.Client 中 send 办法代理来实现,对申请发送和失败进行统一化监听,并记录了申请时长埋点上报。
举荐个网络监听通用计划:
能够看下 didi 的 Flutter 计划: 复写 HttpOverride 即可,DoKit/dokit_http.dart at master · didi/DoKit
如下
- 当点击发送网络申请时,会调用 Bugsnag 本人的 http 库。
- Bugsnag http 库中本人实现了 Client 类,该类复写 send 办法(该办法在产生网络行为时都会被触发),并在其中做了网络监听的额定埋点操作_requestFinished,其中包含对网络后果反馈和网络申请工夫的统计。
- 例子中最终 post 会执行 client.send,从而实现了对网络自埋点门路的上报。
import 'package:bugsnag_breadcrumbs_http/bugsnag_breadcrumbs_http.dart' as http;
void _networkFailure() async =>
http.post(Uri.parse('https://example.com/invalid'));
----[bugsnag_breadcrumbs_http.dart]---->
Future<http.Response> post(Uri url,
{Map<String, String>? headers, Object? body, Encoding? encoding}) =>
_withClient((client) =>
client.post(url, headers: headers, body: body, encoding: encoding));
Future<T> _withClient<T>(Future<T> Function(Client) fn) async {var client = Client();
try {return await fn(client);
} finally {client.close();
}
}
---->[client.dart]---->
class Client extends http.BaseClient {
/// The wrapped client.
final http.Client _inner;
Client() : _inner = http.Client();
Client.withClient(http.Client client) : _inner = client;
@override
Future<http.StreamedResponse> send(http.BaseRequest request) async {final stopwatch = Stopwatch()..start();
try {final response = await _inner.send(request);
// 拦挡点:这里监听发送胜利
await _requestFinished(request, stopwatch, response);
return response;
} catch (e) {
// 拦挡点:这里监听发送失败
await _requestFinished(request, stopwatch);
rethrow;
}
}
Future<void> _requestFinished(
http.BaseRequest request,
Stopwatch stopwatch, [http.StreamedResponse? response,]) =>
_leaveBreadcrumb(Breadcrumb.build(_inner, request, stopwatch, response));
}
总结
本文次要对可追溯 Crash 门路主动埋点原理进行剖析,该需要是读 Bugsnag 是感觉想法上有亮点的中央,就重点拎进去说说,联合本身做 Flutter 异样捕捉过程教训,压根没思考到这种记录异样门路的需要。而且它还做得这么细针对了导航监听和网络监听主动埋点,而这两块又恰好是对定位问题比拟要害的,试问哪个异样呈现了你不关注产生的页面,哪个线上 App 逃得开网络异样。
另外本文也总结浏览 Flutter 异样监控框架必看的几个关键步骤,联合 Bugsnag 源码进行理论解说。其实 Flutter 异样监控框架来回就那么几个步骤没什么大的变动,次要是看其中有什么亮度的需要并针对需要做了哪些开闭设计,这些才是令人振奋的货色。
参考链接
bugsnag/bugsnag-flutter: Bugsnag crash reporting for Flutter apps
DoKit/Flutter at master · didi/DoKit