精读《如何利用 Nodejs 监听文件夹》

1 引言

本期精读的文章是：How to Watch for Files Changes in Node.js，探讨如何监听文件的变化。

若是想使用现成的库，推荐 chokidar 或 node-watch，若是想了解实现原理，请往下阅读。

2 概述

使用 fs.watchfile

使用 fs 内置函数 watchfile 彷佛能够解决问题：

fs.watchFile(dir, (curr, prev) => {});

但你可能会发现这个回调执行有必定延迟，由于 watchfile 是经过轮询检测文件变化的，它并不能实时做出反馈，并且只能监听一个文件，存在效率问题。

使用 fs.watch

使用 fs 的另外一个内置函数 watch 是更好的选择：

fs.watch(dir, (event, filename) => {});

watch 经过操做系统提供的文件更改通知机制，在 Linux 操做系统使用 inotify，在 macOS 系统使用 FSEvents,在 windows 系统使用 ReadDirectoryChangesW，并且能够用来监听目录的变化，在监听文件夹的场景中，比建立 N 个 fs.watchfile 效率高出不少。

$ node file-watcher.js
[2018-05-21T00:55:52.588Z] Watching for file changes on ./button-presses.log
[2018-05-21T00:56:00.773Z] button-presses.log file Changed
[2018-05-21T00:56:00.793Z] button-presses.log file Changed
[2018-05-21T00:56:00.802Z] button-presses.log file Changed
[2018-05-21T00:56:00.813Z] button-presses.log file Changed

但当咱们修改一个文件时，回调却执行了 4 次！缘由是文件被写入时，可能触发屡次写操做，即便只保存了一次。但咱们不须要这么敏感的回调，由于一般认为一次保存就是一次修改，系统底层写了几回文件咱们并不关心。

于是能够进一步判断是否触发状态是 change:

fs.watch(dir, (event, filename) => {
  if (filename && event === "change") {
    console.log(`${filename} file Changed`);
  }
});

这样作能够必定程度解决问题，但做者发现 Raspbian 系统不支持 rename 事件，若是归类为 change，会致使这样的判断毫无心义。

做者要表达的意思是，在不一样平台下， fs.watch 的规则可能会不一样，缘由是 fs.watch 分别使用了各平台提供的 api，因此没法保证这些 api 实现规则的统一性。

优化方案一：对比文件修改时间

基于 fs.watch，增长了对修改时间的判断：

let previousMTime = new Date(0);

fs.watch(dir, (event, filename) => {
  if (filename) {
    const stats = fs.statSync(filename);
    if (stats.mtime.valueOf() === previousMTime.valueOf()) {
      return;
    }
    previousMTime = stats.mtime;
    console.log(`${filename} file Changed`);
  }
});

log 由 4 个变成了 3 个，但依然存在问题。咱们认为文件内容变化才算有修改，但操做系统考虑的因素更多，因此咱们再尝试对比文件内容是否变化。

笔者补充：另一些开源编辑器可能先清空文件再写入，也会影响到触发回调的次数。

优化方案二：校验文件 md5

只有文件内容变化了，才认为触发了改动，这下总能够了吧：

let md5Previous = null;

fs.watch(dir, (event, filename) => {
  if (filename) {
    const md5Current = md5(fs.readFileSync(buttonPressesLogFile));
    if (md5Current === md5Previous) {
      return;
    }
    md5Previous = md5Current;
    console.log(`${filename} file Changed`);
  }
});

log 终于由 3 个变成了 2 个，为何多出一个？可能的缘由是，在文件保存过程当中，系统可能会触发多个回调事件，也许存在中间态。

优化方案三：加入延迟机制

咱们尝试延迟 100 毫秒进行判断，也许能避开中间状态：

let fsWait = false;
fs.watch(dir, (event, filename) => {
  if (filename) {
    if (fsWait) return;
    fsWait = setTimeout(() => {
      fsWait = false;
    }, 100);
    console.log(`${filename} file Changed`);
  }
});

这下 log 变成一个了。不少 npm 包在这里使用了 debounce 函数控制触发频率，才将触发频率修正。

并且咱们须要结合 md5 与延迟机制共同做用，才能获得相对精准的结果：

let md5Previous = null;
let fsWait = false;
fs.watch(dir, (event, filename) => {
  if (filename) {
    if (fsWait) return;
    fsWait = setTimeout(() => {
      fsWait = false;
    }, 100);
    const md5Current = md5(fs.readFileSync(dir));
    if (md5Current === md5Previous) {
      return;
    }
    md5Previous = md5Current;
    console.log(`${filename} file Changed`);
  }
});

3 精读

做者讨论了一些实现文件夹监听的基本方式，能够看出，使用了各平台原生 API 的 fs.watch 并不那么靠谱，但这也咱们监听文件的惟一手段，因此须要基于它进行一系列优化。

而实际场景中，还须要考虑区分文件夹与文件、软链接、读写权限等状况。

另外用在生产环境的库，也基本使用 50 到 100 毫秒解决重复触发的问题。

因此不管 chokidar 或 node-watch，都大量使用了文中说起的技巧，再加上对边界条件的处理，对软链接、权限等状况处理，将全部可能状况都考虑到，才能提供较为准确的回调。

好比判断文件写入操做是否完毕，也须要经过轮询的方式：

function awaitWriteFinish() {
  // ...省略
  fs.stat(
    fullPath,
    function(err, curStat) {
      // ...省略

      if (prevStat && curStat.size != prevStat.size) {
        this._pendingWrites[path].lastChange = now;
      }

      if (now - this._pendingWrites[path].lastChange >= threshold) {
        delete this._pendingWrites[path];
        awfEmit(null, curStat);
      } else {
        timeoutHandler = setTimeout(
          awaitWriteFinish.bind(this, curStat),
          this.options.awaitWriteFinish.pollInterval
        );
      }
    }.bind(this)
  );
  // ...省略
}

能够看出，第三方 npm 库都采起不信任操做系统回调的方式，根据文件信息彻底重写了判断逻辑。

可见，信任操做系统的回调，就没法抹平全部操做系统间的差别，惟有统一重写文件的 “写入”、“删除”、“修改” 等逻辑，才能保证在全平台的兼容性。

4 总结

利用 nodejs 监听文件夹变化很容易，但提供准确的回调却很难，主要难在两点：

1. 抹平操做系统间的差别，这须要在结合 fs.watch 的同时，增长一些额外校验机制与延时机制。
2. 分清楚操做系统预期与用户预期，好比编辑器的额外操做、操做系统的屡次读写都应该被忽略，用户的预期不会那么频繁，会忽略极小时间段内的连续触发。

另外还有兼容性、权限、软链接等其余因素要考虑，fs.watch 并非一个开箱可用的工程级别 api。

5 更多讨论

讨论地址是： 精读《如何利用 Nodejs 监听文件夹》 · Issue #87 · dt-fe/weekly

若是你想参与讨论，请点击这里，每周都有新的主题，周末或周一发布。