快捷導(dǎo)航

Flutter上的數(shù)據(jù)監(jiān)控深入理解

更新時(shí)間：2019年06月14日 08:57:42 作者：zjutkz

這篇文章主要給大家介紹了關(guān)于Flutter上的數(shù)據(jù)監(jiān)控的相關(guān)資料，文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家學(xué)習(xí)或者使用Flutter具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面來一起學(xué)習(xí)學(xué)習(xí)吧

前言

最近看公司Flutter項(xiàng)目的時(shí)候，發(fā)現(xiàn)想要分析數(shù)據(jù)非常的困難，不是數(shù)據(jù)缺失就是數(shù)據(jù)異常，作為一個(gè)成熟的企業(yè)來說這是非常危險(xiǎn)的，缺少了數(shù)據(jù)就像船只在海上航行的時(shí)候沒有了方向，將會(huì)變得無所適從，所以這周花了點(diǎn)時(shí)間去優(yōu)化。

我們要關(guān)注什么數(shù)據(jù)
對(duì)于Flutter這樣的組件來說，我們需要關(guān)注的數(shù)據(jù)無非是兩項(xiàng)：

性能數(shù)據(jù)
異常數(shù)據(jù)

這兩項(xiàng)數(shù)據(jù)是我們監(jiān)控整個(gè)Flutter應(yīng)用是否優(yōu)秀的最基礎(chǔ)也是最重要的指標(biāo)。性能數(shù)據(jù)能夠幫我們分析出Flutter對(duì)比Native，RN，Weex等框架是否有優(yōu)勢，而異常數(shù)據(jù)則是反應(yīng)了項(xiàng)目的健康程度，很多時(shí)候在項(xiàng)目開發(fā)和測試的過程中問題沒有暴露，而是在線上才會(huì)有問題，如果沒有異常監(jiān)控，應(yīng)用就很難具備從錯(cuò)誤中快速恢復(fù)的能力。

性能數(shù)據(jù)

對(duì)于性能數(shù)據(jù)，我們可以拆分成以下兩個(gè)點(diǎn)：

渲染時(shí)長
頁面幀率

對(duì)于頁面幀率，目前我還沒有什么仔細(xì)思考過，這一塊的內(nèi)容我會(huì)放在之后的文章中介紹。

對(duì)于渲染時(shí)長，我們可以通過Flutter給出的系統(tǒng)回調(diào)在監(jiān)控頁面第一幀的渲染時(shí)間。Android為以下方法：

getFlutterView().addFirstFrameListener(new FlutterView.FirstFrameListener() {
 @Override
 public void onFirstFrame() {
  //第一幀渲染回調(diào)
 }
});

iOS也差不多，具體大家可以參考網(wǎng)上的例子。

異常數(shù)據(jù)

對(duì)于異常數(shù)據(jù)，我們可以拆分成以下幾個(gè)點(diǎn)：

頁面的打開次數(shù)
頁面發(fā)生異常的次數(shù)
Framework的異常次數(shù)
crash次數(shù)

統(tǒng)計(jì)頁面的打開次數(shù)是為了讓我們更好的觀測整個(gè)大盤的數(shù)據(jù)，并且以它作為分母，得出我們整個(gè)Flutter項(xiàng)目的渲染成功率，這是很重要的一個(gè)指標(biāo)。

但是我們想一想，在Flutter中使用navigator打開一個(gè)頁面，如果我們不做任何處理的話，是無法感知到一個(gè)Flutter頁面被打開了的，所以我們需要通過注冊nevigator的observer去監(jiān)聽頁面的打開與關(guān)閉：

Widget build(BuildContext context) {
 return new MaterialApp(
 navigatorObservers: [new MyNavigatorObserver()],
 home: new Scaffold(
  body: new MyPage(),
 ),
 );
}

在MyNavigatorObserver中通過didPush方法去上報(bào)頁面打開的埋點(diǎn)。

有了頁面的打開數(shù)據(jù)之后，我們接下去需要統(tǒng)計(jì)的是異常的發(fā)生次數(shù)，而在Flutter中異?？梢源笾路譃槿悾?/p>

Dart異常
Framework異常
crash

對(duì)于Dart異常，我們可以通過全局的onError函數(shù)去捕獲：

runZoned<Future<Null>>(() async {
runApp(new MyApp());
}, onError-: (error, stackTrace) async {
 //監(jiān)聽DartError
});

但是這里的回調(diào)是只要有Dart層的error就會(huì)觸發(fā)，這樣就帶來一個(gè)問題：許多不影響用戶體驗(yàn)，無關(guān)緊要的error都會(huì)被我們統(tǒng)計(jì)到，從而影響我們數(shù)據(jù)的準(zhǔn)確性。針對(duì)于上面這個(gè)問題，我的想法是既然要統(tǒng)計(jì)的是影響用戶的error，那我們可以借助Flutter本身的特性，我們知道Flutter在build期間發(fā)生了異常會(huì)展示一個(gè)紅屏的widget，這個(gè)widget是ErrorWidget，我們只需要hook這個(gè)widget的生成，在該widget展示的時(shí)候上報(bào)我們需要的埋點(diǎn)就可以了：

ErrorWidget.builder = (FlutterErrorDetails flutterErrorDetails) {
 //統(tǒng)計(jì)Dart error
 return ErrorWidget(flutterErrorDetails.exception);
};

甚至我們還可以在這里重寫這個(gè)ErrorWidget，去展示我們自定義的錯(cuò)誤頁。

說完了Dart異常，我們接著去處理Framework異常。這個(gè)異常比較特殊，應(yīng)該是Android獨(dú)有的，因?yàn)樵贏ndroid中我們需要加載動(dòng)態(tài)庫去完成Flutter的初始化，所以這里我們可以捕獲動(dòng)態(tài)庫的加載，如果有異常發(fā)生或者加載失敗，則算作為Framework層異常。

最后一個(gè)則是運(yùn)行時(shí)的crash，對(duì)于這部分異常，我們需要做的就是進(jìn)行堆棧的捕獲，并且判斷是否是Flutter引起的crash，如果是則上報(bào)埋點(diǎn)。

總結(jié)

通過上面的幾個(gè)數(shù)據(jù)統(tǒng)計(jì)，我們可以計(jì)算出Flutter應(yīng)用的以下幾個(gè)數(shù)據(jù)：