【まとめ】フロントエンドが習得すべき3種類のスケジュールタスク

フロントエンドでは、タイミングは非常に重要な知識ポイントであり、スケジュールされたタスクはいたるところにあります。フロントエンドがマスターすべき3種類のスケジュールタスクについては、以下の記事でまとめていますので、ご参考になれば幸いです。

1. ユビキタスなスケジュールされたタスク

スケジュールされたタスクは、簡単に理解すると、どれくらいの時間が経過したら何をするかということです。一定の間隔で行うこと。感じたことはありますか? 実際、スケジュールされたタスクはどこにでも存在します。

たとえば、 e コマース プラットフォームのフラッシュ セールのカウントダウンは毎秒実行され、次のようになります。終わりが近づいているという切迫感;たとえば12306からチケットを購入すると、支払いページのカウントダウンが毎秒表示され、注文が支払われていない場合、チケットは無効になることが通知されます。より長く属する;たとえば 製品担当者は、毎晩 12 時にテーブル A のデータをバックアップする必要があると言いました; たとえば、ページの追加が完了してから 1 分後、自動的に別のページにジャンプします。

別の例として、重要な議題があるため、人事担当者が午後 3 時に会議室に行くように指示したとします。たとえば、毎日 9 時に仕事を始めなければなりませんが、それは不可能です。遅刻したら仕事をします。たとえば、毎日 9 時半に早く仕事を始めます。はい、チーム リーダーは何があってもいつもそこにいます。行かないと、彼はあなたを見下すでしょう。たとえば、あなたの給料は 1 日前ではなく毎月 15 日に支払われます。たとえば、あなたは 65 歳になるまで退職しませんが、彼はあなたが 35 歳であっても気にしません。いつ何をしていても関係ありません。あなたが 65 歳であるとしても、会社があなたを 35 歳の高齢のプログラマーだと考えるかどうかは関係ありません。

これらはすべてタイマーです。決まった時間にそれをしなければならないと教えてくれます。プログラムにはそれを制御するコードがあります。人生には見えざる手があります。それは見えません。あなたをコントロールしてください。

2. setTimeout の使用

1. setTimeout の使用シナリオ

setTimeout の使用シナリオでは、何かの実行にかかる時間を規定しており、実行されるのは 1 回だけです。今日は、初めて読み込まれるコンテンツを減らし、最初の画面レンダリングの負荷を軽減するために、ページの読み込み後に特定のものを読み込まないことを規定するシナリオを実装するだけです。最初の画面コンポーネントが 500 ミリ秒ロードされると、追加のものをいくつかロードします。

vue を例に挙げます。たとえば、最初の画面は a.vue の下に配置されます。マウントされたライフ サイクルは、このコンポーネントの DOM がロードされていることを示していることがわかっていますが、コンポーネントがロードされましたが、これは画像やリクエストを表しません。レンダリングは完了したため、500 ミリ秒を予約しました。コードは次のとおりです:

。。。 // 表示a.vue其余代码
mounted() {
    let timeout1 = setTimeout(() => {
        // 需要延迟做的事情
        // 并且延迟完毕要清除setTimeout
        timeout1 = null;
        window.clearTimeout(timeout1);
    }, 500)
},

2。setInterval ## を置き換えます

# setInterval の使用を推奨しない場合が多いのですが、その理由は後述しますが、 setTimeout は一度実行されますが、実行後に再度実行すると複数回実行になってしまいます。

たとえば、0 から累積を開始するアキュムレータを実装します。非常にクールなコードは次のようなものです。素晴らしいですね。コードが実行できないわけではありません。コードは実行できませんが、私は実行できます。あなたは実行できます。

var num = 0;
setTimeout(() => {
    num += 1;
    setTimeout(() => {
        num += 1;
        setTimeout(() => {
            num += 1;
            ......
            setTimeout(() => {
                num += 1;
            }, 970)
        }, 970)
    }, 970)
}, 970)

しかし、何らかの理由でこの仕事が必要で逃げられない場合は、コードを変更して素晴らしさを減らし、もう少し熱くする必要があります

var num = 0;
function timeoutFn() {
   setTimeout(() => {
      num += 1;
      timeoutFn();
   }, 970)
   console.log('经海路大白狗看一下num吧', num);
}
timeoutFn();

3. setInterval の使用

1. setInterval の使用シナリオ

明らかに、setInterval はより多くの回数と定期的に実行してください。たとえば、3 秒ごとに移動する一般的なカルーセル チャートなど、長いソケット リンクを使用しない時限ポーリング取得などの時限アキュムレータです。今日は数字が1ずつ溜まっていくシーンは作らないで、13ずつ溜まっていき、値が100以上になったら0からカウントアップするシーンを作ります。また。

ゴウ兄弟のブログの特徴に気づきましたか? 私は常にプロジェクト シナリオを重視しています。プロジェクト シナリオは、知識ポイントを孤立させないことを望んでいます。知識ポイントは実際の戦闘で使用する必要があります。私たちはいくらでも学び、知識を発展させれば、最終的には会社に勤めて賃金を稼ぐことになります。

var num = 0;
setInterval(() => {
   if (num >= 100) {
        num = 0;
   }
  num += 13;
}, 970)

2. プロジェクトで発生した問題

ブラウザと setInterval の特性が原因です。 setInterval自体は作成時にヒープメモリに格納されます キューは常にメモリ上に存在するため、次回も時間通りに実行できます ブラウザの特性と相まって、ブラウザがこのヒープを見つけた後メモリ、それ 特定の最適化が行われています。ブラウザのタブが画面の最上部にない場合、ブラウザはスケジュールされたタスクを一時停止します。ブラウザのタブが画面の最上部に戻ると、ブラウザは実行を再開します。

所以我们会经常发现一个问题，例如轮播图正在准时3秒动一次，然后浏览器被切走了，等你隔一段时间回来后呢，轮播图就像疯了一样的转动，然后再继续恢复为3秒一动；又或者是在IOS还是什么环境下来着，我记得当时是做一个倒计时的功能。当浏览器切走之前还剩12分钟，等浏览器切走之后呢，倒计时就不动了，等过了2分钟再切回来的时候，发现还是12分钟，又开始倒计时。

其实这个时候可以检测当前浏览器是否处于用户眼前（或者说是否被切走了），用这个代码来判断：

var countSecondFn = null;
function goOnCount() {
    countSecondFn = setInterval(() => {
        // 任务执行
    })
}
document.addEventListener('visibilitychange',function(){
   if(document.visibilityState=='hidden'){
      window.clearInterval(countSecondFn);
      countSecondFn = null;
    }else if(document.visibilityState=='visible'){
      goOnCount(); 
    }
});

所以很多时候，我们更希望用setTimeout的递归来替换掉setInterval的执行，减少更多的问题。 

四、node-schedule的使用

1. node-schedule的使用场景

node-schedule目前主要用于node服务端，例如我们的一些页面，数据是配置出来的，那么就没有必要每次都去请求数据库，再返回给前端，可以定时一下，几分钟发送一次请求即可；再比如我们每次升级上线，为了保证一个良好的性能，HTML可能会部署在服务端，而静态资源则部署在另外的服务器。这样静态资源从v1.0升级到v1.1，则可以定时的去获取配置平台的版本号，然后动态拼接到HTML页面上，以保证可以每次升级拿到最新的静态资源。

但node-schedule和setInterval有本质上的区别。node-schedule更强调哪一天哪个小时，哪一分钟，哪一秒钟准确的去执行。就像我们经常被告知你明天早上9点去做一件什么事情，每天晚上9点你才可以下班。这样的场景，恐怕setInterval不能够胜任了。

2.  简单使用node-schedule

例如每到10分（3点10分、8点10分。。。12点10分）的时候，我们去请求一下数据，第一次请求到的数据进行缓存处理，再次请求到的数据与老数据进行对比，如果无更新则继续用缓存数据，如果有更新则利用新数据。

const schedule = require('node-schedule');
let job = schedule.scheduleJob('* 10 * * * *', () => {
 axios(url, data, (res) => {
    // 与缓存数据对比
    // 后者再犯个懒，不对比，每次都用新数据，请求异常了再用缓存数据
 })
});

3. 执行钥匙Corn

上一段代码中的   * 10 * * * *   呢，就是所谓node-schedule的定时钥匙，这6个星号从左到右表示：秒 分 小时 天 月 年 ，这样看是不是就更明白他的准确性和与setInterval的区别了。 

4. Corn在项目中的问题 

竟然这个Corn定时钥匙如此准确，规定了哪一分钟那一秒钟去执行，去取数据，比如你写的是每分钟的第10秒去获取，这本没有问题。比如全公司都公用一个配置平台呢，你每分钟的第10秒去获取，那比如你这个项目用到了N台机器呢，这N台是否要都是每分钟的第10秒去获取？那如果全公司的N个业务系统都这么写呢，会有什么问题呢？哈哈，如果听明白了狗哥的意思，欢迎和狗哥交流。

5. 自学前端有没有必要学习node

其实我觉得对于自学前端，急于找到前端开发工作的人，没有太大必要去学习node服务端知识。你基本把纯前端的知识学到位已经很不容易了。但如果有时间，还是建议简单学习一下，哪怕只是搭个koa的架子，练习着写一下接口数据格式。一旦自己练习写过接口数据，自己再从前端发送ajax调用一下，我相信你将会有一个更全面的对开发项目的认知，在你遇到问题的时候，有更多的解决思路。

但如果你没有学透，千万别在简历上写你精通node服务端，也别给自己挖坑说自己做过。你不说他们也不会问，这不丢人，放心吧。

五、定时器代码之外的思考

 狗哥觉得其实即便你做了开发，也不应该生活中只有开发，我们努力工作是为了生活，为了更好的生活，所以狗哥更偏向于基于故事讲基础知识点，也更喜欢着力于知识点冒出个小故事（这句话换成抓手咋说？）。

慢慢的，习惯了开发中的定时任务，我们清楚的知道几秒后该让网页执行一件什么事，每天几点该执行一件什么事，可能觉得已经能够胜任工作了，但久而久之，你到了一定的时刻就必须得离开学校，赖在那里也没有用，到了一定的时机，你就需要结婚生子去面对。没人有强拉着你9点前必须到公司，但你知道9点前不到不行。老板告诉你这个东西下班就得做出来，你不做出来也行啊，但你知道你必须做出来。

人生は大きなタイマーのようなもので、大きなタイマーの中に小さなタイマーが密接に結びついており、それらは目に見えないけれど、目に見えるようでいて、あなたの知らない永遠まで続きます。

[推奨学習: JavaScript ビデオ チュートリアル ]

以上が【まとめ】フロントエンドが習得すべき3種類のスケジュールタスクの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。