篇前声明：为了不涉及业务细节，篇内信息统一以某游戏，某功能代替
前不久，某游戏准备内测客户端，开发人员测试过程中发现某功能突然不灵了，之前的测试一切ok，没有发现任何异常，第一反应是，游戏内浏览器都是自己包装的，是不是做了什么改造，触发了某个盲点。
游戏方表示浏览器还是以前包装的Chromium，不过还真有不同的，就是UA改了，而且不是在原UA后加的后缀标识，而是完全替换，使用了游戏名称做UA，问题应该就在这里了，从代码上来看，不会触发任何雷区，理论上不会有问题，如果有问题，极有可能出现在框架中，YUI3的底层逻辑。
顺便抱怨一下，游戏内测试本身就是一个蛋痛的事情，基本都是自己封装浏览器，即使使用同样的内核，也有可能包装方式不同引出不同的坑，下载了一个游戏，使用fiddler神器代理js测试，js又一直被缓存，游戏内也不知道如何清缓存，代理不到，只能转而代理html页面，js加随机数时间戳。
第一步：YUI组件加载完毕打log
YUI({combine: true}).use('node', 'io', 'xml', function (Y) {
Y.log("init");
});
测试结果：没有log，验证了我的想法，影响YUI组件加载，框架层级的
第二步：增减组件测试
测试结果：刚开始毫无规律，确实有部分组件去掉以后可以正常加载，貌似有共同点，但又看不出明确的共同点，跟其他同事沟通，貌似这些组件加载了皮肤，单独加载其它自带皮肤的组件，果然有问题，而不带皮肤就ok
第三步：YUI组件加载打log观察
测试结果：果然，竟然… 只加载了皮肤，没有加载js
这个时候才想起来看抓包… 发现组件真的没加载
第四步：YUI组件加载代码分析
先来看YUI加载过程
从这个抓包图来看，分为四步，yui种子文件—》loader组件配置文件—》组件皮肤—》组件js代码
1. 加载yui.js
可以理解为种子文件，它将负责后续yui的模块加载，当执行YUI.use引用模块时，开始加载loader文件（如果只引用了种子文字，但没有写js去use方法，实际上不会加载模块的）
YUI的_init方法对loader的配置，_init:
config.base = YUI.config.base || Y.Env.getBase(/^(.*)yui\/yui([\.\-].*)js(\?.*)?$/, /^(.*\?)(.*\&)(.*)yui\/yui[\.\-].*js(\?.*)?$/);
config.loaderPath = YUI.config.loaderPath || 'loader/loader' + (filter || '-min.') + 'js';
use方法代码片段，开始加载loader
handleBoot = function() {
Y._loading = false;
queue.running = false;
Env.bootstrapped = true;
if (Y._attach(['loader'])) {
Y.use.apply(Y, args);
}
};
if (G_ENV._bootstrapping) {
queue.add(handleBoot);
} else {
G_ENV._bootstrapping = true;
var url = config.base + config.loaderPath;
url += (url.indexOf("?") > -1 ? "&" : "?") + "v=" + Y.Env.CACHE_VERSION;
Y.Get.script(url, {
onEnd: handleBoot
});
}
2. 加载loader.js
yui3为按需加载，Loader相当于所有组件的一个配置文件（yui最新版本已将loader直接放入yui.js，减少一个请求），配置内容包括所有的模块，模块的依赖项，模块的皮肤等，如果模块有皮肤，会优先加载，模块有依赖模块，也需要同时加载
我们来简单看一下loader的代码
"console": {
"requires": [
"yui-log",
"widget",
"substitute"
],
"skinnable": true
}
requires代表它依赖的其它模块，skinnable则代表它需要皮肤
模块添加时有这么一句代码 ，如果有皮肤，则添加皮肤
if (o.skinnable) {
this._addSkin(this.skin.defaultSkin, i, name);
}
_addSkin: function(skin, mod, parent) {
var mdef, pkg, name,
info = this.moduleInfo,
sinf = this.skin,
ext = info[mod] && info[mod].ext;
// Add a module definition for the module-specific skin css
if (mod) {
name = this.formatSkin(skin, mod);
if (!info[name]) {
mdef = info[mod];
pkg = mdef.pkg || mod;
this.addModule({
name: name,
group: mdef.group,
type: 'css',
after: sinf.after,
after_map: YArray.hash(sinf.after),
path: (parent || pkg) + '/' + sinf.base + skin + '/' + mod + '.css',
ext: ext
});
}
}
return name;
}
看一下addskin方法，会根据配置的基准路径寻找该皮肤文件，默认是该组件所在文件夹下面的assets/skins/sam下的同名css文件
3. Loader加载成功
重新回到yui.Js的user方法中来看，此时，该判断就会生效，便拿到了所有loader对象，获取到所有的组件加载项args
if (boot && len && Y.Loader) {
Y._loading = true;
loader = getLoader(Y);
loader.onEnd = handleLoader;
loader.context = Y;
// loader.attaching = args;
loader.data = args;
loader.require((fetchCSS) ? missing : args);
loader.insert(null, (fetchCSS) ? null : 'js');
}
一路追踪到loader.js中的loadNext，我们使用了合并的方式，该方法会将同类资源文件合并加载（js or css），然后调用Y.Get.js or Y.Get. css进行资源文件的加载，由此再追踪到yui.js中的_next方法
4. 组件加载
此时，开始进行组件加载，并跟踪加载流程
if (q.type === "script") {
n = _scriptNode(url, w, q.attributes);
} else {
n = _linkNode(url, w, q.attributes);
}
// track this node's load progress
_track(q.type, n, id, url, w, q.url.length);
创建script or link节点
// add it to the head or insert it before 'insertBefore'. Work around IE
// bug if there is a base tag.
insertBefore = q.insertBefore || d.getElementsByTagName('base')[0]; if (insertBefore) {
s = _get(insertBefore, id);
if (s) {
s.parentNode.insertBefore(n, s);
}
} else {
h.appendChild(n);
}
添加到页面上，这里皮肤css与js并不是完全的并行加载，对于webkit与gecko内核，直接开始加载下一个资源文件，即js
if ((ua.webkit || ua.gecko) && q.type === "css") {
_next(id, url);
}
我们看一下_track方法
if (ua.ie) {
n.onreadystatechange = function() {
var rs = this.readyState;
if ("loaded" === rs || "complete" === rs) {
n.onreadystatechange = null;
f(id, url);
}
};
// webkit prior to 3.x is no longer supported
} else if (ua.webkit) {
if (type === "script") {
// Safari 3.x supports the load event for script nodes (DOM2)
n.addEventListener("load", function() {
f(id, url);
});
}
// FireFox and Opera support onload (but not DOM2 in FF) handlers for
// script nodes. Opera, but not FF, supports the onload event for link
// nodes.
} else {
n.onload = function() {
f(id, url);
};
n.onerror = function(e) {
_fail(id, e + ": " + url);
};
}
ie浏览器通过readystatechange进行判断并加载后续的资源文件，其它浏览器如webkit則监听onload（即使监听失败，_next方法中可直接执行js加载）
我们加载的模块是console，但是只加载了css，js不见了，如下图，我不是webkit，我不是gecko，我也不是IE，然后就进入了死胡同
由于UA变更，没有将其判断为webkit，_next方法没有执行，加载完css后无法直接加载js，故只能依靠track方法，track方法判断其不属于IE浏览器，直接进入了else分支，但由于浏览器本身是Chromium内核，link节点的onload方法无法触发。进入了死万劫不复之地。
解决方法也比较简单，对于非css请求，依赖_trace方法触发回调其它js加载（js加载需要严格时序保证），而css请求，不依赖_trace，直接调用_next触发其它资源加载
该方法改动较小，风险较小，即使后续有新的UA变更或浏览器更新等，仍可以保证正常使用，缺点在于，如果加载过程中发生网络波动等异常，有可能出现样式闪动的问题。