滴滴DoKit For Flutter正式开源，还是熟悉的"配方"

社区的小伙伴们，大家好啊，艰难的2020已经过去，随着2021的到来，在新的一年里希望大家都能够需求不变更、准点上下班、代码0 Bug。同时我们DoKit团队也给大家准备了一份特殊的“新年礼物”，没错它就是DoKit For Flutter，它来啦，它带着熟悉的配方来啦。接下来就让我们揭开它神秘的面纱吧。

背景

Flutter是Google开源的跨端技术框架。凭借其区别于RN/Weex的自渲染模式，在社区里引起了广泛关注，不管是终端还是前端的小伙伴都趋之若鹜，大有一统大前端江湖的气势。而国内大厂如闲鱼、字节、美团等，也都在其核心业务上完成了落地。

滴滴做为国内最大的出行平台，早在两年前就有多个内部团队开始在Flutter领域进行尝试。但是在开发过程中，我们遇到了很多调试性问题，如日志、帧率、抓包等。为了解决这些开发测试过程中遇到的各类问题，我们DoKit团队联合滴滴代驾和货运团队，把平时工作过程中沉淀下来的效率工具进行业务剥离和脱敏，并最终打造出DoKit For Flutter，在服务内部业务的同时，也为社区贡献一份力量，这也是滴滴的开源精神。

介绍

DoKit For Flutter是一个DoKit针对Flutter环境的产研工具包，内部集成了各种丰富的小工具，UI、网络、内存、监控等等。DoKit始终站在用户的角度，为用户提供最便利的产研工具。

Github地址

Pub仓库地址

操作文档

那么接下来就让我来列举一下DoKit For Flutter的功能以及核心实现。

工具详解

基本信息

基本信息模块会展示当前dart虚拟机进程、CPU、Flutter版本信息、当前App包名和dart工程构建版本信息；

VM信息通过VMService获取。Flutter版本实际上是通过Devtools服务注入的"flutterVersion"方法获取到的，在flutter attach后，本地会起一个websocket服务，连接VMService并注入flutterVersion和其余方法（HotReload、HotRestart等），通过VMService调用flutterVersion方法，会从本地flutter sdk目录下解析version文件返回版本号。

路由信息

在Flutter中，每个页面对应一个Route，通过Navigator管理Route。Navigator内部会包含一个Overlay Widget，每个Route最终都转化成一个_OverlayEntryWidget添加到Overlay上。这个地方可以把Overlay理解为Android中的FrameLayout，内部子View上下叠加。每打开一个新的Route，都相当于往FrameLayout添加一个新的子View。Navigator会存在嵌套的情况，即Route所创建的页面本身也包含一个Navigator，比如App的根Widget是MaterialApp（自带Navigator）,Route页面也用MaterialApp包裹，就会形成Navigator嵌套的情况。还是以FrameLayout来理解，这也就相当于嵌套的FrameLayout。
路由信息功能会打印出当前栈顶页面所处的Route信息，如果存在Navigator嵌套的情况，也会向上遍历打印出每层Navigator的信息。具体的实现方式是，先获取当前根app根Element，可以使用WidgetsBinding.instance.renderViewElement作为根Element，再通过递归调用element的visitChildElements方法，向下遍历整棵树找到最后一个RenderObejctElement，该RenderObejctElement即为当前显示的页面上的元素。然后使用ModalRoute.of(element)方法即可获取到当前页面的路由信息。

至于嵌套的路由信息，则可以通过找到的RenderObejctElement的findAncestorStateOfType方法，反向向上递归遍历，获得所处的Navigator的NavigatorState，再调用ModalRoute.of(navigatorState.context)，如果返回不为空则表示存在嵌套。

方法通道

Flutter的Method Channel调用最终都会经过ServiceBinding.instance._defaultBinaryMessenger这个对象，类型为BinaryMessenger，由于这个对象是个私有对象，无法动态进行修改。不过查看ServiceBinding的源码可以发现这个对象是通过ServiceBinding.createBinaryMessenger方法创建的，通过使用flutter的mixins，可以实现对该方法的重写。
我们知道，ServiceBinding实际也是通过mixins在WidgetsFlutterBinding.ensureInitialized方法中一起被初始化的，所以只要在WidgetsFlutterBinding这个类额外mixin一个继承于ServiceBinding并且重写了createBinaryMessenger方法的类，就能实现对ServiceBinding中createBinaryMessenger的覆盖，代码如下：

class DoKitWidgetsFlutterBinding extends WidgetsFlutterBinding

    with DoKitServicesBinding {

  static WidgetsBinding ensureInitialized() {

    if (WidgetsBinding.instance == null) DoKitWidgetsFlutterBinding();

    return WidgetsBinding.instance;

  }

}


mixin DoKitServicesBinding on BindingBase, ServicesBinding {

  @override

  BinaryMessenger createBinaryMessenger() {

    return DoKitBinaryMessenger(super.createBinaryMessenger());

  }

}

接下去把runApp的入口调用改成如下，就能实现BinaryMessenger的替换
static void _runWrapperApp(DoKitApp wrapper) {
DoKitWidgetsFlutterBinding.ensureInitialized()
..scheduleAttachRootWidget(wrapper)
..scheduleWarmUpFrame();
}
至于Method Channel具体信息的捕获，只要hook住BinaryMessenger.handlePlatformMessage和BinaryMessenger.send两个方法就行了，具体可看DoKitBinaryMessenger这个类

控件检查

和路由功能类似，通过从根element向下遍历，在遍历过程中记录和选中的View有交集的所有RendereObjectElement，并且记录用以标志当前页面的RendereObjectElement,获取它的Route信息。遍历完成后，遍历记录下来的RendereObjectElement，过滤掉Route信息和当前页面不一致的，这些Element属于被遮盖住的页面。然后通过比对RendereObjectElement和选中View的交叉区域面积占RendereObjectElement面积的比例，占比最大的为当前选中的组件。
在Debug模式下可以获取选中组件在工程中的代码位置，将WidgetInspectorService.instance.selection.current赋值为选中element的renderObject，再调用WidgetInspectorService.instance.getSelectedSummaryWidget方法，会返回一个json字符串，解析这个字符串就能获取源码文件名、行列信息等。

日志查看

日志查看功能比较简单，只要使用runZoned方法替代runApp，传入zoneSpecification，就能为日志输出设置一个代理函数，在这个代理函数内进行日志捕获，同时，还可以为onError设置一个代理函数，在这里将捕获的异常也会传入到日志当中。

帧率

使用WidgetsBinding.instance.addTimingsCallback可以统计帧率信息，在每帧渲染完成时会触发回调，包含该帧渲染的信息。

内存

同VM信息，使用VMService可以获取到内存详细使用信息。

网络请求

Flutter自带的网络请求通过HttpClient类发送，只要hook住HttpClient的创建就可以hook整个网络请求的过程。查看HttpClient的构造函数可以发现，如果存在HttpOverrides，就会使用HttpOverrids来创建HttpClient

factory HttpClient({SecurityContext? context}) {

  HttpOverrides? overrides = HttpOverrides.current;

  if (overrides == null) {

    return new _HttpClient(context);

  }

  return overrides.createHttpClient(context);

}

所以这里重写了一个HttpOverrids

class DoKitHttpOverrides extends HttpOverrides {

  final HttpOverrides origin;


  DoKitHttpOverrides(this.origin);


  @override

  HttpClient createHttpClient(SecurityContext context) {

    if (origin != null) {

      return DoKitHttpClient(origin.createHttpClient(context));

    }

    // 置空，防止递归调用，使得_HttpClient可以被初始化

    HttpOverrides.global = null;

    HttpClient client = DoKitHttpClient(new HttpClient(context: context));

    // 创建完成后继续置回DoKitHttpOverrides

    HttpOverrides.global = this;

    return client;

  }

}

替换HttpOverrides

HttpOverrides origin = HttpOverrides.current;

HttpOverrides.global = new DoKitHttpOverrides(origin);

hook住HttpClient方法后，对于请求和返回结果的hook过程就和Android中的HttpUrlConnection类似了，具体可以看DoKitHttpClient、DoKitHttpClientRequest、DoKitHttpClientResponse三个类。

版本API兼容

Flutter版本更新还是比较快的，每一个大版本更新都会带来一些API的变更，目前DoKit的方案需要重写一些framework层的类，在兼容多版本时就会有一些问题。以上面的BinaryMessager为例，1.17版本只有四个方法，用来hook的DoKitBinaryMessager是这么写的

class DoKitBinaryMessenger extends BinaryMessenger {

  final MethodCodec codec = const StandardMethodCodec();

  final BinaryMessenger origin;


  DoKitBinaryMessenger(this.origin);


  @override

  Future<void> handlePlatformMessage(String channel, ByteData data, callback) {

    ChannelInfo info = saveMessage(channel, data, false);

    PlatformMessageResponseCallback wrapper = (ByteData data) {

      resolveResult(info, data);

      callback(data);

    };

    return origin.handlePlatformMessage(channel, data, wrapper);

  }


  @override

  Future<ByteData> send(String channel, ByteData message) async {

    ChannelInfo info = saveMessage(channel, message, true);

    ByteData result = await origin.send(channel, message);

    resolveResult(info, result);

    return result;

  }


  @override

  void setMessageHandler(

      String channel, Future<ByteData> Function(ByteData message) handler) {

    origin.setMessageHandler(channel, handler);

  }


  @override

  void setMockMessageHandler(

      String channel, Future<ByteData> Function(ByteData message) handler) {

    origin.setMockMessageHandler(channel, handler);

  }

}

用来hook的wrapper类需要调用oring对象的同名方法。但在1.20版本BinaryMessager增加了两个新方法checkMessageHandler和checkMockMessageHandler，如果使用1.17.5版本的flutter sdk去编译，就无法调用origin.checkMessageHandler方法，因为不存在；如果使用1.20.4版本的flutter sdk去编译，编译和发布没问题，但编出来的sdk在1.17.5的工程被引用后，也会因为checkMessageHandler方法不存在导致编译失败。
针对这种多个Flutter版本API不同导致的兼容性问题，可以使用扩展方法extension关键字来解决。
建立一个_BinaryMessengerExt类如下：

extension _BinaryMessengerExt on BinaryMessenger {

  bool checkMessageHandler(String channel, MessageHandler handler) {

    return this.checkMessageHandler(channel, handler);

  }


  bool checkMockMessageHandler(String channel, MessageHandler handler) {

    return this.checkMockMessageHandler(channel, handler);

  }

}

在1.17.5版本，调用origin.checkMessageHandler会走到扩展方法的checkMessageHandler中，编译能通过，由于这个方法在1.17.5中是绝对不会被调用到的，虽然会形成递归调用，但没影响。而在1.20版本，BinaryMessenger本身实现了checkMessageHandler方法，所以调用checkMessageHandler方法会走到BinaryMessenger的checkMessageHandler方法中，也能正常使用。
通过extentsion，只要以最低兼容版本的类作为基础，在扩展类中定义新版本中新增的API，就能解决多版本API兼容的问题。

总结

以上就是DoKit For Flutter的现有功能以及工具的基本原理介绍。 我们知道当前它的功能还不是完善，后续我们会继续不断深入的挖掘业务中的痛点并持续输出各种提高用户效率的工具，努力让DoKit For Flutter变得更加优秀，符合大家的期望。

DoKit一直追求给开发者提供最便捷和最直观的开发体验,同时我们也十分欢迎社区中能有更多的人参与到DoKit的建设中来并给我们提出宝贵的意见或PR。 DoKit的未来需要大家共同的努力。