[フロントエンドチュートリアル] Webページのクラッシュを監視する方法は?

この記事はWebページのストールをどのように監視するのですか?次の章。今日は、Webページの崩壊を監視する方法に焦点を当てています。

クラッシュとケイトンの違いは何ですか?

スタッターとは、Webページの一時的な応答が遅く、JSが時間に実行さないことを意味します。これは、前の章のWebページの停止の監視が依存する技術的なポイントでもあります。

ただし、クラッシュは異なります。Webページがクラッシュし、ページが表示されなくなり、JSが実行されていません。Webページのクラッシュを監視してWebページのクラッシュを報告する方法はありますか?

しかし、天国からの道は常にあります。

loadおよびbeforeunloadイベント

インターネットを検索したところ、道が見つからず、ようやくこの記事に出会いました。この記事では、ウィンドウオブジェクトのloadイベントとbeforeunloadイベントを使用して、Webページのクラッシュ監視を実装します。

http://jasonjl.me/blog/2015/06/21/taking-action-on-browser-crashes/ jasonjl.me

  window.addEventListener('load', function () {
      sessionStorage.setItem('good_exit', 'pending');
      setInterval(function () {
         sessionStorage.setItem('time_before_crash', new Date().toString());
      }, 1000);
   });

   window.addEventListener('beforeunload', function () {
      sessionStorage.setItem('good_exit', 'true');
   });

   if(sessionStorage.getItem('good_exit') &&
      sessionStorage.getItem('good_exit') !== 'true') {
      /*
         insert crash logging code here
     */
      alert('Hey, welcome back from your crash, looks like you crashed on: ' + sessionStorage.getItem('time_before_crash'));
   }

写真は千の言葉に値します:

画像

loadおよびbeforeunloadイベントを使用してクラッシュ監視を実装する

このソリューションでは、ページの折りたたみを巧みに使用して、beforeunloadイベントをトリガーします。

ページが読み込まれると(loadイベント)、good_exitステータスは sessionStorageで保留中として記録さます。ユーザーが正常に終了する(beforeunloadイベント)と、ステータスはtrueに変わりますクラッシュが発生してもステータスは保留中です。ユーザーが2回目にWebページにアクセスしたとき(2番目)ロード・イベント)、ビューはgood_exitまだならば、状態を保留我々は最後の訪問したジムを締結することができるということです!

しかし、このプログラムには問題があります:

  1. sessionStorageを使用て状態保存しますが、通常、Webページがクラッシュまたはフリーズした後、ユーザーはWebページを強制的に閉じるか、単にブラウザを再び開きます。sessionStorageは保存されますが、状態は存在しなくなります。
  2. 状態がlocalStorageまたはcookieに保存されている場合、ユーザーが複数のWebページを次々に開いても閉じない場合、good_exitは常に保留状態で終了し、Webページが開かれるたびにクラッシュレポートが表示されます。

この番組は全国生放送開始当初から採用されており、ページを最適化してもクラッシュは減らず、PVとの比例を保っており、この番組の問題点を実感するだけでした。

Service Workerベースのクラッシュ統計ソリューション

PWAの概念の人気により、だれもがService Workerに慣れ親しんでいます。次の理由により、Service Workerを使用してWebページのクラッシュを監視できます。

  1. Service Workerには、Webページとは異なる独自の独立したワーカースレッドがあり、Webページがクラッシュし、Service Workerは通常の状況ではクラッシュしません。
  2. サービスワーカーのライフサイクルは通常、Webページよりも長く、Webページのステータスを監視するために使用できます。
  3. Webページは、navigator.serviceWorker.controller.postMessage APIを介して独自のSWにメッセージを送信できます。

上記のポイントに基づいて、ハートビート検出に基づく監視スキームを実装できます

画像

  • p1:Webページが読み込まれた後、postMessage API を介して5秒ごとにswにハートビートを送信し、彼がオンラインであることを示します。swはオンラインWebページを登録し、登録時間を更新します。
  • p2:Webページがbeforeunloadにある場合、postMessage APIを介して、Webページが正常に閉じられたこと通知し、swは登録されたWebページをクリアします。
  • p3:実行中のプロセス中にWebページがクラッシュした場合、swの実行ステータスはクリアされず、更新時間はクラッシュ前の最後のハートビートのままです。
  • sw:サービスワーカーは、登録のWebページを10秒ごとにチェックし、登録時間が特定の時間(15秒など)を超えていることを検出して、Webページがクラッシュしていると判断します。

参考のために、いくつかの簡略化された検出コード:

// 页面 JavaScript 代码
if (navigator.serviceWorker.controller !== null) {
  let HEARTBEAT_INTERVAL = 5 * 1000; // 每五秒发一次心跳
  let sessionId = uuid();
  let heartbeat = function () {
    navigator.serviceWorker.controller.postMessage({
      type: 'heartbeat',
      id: sessionId,
      data: {} // 附加信息,如果页面 crash,上报的附加数据
    });
  }
  window.addEventListener("beforeunload", function() {
    navigator.serviceWorker.controller.postMessage({
      type: 'unload',
      id: sessionId
    });
  });
  setInterval(heartbeat, HEARTBEAT_INTERVAL);
  heartbeat();
}

  • ** sessionId **このページセッションの一意のID。
  • postMessageには、現在のページのアドレスなど、クラッシュに必要なデータを報告するための情報が含まれています。
const CHECK_CRASH_INTERVAL = 10 * 1000; // 每 10s 检查一次
const CRASH_THRESHOLD = 15 * 1000; // 15s 超过15s没有心跳则认为已经 crash
const pages = {}
let timer
function checkCrash() {
  const now = Date.now()
  for (var id in pages) {
    let page = pages[id]
    if ((now - page.t) > CRASH_THRESHOLD) {
      // 上报 crash
      delete pages[id]
    }
  }
  if (Object.keys(pages).length == 0) {
    clearInterval(timer)
    timer = null
  }
}

worker.addEventListener('message', (e) => {
  const data = e.data;
  if (data.type === 'heartbeat') {
    pages[data.id] = {
      t: Date.now()
    }
    if (!timer) {
      timer = setInterval(function () {
        checkCrash()
      }, CHECK_CRASH_INTERVAL)
    }
  } else if (data.type === 'unload') {
    delete pages[data.id]
  }
})

コードは非常に単純で、詳しく説明しません。

計画の実現可能性

互換性:

Service Workersの人気はすでに非常に高く、国内のブラウザーはすべてChromeカーネルであり、バージョンはすでにChrome 45よりも高いため、かなりの数のユーザーをカバーしています。監視には、ほとんどのデータカバレッジが適しています。

画像

Service Workerの互換性

信頼性:

これは、私が現在知っている方法で、ウェブページのクラッシュを比較的正確に判断できるはずです。ただし、私たちのソリューションはまだテスト環境にあり、しばらくオンラインになった後でデータを共有します。

ブラウザメーカーへの推奨事項

問題マップのクラッシュリストは、chrome:// crashes /にアクセスしてChromeで確認できます。製造元がAPIを提供できる場合、ページが開いたときに、ユーザーの最新のクラッシュ情報を知ることができます。

サービスの推奨

元の記事を公開0件 ・いい ね0件 訪問数348

おすすめ

転載: blog.csdn.net/weixin_47143210/article/details/105644479