岁月如歌

用开放的心态,打造专业的人生。

模块加载器获取URL的原理

with 4 comments

浏览器端的模块管理

JavaScript 构建的应用越来越复杂,为了提高代码的可维护性,第一步是拆分为多个文件:

a.js
b.js
c.js
...

 
文件拆开是第一步,为了彼此能互相调用,但又不污染全局造成潜在冲突,于是聪明的程序员们想出了用对象来模拟命名空间:

// a.js:
X = {};
X.a = {...};

// b.js:
X.b = {...};

// c.js:
X.c = {...};
...

 
这种命名空间得自己维护,当层级达到三层及其以上时,维护起来并不轻松,比如 YAHOO.widget.TreeView。于是出现了类似 YUI3 的扁平方式:

// 定义模块
YUI.add('a', factory);

// 加载模块
YUI().use('a', function(Y) {
  // 调用模块
  Y.a.doSomething();
});

 
这种方式解决了不少问题,比如依赖加载、模块沙箱、命名空间。但使用时,用户的记忆负担还是比较重,比如:

YUI().use('dd-drop', function(Y) {
  Y.DD...
});

 
得记住 dd-drop 和 Y.DD 的对应关系。当模块很多时,经常要查文档。

服务器端的模块管理

上面是浏览器端的发展。同一时期,服务端 JavaScript 也悄然兴起。开始有了 CommonJS/Modules 1.0 规范:

// math.js:
export.add = function(){...}

// program.js:
var math = require('./math');
math.add(1, 2);

 
通过 exports 和 require, 就可以向外提供模块和向内引入模块。在服务端,可即时读取文件,因此 require 是同步的,很方便。

CommonJS/Modules 1.0 用非常简单的规则,征服了 NodeJS 等社区。简单意味着记忆负担少,简单意味着清晰,简单意味着受众广,等等。

CommonJS 在服务端取得了很高的认可,当迁移到浏览器端时,由于浏览器的两大限制:

  1. Context: 不通过包裹,很难做到上下文环境的限制。
  2. Distance: 文件不能像服务端一样即时读取,需要远程链接。

加上浏览器的同源策略等限制,导致 CommonJS/Modules 1.0 规范在浏览器端只是看起来很美。

于是 CommonJS 社区展开了大讨论,基本上形成了两大派系,其中一派是 AMD 规范:

// a.js:
define(['./b'], function(B) {...});

// main.js:
require(['a.js'], function(A) {...});

 

RequireJS 与 YUI3 有类似的地方,YUI3 是将加载的依赖模块放在 Y 上,AMD 是直接作为参数传入。很显然,AMD 的记忆负担变轻了些。

除了 AMD 规范,CommonJS 的另一大派系,有 Wrappings 和 Modules/2.0 等规范。(注意:CommonJS 的模块规范里,只有 1.x 是正式版,其他都还在讨论中,未成定论。AMD 则脱离了 CommonJS 社区,成为独立的社区发展。)

Wrappings 等规范与 AMD 最大的不同点在于:

  1. Wrappings 尽量保持与 Modules 1.x 的兼容。
  2. Wrappings 的哲学是尽量保持简单,用最小的代价、最少的 API 来实现浏览器端的模块规范。
  3. Wrappings 尽量保持“懒”。能不执行的先不执行,需要时才初始化。

举个例子:

// a.js:
define(function(require, exports, module) {
  var b = require('./b');
  //...
});

 
在 Wrappings 规范里,除了外层包裹,里层代码绝大部分和服务端是一样的。

RequireJS 也支持一种 CommonJS Simple Wrapper 规范,只是长得一样,内蕴上是差异比较大的,比如:

// a.js:
define(function(require, exports, module) {
  alert(2);
});

// b.js:
define(function(require, exports, module) {
  alert(1);
  var a = require('./a');
});

 

在 AMD 和 Wrappings 等规范里,a 模块都会提前加载好,但对于什么时候执行 a 模块的 factory 代码,两派存在很大的差异。AMD 里,运行上面的代码,会先弹出 2, 然后才是 1. 在 Wrappings 等规范里,a 模块只是提取加载好,factory 的运行,会延迟到第一次 require 时,因此会先弹出 1, 然后才是 2, 和服务端的逻辑是一样的。

有点扯远了,萝卜白菜,各有所爱。我个人更喜欢 NodeJS 遵守的 CommonJS/Modules 1.x 规范,以及简单 Wrappings 模式。

回到本篇博客的正题。无论是 AMD 还是 Wrappings 规范,从 DRY 的原则上讲,都支持匿名 define 模块(这和 YUI3 要显式指明模块名是不同的),都是匿名模块了,那如何引用呢?肯定得有 id 的,这 id 就是 URI. 对于浏览器端来说,就是 URL. 模块的 URL 就是模块的唯一标识,很简单的道理,但能将此固化为标准并加以实现就不容易了。

串行获取方案

这是最简单的方式,一次只下载一个:

// 在执行 define 时:
var mod = {...};

// 在加载 script 时:
getScript(url, function() {
  // 保存模块
  save(url, mod);

  // 加载下一个模块
  next();
});

 
这样,每次只加载一个模块,url 的获取非常轻松,YUI3 早期也是这种模式。

现代浏览器下的获取方案

现代浏览器(排除IE6-8)下,有一个很强的规律:

脚本 a 执行完后,会立刻触发 a 的 onload 事件,中间不会被打断(除非被 alert 等操作强行打断)。

由于采用包裹的方式,alert 这种中断我们就不用考虑了。利用这个规律,很容易实现URL的获取:

// 在执行 define 时:
var mod = {...};

// 在加载 script 时:
getScript(url, function() {
  // 保存模块
  save(url, mod);
});

 
看起来和串行方案的唯一区别是没有 next(), 其实上复杂很多,a.js 和 b.js 的下载都是并发的,要通过递归回调等方式来处理依赖加载。

IE6-8 下的获取方案

如果这个世界上没有 IE,那么,会很糟糕的(必须承认 IE 对 Web 的伟大贡献),但现在 IE 的确成为了前端巨大的负担。在 IE6-8 下,脚本执行和脚本onload事件之间没有紧相邻的规律,比如:

// 记 a.js 的执行为 A, onload 为 a
// 记 b.js 的执行为 B, onload 为 b

// 同时加载 a.js 和 b.js 时,有可能是 ABab, 而不总是 AaBb

 

这个看起来很小的麻烦,要解决却是大麻烦。CommonJS 社区讨论了好久,后来出现了一种解决方案:

// 在执行 define 时:
var mod = {...};
var url = getInteractiveScript();
save(url, mod);

 
通过 getInteractiveScript, 在 define 执行时,就可获取到当前正在执行的脚本文件路径:

funcition getInteractiveScript() { 
  var scripts = head.getElementsByTagName('script');

  for (var i = 0; i < scripts.length; i++) {
    var script = scripts[i];
    if (script.readyState === 'interactive') {
      return script;
    }
  }
  return null;

 
正在执行的脚本,其 readyState 属性是 interactive. 这真是天才的发现,一切看起来很完美。

然而,当加载的文件是浏览器缓存好的文件时,IE的读取是“瞬间的”,这个瞬间绝对会秒杀你的想象,不光不会有 interactive 状态,还会像服务器一样“同步操作”:

// 在执行 define 时:
var mod = {...};

// 在加载 script 时:
var urlCache = url;
getScript(url, function() {
    save(urlCache, mod);
});
urlCache = null;

 
getScript 是异步的,但其 callback 里,却可“同步”获取到 urlCache 的值,诡异又强悍的 IE!

IE下的总方案

对于 IE9,和现代浏览器一样,采用紧相邻规律就行。

对于 IE6-8,先用 getInteractiveScript 的方案获取,获取不到时,再用同步 cache 的获取方式,倘若还是获取不到,则进一步降级到紧相邻规律(虽然不严格遵守,但大部分情况下,IE6-8 还是符合这一规律的)。

注意:IE6-8 下,虽然用了三种方式组合获取,但依旧可能获取失败。并行加载的文件越多,获取失败的概率越大,主要是 IE6 有问题。原因很复杂,尚未分析出具体规律。(好在概率很低,目前只发现 IE6 下,在获取没有设置缓存头的动态 js 文件时,会经常获取不到正确的 URL。)

目前 RequireJS、BravoJS、SeaJS 等等模块加载器采用的都是这个方案,可靠性不是 100%, 但还是非常值得信赖的,特别是考虑上线时还会经过打包优化。

Army 的方案

Army 最近做了一个很有趣的测试:onload次序测试,发现虽然无法保证 AbBbCc, 但执行的顺序和 onload 的顺序彼此是一致的,比如:ACaBcb. 如果大写字母的顺序是 ACB,则小写字母的顺序一定是 acb.

利用这个规律,可以很方便获取到 URL:

// 在执行 define 时:
var mod = {...};
defQueque.push(mod);

// 在加载 script 时:
getScript(url, function() {
  save(url, defQueque.shift());
});

 
如果能严格做到一个文件一个模块,采用这种方式是很完美的。注意:Army 博客中的测试数据显示还是有极少失败的概率,目前确切原因未知。但这个方法本身的确很好,是所有浏览器都遵守的统一规律。

更复杂的现实情况

API 的设计要尽可能简单,但另一方面,对使用时的场景又得尽可能的包容。在 Army 的方案中,如果有两个文件:

// a.js 是打包部署后的:
define(true, 'http://path/to/a.js', ...); 
// 在 army 方案中,打包后,会在 define 的参数前面添加两个参数来指明

// b.js 是新开发的,尚未打包的:
define(function(){...});

// 同时使用时:
use(["a.js", "b.js"], callback);

 
这种情况是很现实的,比如在老产品上开发新功能。

这时,a.js 不会给 defQueue 添加新项,b.js 则会给 defQueque 添加一项。但在 getScript 的 callback 中,比如 a.js 的 callback 里,是不知道 a.js 有无给 defQueue 添加项,这样信息是缺失的,会导致 defQueque.shift() 出来的与当前 callback 不对应而出现错乱。

面对现实情况,看似完美的方案,困境重重。(谁若简单的好策略,热烈欢迎交流回复,很希望能找出完满的方案。)

小结

困了,睡觉。今天的困惑,有可能是明天的希望。

Advertisements

Written by lifesinger

November 11, 2011 at 22:05

Posted in Articles

4 Responses

Subscribe to comments with RSS.

  1. 打包那里我还要说明一下,前提是1对1的文件模块。其实并没有“多个模块合并”的概念,而是当我使用1个模块时,如果这个模块会有很多依赖以及递归依赖,那么我选择打包功能,将这些依赖们统统combo进来不要多余的请求,那么此时这个模块不会做特殊处理加那2个参数,但是被combo的统统做了处理。因此不会对回调有困扰的。
    而且我的构建工具设计思路里有比较严格的校验过程,比如1对1的校验,不是这个规则的话java直接异常,不允许你提交。

    army8735

    November 12, 2011 at 10:58

  2. […] 不知道上下文的,请先阅读这篇博客:模块加载器获取 URL 的原理 […]

  3. 做了少许调整,你最后说的那个不对应我想是解决了。
    https://github.com/army8735/Ai/blob/master/base/amd.js

    army8735

    November 15, 2011 at 10:17

  4. 嘿嘿,我也发现onload事件执行顺序和异步加载的顺序是一致的了. https://github.com/latel/cook.js

    latel

    August 18, 2014 at 09:18


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s