解刨gulp中steam pipe的异步并行坑

最近在写一个项目,基于gulp做一个components的工作流框架,通过这个框架去add,build,preview,test,publish,目前还在开发阶段,不过已经实现了一些基本功能,而且开发出的pipe-queuepipe-matrix也是基于这个工作流实现的。不过这两个组件原本是为了实现我的这个框架,结果在倒腾框架的过程中诞生了这两个组件,而它们又是在框架中诞生的,真说不清是“鸡生蛋还是蛋生鸡”。

在这个过程里面,躺了很多stream pipe的坑,所以打算今天就来慢慢谈谈。事先说好,我在写的时候思维乱跳,可能会穿插一些吐槽,做好心理准备。

gulp和grunt的本质区别

我之前是在grunt上跑任务,改起来也很顺手,思维完全是清晰的,看着一个个组件在自己的工作流下面出来,心中也暗爽出一种上帝视角,这种“谜之自信”在我进入gulp开发的第三天被打碎。

gulp和grunt的本质区别在于:gulp是对文件流的一种工作流,而且完全遵守node的异步思想。而grunt嘛……并没有什么node的思想,如果一定要尊称一下,可以称之为“工作流的祖先”吧。

gulp的所有的一切都是围绕文件转,你在gulp开发里面要动的东西,永远都是文件,无论做什么事,到最后你都是为了把文件怎样怎样。比如你gulp.src是为了弄过来文件,gulp.dest是为了搞出到文件,gulp.watch是为了监视文件,对不起,“文件”不是一个人,真的是计算机里面的file。

但是,怎么搞文件呢?gulp抓住了内在核心,那就是流(stream)这个东西,虽然在node中stream有多种,但是在gulp里面,主要就是搞file stream,当然,这里面也有file buffer的戏份。但是不管怎样,gulp.src完,你一定要回到node的pipe机制,通过pipe去对文件流进行处理。处理文件流,是gulp性能上优于grunt的第一个原因。

异步并行的gulp

这个搞文件流的过程,和node一样,是异步的,也就是说当你在gulp任务中用多个pipe去处理不同的stream的时候,这几个stream的处理过程是异步的,他们会同时发生,而且一旦开始,就转到child_process里面去搞,搞完了如果你不做处理,根本不知道。这也就是为什么gulp.task的回调函数要用一种方式去通知的原因,它有三种方式通知:返回一个stream,返回一个Promise,直接调用callback。如果不做上面三选一的处理,那么gulp.task的代码执行完几乎就是一瞬间的事情,你的cli一闪而过,根本不知道后面发生了什么事情。

举个栗子更性感:

gulp.task('default',function(){
    gulp.src('src/*.js').pipe(..要花1分钟处理的..).pipe(gulp.dest('dist'));
});

你以为上面这段代码会在terminal里面等一分钟以后才提示你任务完成了吗?不,绝对不会。它会告诉你default task结束啦,于是你兴冲冲跑去dist目录看,啥都没有。正确的做法是:

gulp.task('default',function(){
    return gulp.src('src/*.js').pipe(..要花1分钟处理的..).pipe(gulp.dest('dist'));
});

返回的是一个stream类型,gulp会监听这个stream的情况,直到一个end的emit事件被抛出来,gulp才会提示你任务结束。

再来一个栗子让你吃饱:

gulp.task('default',function(){
    gulp.src('src/*.es6').pipe(..要花1分钟转码..).pipe(gulp.dest('src'));
    return gulp.src('src/*.js').pipe(..花5秒钟合并文件的..).pipe(gulp.dest('dist'));
});

gulp又提示你任务结束啦,你跑去dist目录看,尼玛什么也没有,感觉被世界欺骗了一样。上面两个stream是异步并行的,这也就是说,第一个stream和第二个stream会同时开始,所以第二个stream并没有发现src目录下的.js文件,所以草草结束了,1分钟之后src目录下才产生了.js,可是这个时候,下面个stream早都结束了,你只能再运行一遍这个任务才能实现目的。那到底要怎样才能实现我们的目的,转码完后再去执行合并文件的操作呢?这个在下文有答案。

异步是gulp获得更高性能的重要原因,然而“并行”让开发者吃尽苦头。我刚开始遇到这个情况的时候,简直就是彻夜难眠。还好,后来被我解决了,并且产生了pipe-queue这个组件。

发挥异步并行优势

异步好是好,但是你是不是感觉好像没啥用,反而给你带来了一些不方便。确实,刚开始的时候,由于“异步”我总是不能在cli里面得到自己想要的信息,由于“并行”总是导致文件无法正确处理。但是慢慢思考之后,就好像被上帝摸了一下脑袋,领悟了一些道理。

异步并行这个思想,简直就是神来之笔,让工作流效率高很多很多。

举一个栗子先:我们经常会先撰写自己的代码,然后要编译和打包,一般的流程是“js编译,然后模块的浏览器端支持,合并,混淆;样式的编译,合并,混淆”。如果按照同步串行的方式,必须按照上面的步骤一个一个去做,异步并行就不用,因为非常明显,样式的合并混淆跟js的任何一个动作都没有半毛钱关系,所以我们应该在这个任务里面把文件流分为两条线,一条处理js,一条处理css,但是必须等到这两条线都完成,才算整个任务完成。这个任务所花的时候,是比较长那条线所花的时间,而不是两条线的总和。

但是无奈,js的后面的处理步骤必须依赖前面的步骤。所以在一条线内,又必须串行。这就是坑了,暂且不说在不了解gulp相关的背景下怎么实现上面说的“完成任务的标准”,单就这个“依赖”就很麻烦。

gulp官方给出的方案是,通过task之间的依赖关系来实现,比如创建jsCompile, jsConcat, jsMinify三个任务,然后在jsConcat的依赖中加入jsCompile,在jsMinify的依赖中加入jsConcat,这样当你运行jsMinify的时候,前面两个依赖都会被执行,而且还是按照依赖的关系顺序执行。但是这种思想非常恶心,创建一个任务本来就是希望这个任务完成我想要的事情,何必拆分为多个任务呢?当然,有的时候有些小任务在不同的其他任务中都可能用到,可以单独出来,但是如果有些任务根本没有必要呢?所以,同步串行的东西,在编程世界里,也是必须要有的啊,不然node为什么也有很多sync的方法呢?

合并异步并行的stream的实现

前面提到的,A和B两条stream的pipe line并行非常棒,应该发挥这个功效,但是问题是,怎么实现判断何时这个任务才算结束,在cli中给出finished的提示呢?其实这是stream的机制,我们可以通过将A和B的两个stream注入到一个新的stream中,而这个stream里面可以去构造何时emit一个end事件。

基于这个思想,参考了别人的代码,我实现了一个pipe-concat组件,使用它可以实现这个功能。

npm install --save-dev pipe-concat
var gulp = require('gulp');
var concat = require('pipe-concat');

gulp.task('build',function(){
    var stream1 = gulp.src(...).pipe(...).pipe(gulp.dest(..));
    var stream2 = ...
    var stream = concat(stream1,stream2);
    return stream;
});

concat返回的是一个stream,所以它可以直接被return给gulp的回调函数,这样gulp在监听到这个新的stream抛出的end事件时,才会结束当前的任务。

通过上面这个方法,我们实现了并行多个异步任务,在同一个任务里面,做多件事,这样可以节省执行时间,提升我们的开发效率。

有个槽点,就是到底用concat和merge作为名称。我们知道这两个单词都有合并的意思,但是我认为concat更符合这里的场景,merge是合并,意思是会有覆盖重写的,有重复的就合并,但是concat没有,它是连接,concat真的就是把后面的往前面的尾巴上加。而我们这个地方实际上是把两条stream pipe line叠加在一起,不改变pipe line本身的任何内容,而且从空间逻辑上,他们也有先后顺序。只不过没有完全合并为一条线而已。

串行stream pipe line的实现

接下来,我们就要干一件大事,就是把并行的stream硬生生改为串行,从而实现前一个步骤完成之后,再执行后面一个步骤。这个时候,我们有了步骤的概念,有了等待被执行的概念,我就要顺势推出pipe queue的概念了。

pipe queue就是具有先后顺序的pipe line的组合。因为还没有提到pipe matrix,所以我还暂时不上图。一条pipe line其实处理了一个stream,虽然这个line中有多个pipe,但是他们的对象是连贯的,这组pipe不可以分开对待。但是pipe queue就不同了,它是line的队列,前一个line处理完毕,后面一个line才会继续。

基于这种思维,我创建了pipe-queue这个组件,使用如下:

npm install --save-dev pipe-queue
var gulp = require('gulp');
var PipeQueue = require('pipe-queue');

gulp.task('build',function(){
    var stream1 = gulp.src(...).pipe(...).pipe(gulp.dest(..));
    var stream2 = ...

    var $queue = new PipeQueue();
    $queue.when(stream1,stream2).then(function(next,concat){
        var stream1 = ...
        var stream2 = ...
        concat(stream1,stream2).on('end',next);
    }).then(...).end(function(){
        console.log('finished!');
    });

    return $queue.promise();
});

你在这个例子里面看到的,感觉上不是很简单,因此不说说是不行的。

首先,PipeQueue是一个类,真的是一个class类型,你可以去看源码,只不过我用babel把它转码了而已。实例化这个类后放到$queue里面,可以去调用它的when, then, end,具体的用法就不再这里说了,去我GitHub上去看,都有非常详细的说明。

为什么一定要把后面那两个stream放在函数里去,而不像when一样,直接当参数传进去?其实道理很简单,就是当参数传进去时,实际上pipe line已经开始了,stream已经在流动了,而且很快就会结束,而把他们放到then的函数里面的时候,只有去调用并运行这个函数时,里面的pipe line才会开始,这就是最终的秘诀。

另一个秘诀就是,给了一个next作为下一个then的行动信号,也就是说,如果你不在then的函数里调用next(),那么下一个then绝对不会执行,这样下一个then里面的stream也不会开始流了。

而末尾的那个promise是为了返回给gulp的,因为gulp只能通过前面说过的三种方式获得回调通知,而且callback形式在异步中是没法用的,而queue又不能返回一个stream类型,所以这里只能构造一个Promise来实现啦。

有了pipe-queue,就可以把具有依赖的两个不同的pipe line按照我们惯有的逻辑思维组织起来,比如上面的js的build过程,不用再写多个子任务,然后到依赖里面去一层套一层了。

而且,由于pipe-queue是依赖于pipe-concat实现的when方法,所以实际上如果仅仅是想并行完成pipe line,而不计较使用使用end事件的话,pipe-queue的when也可以并行完成几条line。

并行同步的stream pipe line的实现

搞定了串行的stream pipe line就剩下最后一个问题,就是我要让build js和build css那两条线同时运行,以用时更长的那条线的结束作为整个任务的结束。

思路就相对简单很多,其中两条线各自通过pipe-queue来实现,现在的问题就是,有没有一个机制可以知道哪条线跑的时间更久?这当然是可以的。这种两条线并行跑的形式,就是并行同步,也就是整体上是并行,但是每个并行的line内部是同步串行的。基于这种思想,我开发了pipe-matrix。matrix的意思是“矩阵”,我要实现的,不仅仅是几条线的并行同步执行,我希望任何一种形式都可以通过pipe-matrix去实现,所以,总得来说,pipe-matrix就是处理pipe queue的并行问题的解决方案。

pipe-matrix-model

上图是一个示意图,给了很多case。pipe就是一个绿色块,一个一个的管道,这些管道连接在一起就是pipe line,是stream处理的最常见形式,也是gulp里面的默认形式,即case1。而case2则是演示了当需要在几条line并行运行,且全部完成后抛出end的过程。case3则是pipe queue的演示。case4是pipe matrix的演示,pipe-matrix不仅可以让几条queue并行,而且可以在并行完之后串行至下一个matrix。

使用方法也很简单:

npm install --save-dev pipe-matrix
var gulp = require('gulp');
var PipeQueue = require('pipe-queue');
var PipeMatrix = require('pipe-matrix');

gulp.task('default',function(){
    var stream1 = ...
    var stream2 = ...
    var $queue1 = new PipeQueue();
    $queue1.when(stream1,stream2)... // 注意,这里不能使用end,即使使用了也无效
    ...
    var $queue2 = ...
    ...
    var $matrix = new PipeMatrix();
    $matrix.when($queue1,$queue2).then(function(next){
        // ...
    }).end(function(){...});

    return $matrix.promise();
});

可以看到,其实pipe-matrix的用法和pipe-queue的用法非常像,只不过pipe-matrix面对的是queue,而非pipe line,这也就是说,在pipe-matrix中跟stream本身其实没多大关系了,matrix中,主要监测的,是pipe queue的完成情况,这也就是为什么我在matrix中说,如果你没有用到pipe queue,就没必要用这个组件的原因。

同步完成多个步骤的小技巧

gulp中有非常多的隐藏技巧并没有被官方文档暴露给我们,官方总是希望我们用他们希望的方式去写依赖,而实际上,我们可以用一种小技巧去避免。这就需要我们理解一下pipe,当pipe line结束的时候,stream其实还在,它被放在内存中,等待释放。而如果我们这个时候立即用另一个pipe line去操作它,那么它会被拾起来,继续投入战斗。举个栗子时间:

var stream = gulp.src(srcDir + '/js/index.js')
    // webpack code
    .pipe(webpack({
        module: {
            loaders: [
                {
                    test: /\.js$/, 
                    loaders:['babel?{"presets":["latest"]}']
                },
            ],
        },
    }))
    .pipe(rename(name + '.js'))
    .pipe(gulp.dest(distDir + '/js/'))
    // minify code
    .pipe(uglify())
    .pipe(rename({suffix:'.min'}))
    .pipe(gulp.dest(distDir + '/js/'))
return stream;

其实上面这段代码有两个pipe line,因为在gulp.dest的时候,已经输出了文件,但是另一个pipe马上去接上,这就相当于两个分开的pipe line首尾相连,实际上就是一个pipe line。所以上面的pipe line会输出两个文件,一个是webpack打包后的原始文件,另一个是uglify压缩后并且加上.min后缀的混淆文件。

所以最后的最后,当我们再看前文js和css的任务时,其实只需要用到pipe-concat就可以了,因为js和css各自的工作流靠这里的小技巧就解决了。再通过pipe-concat合并两个stream,就可以完成我们想要的效果了。

废了这么大篇幅,从pipe-queue绕到pipe-matrix,现在又绕了回来。这就是一个不可饶恕的坑啊,也许只有在自我折腾中,才能成长吧。

有了上面这些组件,帮我们完成各类异步并串行的pipe line,基本上可以帮我们搞定所有gulp的任务了。还等什么,赶紧搞起来。

2016-11-26 | , , ,