如何做Flutter高可用SDK

這篇文章主要介紹“如何做Flutter高可用SDK”的相關知識，小編通過實際案例向大家展示操作過程，操作方法簡單快捷，實用性強，希望這篇“如何做Flutter高可用SDK”文章能幫助大家解決問題。

事出有因 - 我們為什么要做Flutter高可用SDK

移動端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本身要易于拓展，同時需要一系列的規范來幫助大家進行開發。

見微知著 - 從單個指標看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().push(FrameData(_frameStopwatch.elapsedMicroseconds));
          break;
      }
    } else if (event is UserInputEvent) {
      ///...
    }
  }

  @override
  List<Type> subscribedEventList() {
    return <Type>[RenderEvent, RouterEvent, UserInputEvent];
  }
}

我們在beginFrame時打下開始點，在endFrame時打下結束點，即可得到每幀的時長。可以看到我們收集到了每幀時長后，將其封裝為了一個FrameData并push到了PerformanceDataCenter中。PerformanceDataCenter會將該數據分發給訂閱了FrameData的Processor中，所以我們需要新建一個FpsProcessor訂閱并處理這些源數據。

class FpsProcessor extends BaseProcessor {
    ///...
  @override
  void process(BaseData data) {
    if (data is FrameData) {
      ///...
      if (isFinishedWithSample(currentTime)) {
        ///當時間間隔大于1s，則計算一次FPS
        _startSampleTime = currentTime;
        collectSample(currentTime);
      }
    }
  }

  @override
  List<Type> subscribedDataList() {
    return [FrameData];
  }
  
  void collectSample(int finishSampleTime) {
    ///...
    PerformanceDataCenter().push(FpsUploadData(avgFps: fps));
  }
  ///...
}

FpsProcessor將獲取到的每幀時長收集起來并計算1s內的瞬時Fps值（具體的統計方法可以參考上文提到的前一篇文章的實現，這里不過多的進行描述）。同樣的在計算完Fps值后，我們將其封裝為了一個FpsUploadData并再一次push到了PerformanceDataCenter中。PerformanceDataCenter會將FpsUploadData交給訂閱了它的Uploader進行處理，所以我們需要新建一個MyUploader訂閱并處理這些數據。

class MyUploader extends BaseUploader {
  @override
  List<Type> subscribedDataList() {
    return <Type>[
      FpsUploadData, //TimeUploadData, ScrollUploadData, ExceptionUploadData,
    ];
  }

  @override
  void upload(BaseUploadData data) {
    if (data is FpsUploadData) {
      _sendFPS(data.pageInfoData.pageName, data.avgFps);
    }
    ///...
  }
}

Uploader可以通過subscribedDataList()選擇需要訂閱的UploadData，并通過upload()接收notify并進行上報。理論上一個Uploader對應一個上傳渠道，使用者可以按需實現如LocalLogUploader、NetworkUploader等將數據上報到不同的地方。

縱觀全局 - SDK整體結構設計

SDK總體可以分為4層，并大量的使用了發布-訂閱模式利用2個Center進行連接，這種模式的好處在于可以使得層與層之間做到完全的解耦，使得對于數據的處理可以更加靈活多變。

API

這一層中主要是一些對外暴露的接口。比如init()需要使用者在runApp()前進行調用，以及業務層需要調用pushEvent()方法給SDK提供的一些時機。

Recorder

這一層的主要職責是用Evnet所提供的時機進行相應的源數據收集并交給訂閱了該數據的Processor進行處理。比如FPS采集中的每幀時長即為源數據。這一層的設計主要是為了使得源數據可以被利用在不同的地方，比如每幀時長除了用于計算FPS，還可以用來計算卡頓秒數。

使用時需要繼承BaseRecoder，通過subscribedEventList()選擇訂閱的Event，在onReceivedEvent()中處理接收到的Event

abstract class BaseRecorder with TimingObserver {
  BaseRecorder() {
    PerformanceEventCenter().subscribe(this, subscribedEventList());
  }
}
mixin TimingObserver {
  void onReceivedEvent(BaseEvent event);

  List<Type> subscribedEventList();
}

Processor

這一層主要是將源數據加工為最終可以被上報的數據，并交給訂閱了該數據的Uploader進行上報。比如FPS采集中根據收集到的每幀時長進行計算，得到這一段時間內的FPS值。

使用時需要繼承BaseProcessor，通過subscribedDataList()選擇訂閱的Data類型，在process()中對接收到的Data進行處理。

abstract class BaseProcessor{
  void process(BaseData data);

  List<Type> subscribedDataList();

  BaseProcessor(){
    PerformanceDataCenter().registerProcessor(this, subscribedDataList());
  }
}

Uploader

這一層主要是由使用者自己去實現，因為每一位使用者希望將數據上報到的地方都不一樣，所以SDK內部會提供相應的基類，只需要跟隨著基類的規范來寫，即可獲取到訂閱的數據。

使用時需要繼承BaseUploader，通過subscribedDataList()選擇訂閱的Data類型，在upload()中對接收到的UploadData進行處理。

abstract class BaseUploader{

  void upload(BaseUploadData data);

  List<Type> subscribedDataList();

  BaseUploader(){
    PerformanceDataCenter().registerUploader(this, subscribedDataList());
  }
}

PerformanceDataCenter

單例，用于接收BaseData（源數據）以及UploadData（加工后的數據），并將這些時機分發給訂閱了他們的Processor和Uploader進行處理。

在BaseProcessor和BaseUploader的構造函數中，分別調用了PerformanceDataCenter的register方法進行訂閱該操作會把對應的實例存在PerformanceDataCenter的兩個Map中，這樣的數據結構使得一個DataType可以對應多個訂閱者。

final Map<Type, Set<BaseProcessor>> _processorMap = <Type, Set<BaseProcessor>>{};

final Map<Type, Set<BaseUploader>> _uploaderMap = <Type, Set<BaseUploader>>{};

當調用PerformanceDataCenter.push()方法push數據時，會根據Data的類型進行分發，交給所有訂閱了該數據類型的Proceesor/Uploader。

PerformanceEventCenter

單例，設計思路和PerformanceDataCenter類似，但這里是用于接收業務層提供的Event（相應的時機），并將這些時機分發給訂閱了他們的Recorder進行處理。Event的種類主要有：（其中業務狀態需要使用者提供，其它時機SDK內部已經完成收集）

• App狀態：App前后臺切換

• 頁面狀態：幀渲染開始、幀渲染結束

• 業務狀態：頁面發生Pop/Push、頁面發生滑動、業務中發生Exception

見仁見智 - SDK的打開方式

如果你是SDK的使用者，那么你只需要關注API層以及Uploader層，你只需要進行以下幾步操作：

1. 在Pubspec中引用高可用SDK；

2. 在runApp()方法被調用前，調用init()方法將SDK初始化；

3. 在你的業務代碼中，通過pushEvent()方法給SDK提供一些必要的時機，比如路由的Pop以及Push；

4. 自定義一個Uploader類，將數據以你希望的格式上報到你所使用的數據收集平臺。

如果你希望能為高可用SDK貢獻一份力量，那么希望你遵守以下幾點設計規范并向我們提出Push Request，我們會及時進行Review并將反饋給到你。

1. 使用發布-訂閱模式，發布者先將數據交給對應的數據中心，再由數據中心分發給相應的訂閱者。

2. 數據流向從Recorder到Processor再到Uploader，通過數據進行驅動，API通過Event驅動Recorder，Recorder通過BaseData驅動Processor，Processor通過UploadData驅動Uploader。

關于“如何做Flutter高可用SDK”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識，可以關注億速云行業資訊頻道，小編每天都會為大家更新不同的知識點。