requirejs不会保证按顺序运行目标脚本，只是保证它们的运行次序能满足各自的依赖性要求。从而我们确保了尽快的并行加载所有脚本，并有条不紊的按照依赖性拓扑结构去执行这些脚本。
四、总结
OK，谈到这儿，异步加载脚本的陈述也就完了。我再次啰嗦一下这里的优化顺序——
1> 传统的方式，我们使用script标签直接嵌入到html文档中，这里分两种情况——
a> 嵌入到head标签中——要注意，这样做并不会影响文档内容中其他静态资源文件的并行加载，它影响的是，文档内容的渲染，即此时的DOM渲染就会被阻塞，呈现白屏。
b> 嵌入到body标签底部——为了免去白屏现象，我们优先进行DOM的渲染，再去执行脚本，但问题又来了。先说第一个问题——如果DOM文档内容比较大，交互事件绑定便有了延迟，体验便差了些。当然，我们需要根据需求而定，让重要的脚本优先执行。再说第二个问题——由于脚本文件至于body底部，导致对于这些脚本的加载相对于至于head中的脚本而言，它们的加载便有了延迟。所以，至于body底部，也并非是优化的终点。
c> 添加defer属性——我们希望脚本尽早的进行并行加载，我们把这批脚本依旧放入head中。脚本的加载应该与文档的加载同时进行，并且不影响DOM的渲染。这样，一旦文档就绪就可以运行脚本。所以便有了defer这样属性。但是要注意它的兼容性，对于不支持defer属性的浏览器，我们需要将代码封装在诸如jQuery之$(document).ready中。需要注意一点，所有的defer属性的脚本，是按照其出场顺序依次执行，因此，它同样严格同步。
2> 上一点，讲的都是同步执行脚本（要注意，这些脚本的加载过程是并行的，只不过是谁先触发请求谁后触发请求的区别而已），接下来的优化点便是“并行执行脚本”，当然，我们知道，一个时间点，只有执行一个js文件，这里的“并行”是指，谁先加载完了，只要此时js引擎空闲，立马执行之。这里的优化分成两种——
a> 添加async这个属性——确实能够完成上面我们所说的优化点，但是它有很高的局限性，即仅仅是针对非依赖性脚本加载，最恰当的例子便是引入多个第三方脚本了。还有就是与deffer属性的合用，实在是让人大费脑筋。当然，它也存在兼容性问题。以上三个问题便导致其应用并不广泛。当使用async的时候，一定要严格注意依赖性问题。
b> 脚本加载脚本——很显然，我们使用之来达到“并行执行脚本”的目的。同时，我们也方便去控制脚本依赖的问题，我们便使用了如requirejs中对于js异步加载的智能化加载管理。
好，写到这儿。
这里，我仅仅谈的是异步加载脚本的相关内容。还有一块儿内容，便是异步加载样式文件或者其他静态资源。待续......
您可能感兴趣的文章: