即将开源|Flutter页面线上性能数据不再是谜

事出有因——为什么要做Flutter性能监控

移动端APM其实已经是一个很成熟的命题了，在Native世界这些年的发展中，曾经诞生过很多用于监控线上性能数据的SDK。但是由于Flutter相对于Native做了很多革命性的改变，导致Native的性能监控在Flutter页面上基本全部失效了。基于这个背景，我们在去年启动了名为Flutter高可用SDK的项目，目的是让Flutter页面像Native页面一样可以被度量。

有的放矢——我们需要一个怎样的SDK

性能监控既然是一个成熟的命题，那么意味着我们有着充足的资源可以借鉴。我们借鉴了包括手淘的EMAS高可用、微信的Martix、美团的Hertz等性能监控SDK，并结合Flutter的实际情况我们确定了两个问题，一个是需要收集什么性能指标，一个是SDK需要有什么特性。

性能指标

1. 页面滑动流畅度：传统体现滑动流畅度主要是通过Fps，但是Fps有个问题是无法区分大量的轻微卡顿和少量的严重卡顿，但是对于用户来说显然体感差异是很大的，所以我们同时引入了Fps、滑动时长、掉帧时长来进行衡量是否流畅。

2. 页面加载耗时：页面加载耗时我们选了更能反映用户体感的可交互时长，可交互时长是指从用户点击发起路由跳转行为开始，到页面内容加载到可以发生交互结束的这一段时长。

3. Exception：这个指标应该不需要多做解释。

SDK特性

1. 准确性：准确性是一个性能监控SDK的基础要求，误报或者错报会导致开发者付出很多不必要的排查时间。

2. 线上监控：线上监控意味着收集数据时付出的代价不能太大，不能让监控影响到App原本的性能。

3. 易于拓展：作为一个开源项目，根本目标是希望大家都能参与进来为社区做贡献，所以SDK本身要易于拓展，同时需要一系列的规范来帮助大家进行开发。

见微知著——从单个指标看整体设计

2019年4月25日，我们曾经发表了一篇文章，讲述通过数据驱动Flutter体验升级，文章中详细介绍了Flutter的性能指标以及收集方式，大家可以去翻阅一下之前的文章快速复习一下学过的知识。我们这里就选择其中比较典型的收集瞬时Fps的实现来进行讲解，并通过这样的形式带大家看一下SDK整体的设计。

首先需要实现一个FpsRecorder，并继承自BaseRecorder。这个类的目的是为了获取到业务层中页面Pop/Push的时机以及FlutterBinding提供的页面开始渲染，结束渲染，发生点击事件的时机，并通过这些时机来计算出源数据。对于瞬时Fps来说源数据即为每帧时长。

class FpsRecorder extends BaseRecorder {	
    ///...	
  @override	
  void onReceivedEvent(BaseEvent event) {	
    if (event is RouterEvent) {	
      ///...	
    } else if (event is RenderEvent) {	
      switch (event.eventType) {	
        case RenderEventType.beginFrame:	
          _frameStopwatch.reset();	
                _frameStopwatch.start();	
          break;	
        case RenderEventType.endFrame:	
          _frameStopwatch.stop();	
          PerformanceDataCenter(