关于程序员:Flutter异常监控-叁-从bugsnag源码学习如何追溯异常产生路径

如果感觉文章对你有帮忙，点赞、珍藏、关注、评论，一键四连反对，你的反对就是我创作最大的能源。

❤️ 本文原创听蝉公众号： 码里特地有禅 欢送关注原创技术文章第一工夫推送 ❤️

没错，继 Flutter 异样监控 | 框架 Catcher 原理剖析之后，带着那颗动乱的好奇心我又捣鼓着想找其余 Flutter 异样监控框架读读，看能不能找到一些好玩的货色，于是在官网介绍第三方库里发现了这货 Bugsnag，大抵扫了下源码发现 flutter 侧主流程很简略没啥货色可看滴，因为这货强烈依赖对端能力，Flutter 异样捕捉之后就无脑抛给对端 SDK 本人啥都不干，抛开 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 显示和上报两个。个别在我的项目中可能显示不那么重要，最重要的是存储和上报。

次要领略下”异样捕捉通用套路”大法有多香：

找监控点

这个流程中少了 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

关于程序员:Flutter异常监控-叁-从bugsnag源码学习如何追溯异常产生路径

前言

Bugsnag

性能简介

根本应用

后盾成果展现

异样捕捉框架浏览通用套路

Bugsnag 次要流程源码简析

什么是可追溯异样门路

如何实现

前置常识

如何增加门路

导航栏主动埋点实现原理

网络申请主动埋点实现原理

总结

参考链接