本期精读的文章是:How to Watch for Files Changes in Node.js,探讨如何监听文件的变化。node
若是想使用现成的库,推荐 chokidar 或 node-watch,若是想了解实现原理,请往下阅读。git
使用 fs
内置函数 watchfile
彷佛能够解决问题:github
fs.watchFile(dir, (curr, prev) => {});
复制代码
但你可能会发现这个回调执行有必定延迟,由于 watchfile
是经过轮询检测文件变化的,它并不能实时做出反馈,并且只能监听一个文件,存在效率问题。typescript
使用 fs
的另外一个内置函数 watch
是更好的选择:npm
fs.watch(dir, (event, filename) => {});
复制代码
watch
经过操做系统提供的文件更改通知机制,在 Linux 操做系统使用 inotify,在 macOS 系统使用 FSEvents,在 windows 系统使用 ReadDirectoryChangesW,并且能够用来监听目录的变化,在监听文件夹的场景中,比建立 N 个 fs.watchfile
效率高出不少。windows
$ 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 次!缘由是文件被写入时,可能触发屡次写操做,即便只保存了一次。但咱们不须要这么敏感的回调,由于一般认为一次保存就是一次修改,系统底层写了几回文件咱们并不关心。api
于是能够进一步判断是否触发状态是 change
:bash
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 个,但依然存在问题。咱们认为文件内容变化才算有修改,但操做系统考虑的因素更多,因此咱们再尝试对比文件内容是否变化。
笔者补充:另一些开源编辑器可能先清空文件再写入,也会影响到触发回调的次数。
只有文件内容变化了,才认为触发了改动,这下总能够了吧:
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`);
}
});
复制代码
做者讨论了一些实现文件夹监听的基本方式,能够看出,使用了各平台原生 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 库都采起不信任操做系统回调的方式,根据文件信息彻底重写了判断逻辑。
可见,信任操做系统的回调,就没法抹平全部操做系统间的差别,惟有统一重写文件的 “写入”、“删除”、“修改” 等逻辑,才能保证在全平台的兼容性。
利用 nodejs 监听文件夹变化很容易,但提供准确的回调却很难,主要难在两点:
fs.watch
的同时,增长一些额外校验机制与延时机制。另外还有兼容性、权限、软链接等其余因素要考虑,fs.watch
并非一个开箱可用的工程级别 api。
若是你想参与讨论,请点击这里,每周都有新的主题,周末或周一发布。