背景

团队维护的项目框架采用的ng，后面技术栈导向改变，使用hybrid嵌入vue项目，但是突然有一天，release ng项目的时候，fis3 release能耗和cpu占用率非常高，从此每次开发的时候身边都有一架要起飞的✈️，不，说它是飞机都是客气了，这简直就是一个行星发动机！

我记得是在实习结束正式入职之后才这样的，当时以为是升级Catalina的问题 在心里狠狠地黑了一波mac开发者。

过程

1. 减少release模块文件夹

由于业务快速发展，模块文件指数级膨胀，心想有可能是文件太多导致的，于是先从指定编译模块文件夹开始，fork构建工具，然后加入命令行参数，-m [a,b,c]，再封装好，使得每次只编译自己要开发的部分，完成之后，release时间果然从60s+降低到10s

优化前：

优化后：

到这一步心中大喜，除了苏喂苏喂苏喂没有办法表达心中的激动，于是开开心心地开始开发。

然而，菜狗最大的问题就是不知道自己哪里菜。

虽然降低了release的时间，但是并没有降低能耗和cpu占用率，行星发动起正常运转。

2. 监听文件刷新

既然不是编译太多文件导致的，那么真相只有一个...

cpu占用率来自监测文件改动的过程中，于是我打开fis3的源码，一路摸到node_modules/fis3-command-release/lib/watch.js

简单看了下，尝试改了一些参数，几次修改无果。

此时我怒从心中起，恶向胆边生，把这个文件所有关于循环的方法都注释掉了，forEcah，map什么的。

一跑项目，得，行星发动机仍然运转正常😑。

3. chokidar

正当我对整个watch实现一筹莫展的时候，发现了chokidar的引用

令人智熄，竟然还有一个todo

众所周知，我留的todo一般不会做，fis3的开发人员todo也没有做，那么我=fis3开发人员

通过打开checkIgnore方法可以看到：

这里通过读取project.ignore的正则配置，来过滤是否要监听的文件，我尝试在这个输出一下path，结果一下就卡住了，它遍历了当前目录所有的文件，包括引入的hybird子项目的所有文件，难怪卡成这样了，于是在对应project.ignore的地方加上过滤文件夹配置，将监听文件夹也做好配置修改，就大功告成了，如果只编译我负责的模块内容的话，能耗从450+降低到100。

结尾

这个问题其实可以说是引入hybird会遇到的通常性问题，母项目的文件监测误加了子项目的所有文件，导致性能开销很大。

最后，我愿称我自己为最佳节能王、环保小助手、低碳排放公民。