js脚本异步问题
‘壹’ 我对JS异步执行机制的理解
说起JS的异步执行机制，如果网络一下，你首先会发现阮一峰的写过一篇关于异步机制的文章（ http://www.ruanyifeng.com/blog/2014/10/event-loop.html ），等你津津有味又一头雾水的看完，然后继续看网络的其他结果，然后会发现，阮一峰的这篇被另一个大牛朴灵给批判了
（ http://www.360doc.com/content/14/1011/13/15077656_416048738.shtml ）。
由此可见，关于异步执行机制到底是怎么回事，因为涉及到浏览器底层机制，所以不容易彻底了解清楚，就算是大牛阮一峰，也只是通过英文文献来了解，而且一知半解。我的这篇文章只是试图尽可能简单的描述一下JS的异步执行机制，坦白说，我现在并不能完全弄懂这个机制，所以也不能完全解释清这个机制，所以，如果我写的越严谨，就越容易出错，我只能简单但是较模糊的描述一下：
JS的运行环境是一个很复杂的环境，它里面有非常多的复杂的名词事物，用简单又不严谨的说法来说，运行环境里至少有下面这些事物：
有一个国外的web app，专门用来讲解异步事件的门道 Loupe ，这个更接近真实情况。为什么我不讲解这个？因为更复杂了，我们并不打算研究浏览器的底层，不是么？
然后说一下任务队列里的任务。所有任务可以分成两种，一种是同步任务（synchronous），另一种是异步任务（asynchronous）。同步任务指的是，靠主线程自己就可以执行完成的任务；异步任务指的是，主线程执行开始之后，需要靠主线程之外的线程才能完成的任务。由主线程决定是否要动用其他线程。以下内容，不再提栈，只说主线程。
现在说重点：
异步任务的执行机制是：
当主线程遇到一个异步任务，比如一个ajax请求，当主线程执行到 xhr.send() 的时候，这个send命令是立即执行的， 并不会像一些人想象的，拖到所有同步任务的最后面。 然后主线程向http线程发送指令，要求http线程向服务器发送请求。这里强调一下http线程，显然它不是主线程的一部分，因为它可以并发，如果你有100个ajax请求，每个都需要1秒钟，是不是http线程要花100秒呢？并不是，它会并发100个请求，总共耗时大约1.01秒就完成了。
主线程向以http线程为代表的几个线程发送指令之后，主线程就暂时不再管这个ajax任务了，而是去看任务队列里的下一个任务。
http线程发送了请求之后接收反馈，收到之后，形成一个新的事件（可以叫做“我收到啦！”事件），然后插入到回调函数队列中，因为回调函数队列的优先级很低，所以会排到总队列的最后面，其结果就是：主线程把同步任务都完成了，才开始执行异步事件的 回调 。 注意，并不是异步任务在全体同步任务结束之后才开始，而是异步任务的回调通常在全体同步任务结束之后才开始！异步任务跟异步任务的回调是两回事！是两个任务！一个鲜明的例子就是 setTimeout(fn, 1000) ，计时是从主线程遇到 setTimeout() 任务，然后分配给计时器线程，计时器线程开始干活的时候就开始计时了！只不过要1秒之后 fn 才执行！ setTimeout() 和 fn 是两个任务！ setTimeout() 是立即执行， fn 才是1秒之后执行。但是 setTimeout() 的执行，人眼是感受不到的，因为并没有什么地方有一个秒表告诉你 setTimeout() 开始执行了；而fn的执行，人眼能感受到，所以人们会错误的以为fn才是异步任务，其实fn并不是， fn 是个回调任务，往往 fn 是同步任务，比如 fn 可能是 console.log(123) ，这怎么会是异步任务。
所以，异步机制是浏览器的两个或以上常驻线程共同完成的，异步请求是JS主线程和其他某个线程共同完成的，JS的执行线程发起异步请求（这时浏览器会开一条新的HTTP请求线程来执行请求，这时JS自己的任务已完成，继续执行线程队列中剩下的其他任务），然后在未来的某一时刻"任务队列"线程监视到之前的发起的HTTP请求已完成， "任务队列"就会把完成事件插入到JS执行队列的尾部等待JS处理 。
最后专门说说定时触发（settimeout和setinterval）。
定时触发是由浏览器的定时器线程执行的定时计数， 然后在定时时间到达之后，定时器线程把定时处理函数的执行请求插入到JS回调队列的尾端。
这个1到底是100毫秒之后弹出，还是1000毫秒（或更多时间）后弹出呢？又或是1100毫秒之后弹出？
答案是，1000毫秒多一点点之后弹出。
原因：浏览器会先执行setTimeout，也就是开始计时，然后开始执行sometask，执行了1000毫秒，然后去回调队列里看回调任务，alert(1);早就恭候了，因为定时100毫秒之后alert(1)就可以执行了。所以，等1000毫秒的任务完成，1就会立即弹出，所以答案是1000毫秒多一点点之后弹出。
所以用这两个函数的时候，实际的执行时间是大于或等于指定时间的，不保证能准确定时的。
最后强调一下setInterval。比如我希望每100毫秒打印一个1。然后，又有极端情况，就是sometask耗时1000毫秒。你以为sometask结束之后会打出10个1么？并不会，只会打出1个1，因为setInterval第一次读秒结束之后，回调队列出现了一个alert(1)，根据之前的理论，并不会执行。又过了100毫秒之后，计时器线程会去观察回调队列是不是已经有了alert(1)，如果有，就不再往回调队列里加alert(1)，目的就是为了避免回调叠加执行。
总之，你需要记住，异步任务就是主线程在任务队列里看到了这个任务，看了一眼之后就然后安排别的线程帮忙，然后主线程就忙别的去了，别的线程帮忙完事之后，再在队列末尾放一个新任务叫“帮忙完毕”，到此异步任务本身就完事。主任务看到“帮忙完毕”任务之后，就去执行回调，回调执行完，这个异步任务连同回调就全都完事。然后，如果并没有回调。。。没有就没有呗。
‘贰’ JS异步操作新体验之 async函数
文章来自 https://www.cnblogs.com/rogerwu/p/10784236.html
async 函数返回一个 Promise 实例对象，可以使用 then 方法添加回调函数。
当函数执行时，一旦遇到 await 就会先返回，等到异步操作完成，再接着执行函数体内后面的语句
（1）、async 函数内部 return语句返回的值，会成为then方法回调函数的参数
（2）、async 函数内部抛出错误，会导致返回的 Promise对象变成reject状态，抛出的错误会被catch方法回调函数接收到
（3）、只有 async 函数内部的异步操作执行完，才会执行 then方法指定的回调函数
实际应用
‘叁’ js异步加载的方式有哪些
方法一：Script Dom Element
(function(){
var scriptEle = document.createElement("script");
scriptEle.type = "text/javasctipt";
scriptEle.async = true;
scriptEle.src = "http://cdn.bootcss.com/jquery/3.0.0-beta1/jquery.min.js";
var x = document.getElementsByTagName("head")[0];
x.insertBefore(scriptEle, x.firstChild);
})();
方法二：onload时的异步加载
function(){
if(window.attachEvent){
window.attachEvent("load", asyncLoad);
}else{
window.addEventListener("load", asyncLoad);
}
var asyncLoad = function(){
var ga = document.createElement('script');
ga.type = 'text/javascript';
ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(ga, s);
}
})();
方法三：$(document).ready()
‘肆’ js执行顺序+同步异步
按照js同步执行的顺序，函数调用会首先执行for循环，循环5次开启了5个延迟器，延时器内部的回调函数将会异步执行，会在延时1s后进入消息队列等待执行。循环了5次，所以此时i的值为5，然后同步执行console.log打印5，第一次同步执行结束，然后开始执行消息队列的异步任务，打印5个5，中间的undefined是函数调用无返回值返回的。
执行顺序和第一题相同，不同的是延时器被包裹在了一个立即执行函数内容，并把每一次循环的i作为参数传入，此时循环内部的函数形成了一个私有作用域，每一次的i变量被独立保存了起来，因此每一次循环的i的值都会被打印出来。
延时器内部回调函数是异步函数，将在延时结束后，进入消息队列等待执行，因此同步的console.log("CCCC")最优先执行，然后延时0ms的延时器的回调先进入消息队列，1000ms后第一个延时器的回调再进入消息队列等待执行，因此先执行0ms的回调打印DDDD，再执行1000ms的回调打印BBBB。
这里与上一题不同的是中间多了一个执行3s的同步while循环，因此执行顺序是这样的：
第一个延时器延时1s后内部异步回调函数进入消息队列等待执行，
等待while循环3s后打印"CCCC"，
循环结束后第一个延时器内部的回调已经进入消息队列第一个执行位置等待执行。
第二个延时器延时0s后内部异步回调函数进入消息队列等待执行，延时结束后排到第一个延时器的回调函数后面，
因此异步队里内部先打印"BBBB"，再打印"DDDD"
‘伍’ javascript中异步操作的异常怎么处理
一、JavaScript异步编程的两个核心难点
异步I/O、事件驱动使得单线程的JavaScript得以在不阻塞UI的情况下执行网络、文件访问功能，且使之在后端实现了较高的性能。然而异步风格也引来了一些麻烦，其中比较核心的问题是：
1、函数嵌套过深
JavaScript的异步调用基于回调函数，当多个异步事务多级依赖时，回调函数会形成多级的嵌套，代码变成
金字塔型结构。这不仅使得代码变难看难懂，更使得调试、重构的过程充满风险。
2、异常处理
回调嵌套不仅仅是使代码变得杂乱，也使得错误处理更复杂。这里主要讲讲异常处理。
二、异常处理
像很多时髦的语言一样，JavaScript 也允许抛出异常，随后再用一个try/catch
语句块捕获。如果抛出的异常未被捕获，大多数JavaScript环境都会提供一个有用的堆栈轨迹。举个例子，下面这段代码由于'{'为无效JSON
对象而抛出异常。
?
12345678
function JSONToObject(jsonStr) { return JSON.parse(jsonStr);}var obj = JSONToObject('{');//SyntaxError: Unexpected end of input//at Object.parse (native)//at JSONToObject (/AsyncJS/stackTrace.js:2:15)//at Object.<anonymous> (/AsyncJS/stackTrace.js:4:11)
堆栈轨迹不仅告诉我们哪里抛出了错误，而且说明了最初出错的地方：第4 行代码。遗憾的是，自顶向下地跟踪异步错误起源并不都这么直截了当。
异步编程中可能抛出错误的情况有两种：回调函数错误、异步函数错误。
1、回调函数错误
如果从异步回调中抛出错误，会发生什么事？让我们先来做个测试。
?
1234567
setTimeout(function A() { setTimeout(function B() { setTimeout(function C() { throw new Error('Something terrible has happened!'); }, 0); }, 0);}, 0);
上述应用的结果是一条极其简短的堆栈轨迹。
?
12
Error: Something terrible has happened!at Timer.C (/AsyncJS/nestedErrors.js:4:13)
等等，A 和B 发生了什么事？为什么它们没有出现在堆栈轨迹中？这是因为运行C 的时候，异步函数的上下文已经不存在了，A 和B 并不在内存堆栈里。这3
个函数都是从事件队列直接运行的。基于同样的理由，利用try/catch
语句块并不能捕获从异步回调中抛出的错误。另外回调函数中的return也失去了意义。
?
1234567
try { setTimeout(function() { throw new Error('Catch me if you can!'); }, 0);} catch (e) {console.error(e);}
看到这里的问题了吗？这里的try/catch 语句块只捕获setTimeout函数自身内部发生的那些错误。因为setTimeout
异步地运行其回调，所以即使延时设置为0，回调抛出的错误也会直接流向应用程序。
总的来说，取用异步回调的函数即使包装上try/catch 语句块，也只是无用之举。（特例是，该异步函数确实是在同步地做某些事且容易出错。例如，Node
的fs.watch(file,callback)就是这样一个函数，它在目标文件不存在时会抛出一个错误。）正因为此，Node.js
中的回调几乎总是接受一个错误作为其首个参数，这样就允许回调自己来决定如何处理这个错误。
2、异步函数错误
由于异步函数是立刻返回的，异步事务中发生的错误是无法通过try-catch来捕捉的，只能采用由调用方提供错误处理回调的方案来解决。
例如Node中常见的function (err, ...)
{...}回调函数，就是Node中处理错误的约定：即将错误作为回调函数的第一个实参返回。再比如HTML5中FileReader对象的onerror函数，会被用于处理异步读取文件过程中的错误。
举个例子，下面这个Node 应用尝试异步地读取一个文件，还负责记录下任何错误（如“文件不存在”）。
?
1234567
var fs = require('fs'); fs.readFile('fhgwgdz.txt', function(err, data) { if (err) { return console.error(err); }; console.log(data.toString('utf8'));});
客户端JavaScript 库的一致性要稍微差些，不过最常见的模式是，针对成败这两种情形各规定一个单独的回调。jQuery 的Ajax
方法就遵循了这个模式。
?
1234
$.get('/data', { success: successHandler, failure: failureHandler});
不管API 形态像什么，始终要记住的是，只能在回调内部处理源于回调的异步错误。
三、未捕获异常的处理
如果是从回调中抛出异常的，则由那个调用了回调的人负责捕获该异常。但如果异常从未被捕获，又会怎么样？这时，不同的JavaScript环境有着不同的游戏规则……
1. 在浏览器环境中
现代浏览器会在开发人员控制台显示那些未捕获的异常，接着返回事件队列。要想修改这种行为，可以给window.onerror
附加一个处理器。如果windows.onerror 处理器返回true，则能阻止浏览器的默认错误处理行为。
?
123
window.onerror = function(err) { return true; //彻底忽略所有错误};
在成品应用中， 会考虑某种JavaScript 错误处理服务， 譬如Errorception。Errorception
提供了一个现成的windows.onerror 处理器，它向应用服务器报告所有未捕获的异常，接着应用服务器发送消息通知我们。
2. 在Node.js 环境中
在Node 环境中，window.onerror 的类似物就是process 对象的uncaughtException 事件。正常情况下，Node
应用会因未捕获的异常而立即退出。但只要至少还有一个uncaughtException 事件处理
器，Node 应用就会直接返回事件队列。
?
123
process.on('uncaughtException', function(err) { console.error(err); //避免了关停的命运！});
但是，自Node 0.8.4 起，uncaughtException 事件就被废弃了。据其文档所言，对异常处理而言，uncaughtException
是一种非常粗暴的机制，请勿使用uncaughtException，而应使用Domain 对象。
Domain 对象又是什么？你可能会这样问。Domain 对象是事件化对象，它将throw 转化为'error'事件。下面是一个例子。
?
123456789
var myDomain = require('domain').create();myDomain.run(function() { setTimeout(function() { throw new Error('Listen to me!') }, 50);});myDomain.on('error', function(err) { console.log('Error ignored!');});
源于延时事件的throw 只是简单地触发了Domain 对象的错误处理器。
Error ignored!
很奇妙，是不是？Domain 对象让throw
语句生动了很多。不管在浏览器端还是服务器端，全局的异常处理器都应被视作最后一根救命稻草。请仅在调试时才使用它。
四、几种解决方案
下面对几种解决方案的讨论主要集中于上面提到的两个核心问题上，当然也会考虑其他方面的因素来评判其优缺点。
1、Async.js
首先是Node中非常着名的Async.js，这个库能够在Node中展露头角，恐怕也得归功于Node统一的错误处理约定。
而在前端，一开始并没有形成这么统一的约定，因此使用Async.js的话可能需要对现有的库进行封装。
Async.js的其实就是给回调函数的几种常见使用模式加了一层包装。比如我们需要三个前后依赖的异步操作，采用纯回调函数写法如下：
?
12345678910111213141516
asyncOpA(a, b, (err, result) => { if (err) { handleErrorA(err); } asyncOpB(c, result, (err, result) => { if (err) { handleErrorB(err); } asyncOpB(d, result, (err, result) => { if (err) { handlerErrorC(err); } finalOp(result); }); });});
如果我们采用async库来做：
?async.waterfall([ (cb) => { asyncOpA(a, b, (err, result) => { cb(err, c, result); }); }, (c, lastResult, cb) => { asyncOpB(c, lastResult, (err, result) => { cb(err, d, result); }) }, (d, lastResult, cb) => { asyncOpC(d, lastResult, (err, result) => { cb(err, result); }); }], (err, finalResult) => { if (err) { handlerError(err); } finalOp(finalResult);});
可以看到，回调函数由原来的横向发展转变为纵向发展，同时错误被统一传递到最后的处理函数中。
其原理是，将函数数组中的后一个函数包装后作为前一个函数的末参数cb传入，同时要求：
每一个函数都应当执行其cb参数;cb的第一个参数用来传递错误。我们可以自己写一个async.waterfall的实现：
?let async = { waterfall: (methods, finalCb = _emptyFunction) => { if (!_isArray(methods)) { return finalCb(new Error('First argument to waterfall must be an array of functions')); } if (!methods.length) { return finalCb(); } function wrap(n) { if (n === methods.length) { return finalCb; } return function (err, ...args) { if (err) { return finalCb(err); } methods[n](...args, wrap(n + 1)); } } wrap(0)(false); }};
Async.js还有series/parallel/whilst等多种流程控制方法，来实现常见的异步协作。
Async.js的问题：
在外在上依然没有摆脱回调函数，只是将其从横向发展变为纵向，还是需要程序员熟练异步回调风格。
错误处理上仍然没有利用上try-catch和throw，依赖于“回调函数的第一个参数用来传递错误”这样的一个约定。
2、Promise方案
ES6的Promise来源于Promise/A+。使用Promise来进行异步流程控制，有几个需要注意的问题，
把前面提到的功能用Promise来实现，需要先包装异步函数，使之能返回一个Promise：
?
12345678910
function toPromiseStyle(fn) { return (...args) => { return new Promise((resolve, reject) => { fn(...args, (err, result) => { if (err) reject(err); resolve(result); }) }); };}
这个函数可以把符合下述规则的异步函数转换为返回Promise的函数：
回调函数的第一个参数用于传递错误，第二个参数用于传递正常的结果。接着就可以进行操作了：
?
123456789101112131415
let [opA, opB, opC] = [asyncOpA, asyncOpB, asyncOpC].map((fn) => toPromiseStyle(fn)); opA(a, b) .then((res) => { return opB(c, res); }) .then((res) => { return opC(d, res); }) .then((res) => { return finalOp(res); }) .catch((err) => { handleError(err); });
通过Promise，原来明显的异步回调函数风格显得更像同步编程风格，我们只需要使用then方法将结果传递下去即可，同时return也有了相应的意义：
在每一个then的onFullfilled函数（以及onRejected）里的return，都会为下一个then的onFullfilled函数（以及onRejected）的参数设定好值。
如此一来，return、try-catch/throw都可以使用了，但catch是以方法的形式出现，还是不尽如人意。
3、Generator方案
ES6引入的Generator可以理解为可在运行中转移控制权给其他代码，并在需要的时候返回继续执行的函数。利用Generator可以实现协程的功能。
将Generator与Promise结合，可以进一步将异步代码转化为同步风格：
?
1234567891011
function* getResult() { let res, a, b, c, d; try { res = yield opA(a, b); res = yield opB(c, res); res = yield opC(d); return res; } catch (err) { return handleError(err); }}
然而我们还需要一个可以自动运行Generator的函数：
?
2324252627282930
function spawn(genF, ...args) { return new Promise((resolve, reject) => { let gen = genF(...args); function next(fn) { try { let r = fn(); if (r.done) { resolve(r.value); } Promise.resolve(r.value) .then((v) => { next(() => { return gen.next(v); }); }).catch((err) => { next(() => { return gen.throw(err); }) }); } catch (err) { reject(err); } } next(() => { return gen.next(undefined); }); });}
用这个函数来调用Generator即可：
?
1234567
spawn(getResult) .then((res) => { finalOp(res); }) .catch((err) => { handleFinalOpError(err); });
可见try-catch和return实际上已经以其原本面貌回到了代码中，在代码形式上也已经看不到异步风格的痕迹。
类似的功能有co/task.js等库实现。
4、ES7的async/await
ES7中将会引入async function和await关键字，利用这个功能，我们可以轻松写出同步风格的代码，
同时依然可以利用原有的异步I/O机制。
采用async function，我们可以将之前的代码写成这样：
?
12345678910111213
async function getResult() { let res, a, b, c, d; try { res = await opA(a, b); res = await opB(c, res); res = await opC(d); return res; } catch (err) { return handleError(err); }} getResult();
和Generator & Promise方案看起来没有太大区别，只是关键字换了换。
实际上async
function就是对Generator方案的一个官方认可，将之作为语言内置功能。
async function的缺点：
await只能在async function内部使用，因此一旦你写了几个async function，或者使用了依赖于async
function的库，那你很可能会需要更多的async function。
目前处于提案阶段的async
function还没有得到任何浏览器或Node.JS/io.js的支持。Babel转码器也需要打开实验选项，并且对于不支持Generator的浏览器来说，还需要引进一层厚厚的regenerator
runtime，想在前端生产环境得到应用还需要时间。
以上就是本文的全部内容，希望对大家的学习有所帮助。
‘陆’ js单线程和js异步操作的几种方法
为了解决这个问题，Javascript语言将任务的执行模式分成两种：同步（Synchronous）和异步（Asynchronous）。
"同步模式"就是上一段的模式，后一个任务等待前一个任务结束，然后再执行，程序的执行顺序与任务的排列顺序是一致的、同步的；"异步模式"则完全不同，每一个任务有一个或多个回调函数（callback），前一个任务结束后，不是执行后一个任务，而是执行回调函数，后一个任务则是不等前一个任务结束就执行，所以程序的执行顺序与任务的排列顺序是不一致的、异步的。
"异步模式"非常重要。在浏览器端，耗时很长的操作都应该异步执行，避免浏览器失去响应，最好的例子就是Ajax操作。在服务器端，"异步模式"甚至是唯一的模式，因为执行环境是单线程的，如果允许同步执行所有http请求，服务器性能会急剧下降，很快就会失去响应。
‘柒’ js 如何判断是异步请求还是普通请求
这是根据请求时的参数来决定的啊，如果async为true就是异步请求，为false就是同步请求。也就是说，是否异步请求是由前端决定的，后台程序是不作区分一视同仁处理的。前端如果是以同步方式发出请求，它就会阻塞程序，等待后台返回数据再继续运行；而异步方式的话，就会立刻返回，继续执行其他代码，当后台返回数据时再以回调函数的形式进行处理。既然同步异步是由前端决定的，那么前端的js自然就知道如何来处理这个请求结果啦。
‘捌’ js异步问题怎么解决
异步加载又叫非阻塞加载，浏览器在下载执行js的同时，还会继续进行后续页面的处理。主要有三种方式。
方法一：也叫Script DOM Element
(function(){
var scriptEle = document.createElement("script");
scriptEle.type = "text/javasctipt";
scriptEle.async = true;
scriptEle.src = "http://cdn.bootcss.com/jquery/3.0.0-beta1/jquery.min.js";
var x = document.getElementsByTagName("head")[0];
x.insertBefore(scriptEle, x.firstChild);
})();
<async>属性是HTML5中新增的异步支持。此方法被称为Script DOM Element 方法。Google Analytics 和 Google+ Badge 都使用了这种异步加载代码
(function(){;
var ga = document.createElement('script');
ga.type = 'text/javascript';
ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(ga, s);
})();
但是这种加载方式执行完之前会阻止onload事件的触发，而现在很多页面的代码都在onload时还执行额外的渲染工作，所以还是会阻塞部分页面的初始化处理。
方法二：onload时的异步加载
(function(){
if(window.attachEvent){
window.attachEvent("load", asyncLoad);
}else{
window.addEventListener("load", asyncLoad);
}
var asyncLoad = function(){
var ga = document.createElement('script');
ga.type = 'text/javascript';
ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0];
s.parentNode.insertBefore(ga, s);
}
)();
这种方法只是把插入script的方法放在一个函数里面，然后放在window的onload方法里面执行，这样就解决了阻塞onload事件触发的问题。
注:DOMContentLoaded与load的区别。前者是在document已经解析完成，页面中的dom元素可用，但是页面中的图片，视频，音频等资源未加载完，作用同jQuery中的ready事件；后者的区别在于页面所有资源全部加载完毕。
方法三：其他方法
由于JavaScript的动态性，还有很多异步加载方法： XHR Injection、 XHR Eval、 Script In Iframe、 Script defer属性、 document.write(script tag)。
XHR Injection(XHR 注入)：通过XMLHttpRequest来获取javascript，然后创建一个script元素插入到DOM结构中。ajax请求成功后设置script.text为请求成功后返回的responseText。
//获取XMLHttpRequest对象，考虑兼容性。
var getXmlHttp = function(){
var obj;
if (window.XMLHttpRequest)
obj = new XMLHttpRequest();
else
obj = new ActiveXObject("Microsoft.XMLHTTP");
return obj;
};
//采用Http请求get方式;open()方法的第三个参数表示采用异步(true)还是同步(false)处理
var xmlHttp = getXmlHttp();
xmlHttp.open("GET", "http://cdn.bootcss.com/jquery/3.0.0-beta1/jquery.min.js", true);
xmlHttp.send();
xmlHttp.onreadystatechange = function(){
if (xmlHttp.readyState == 4 && xmlHttp.status == 200){
var script = document.createElement("script");
script.text = xmlHttp.responseText;
document.getElementsByTagName("head")[0].appendChild(script);
}
}
XHR Eval：与XHR Injection对responseText的执行方式不同，直接把responseText放在eval()函数里面执行。
//获取XMLHttpRequest对象，考虑兼容性。
var getXmlHttp = function(){
var obj;
if (window.XMLHttpRequest)
obj = new XMLHttpRequest();
else
obj = new ActiveXObject("Microsoft.XMLHTTP");
return obj;
};
//采用Http请求get方式;open()方法的第三个参数表示采用异步(true)还是同步(false)处理
var xmlHttp = getXmlHttp();
xmlHttp.open("GET", "http://cdn.bootcss.com/jquery/3.0.0-beta1/jquery.min.js", true);
xmlHttp.send();
xmlHttp.onreadystatechange = function(){
if (xmlHttp.readyState == 4 && xmlHttp.status == 200){
eval(xmlHttp.responseText);
//alert($);//可以弹出$,表明JS已经加载进来。click事件放在其它出会出问题，应该是还没加载进来
$("#btn1").click(function(){
alert($(this).text());
});
}
}
Script In Irame：在父窗口插入一个iframe元素，然后再iframe中执行加载JS的操作。
var insertJS = function(){alert(2)};
var iframe = document.createElement("iframe");
document.body.appendChild(iframe);
var doc = iframe.contentWindow.document;//获取iframe中的window要用contentWindow属性。
doc.open();
doc.write("<script>var insertJS = function(){};<\/script><body onload='insertJS()'></body>");
doc.close();
GMail Mobile：业内JS内容被注释，所以不会执行，在需要的时候，获取script中的text内容去掉注释，调用eval()执行。
<script type="text/javascript">
/*
var ...
*/
</script>
HTML5新属性：async和defer属性
defer属性：IE4.0就出现。defer属声明脚本中将不会有document.write和dom修改。浏览器会并行下载其他有defer属性的script。而不会阻塞页面后续处理。注：所有的defer脚本必须保证按顺序执行的。
<script type="text/javascript" defer></script>
async属性：HTML5新属性。脚本将在下载后尽快执行，作用同defer，但是不能保证脚本按顺序执行。他们将在onload事件之前完成。
<script type="text/javascript" defer></script>
Firefox 3.6、Opera 10.5、IE 9和最新的Chrome和Safari都支持async属性。可以同时使用async和defer，这样IE 4之后的所有IE都支持异步加载。
没有async属性，script将立即获取（下载）并执行，期间阻塞了浏览器的后续处理。如果有async属性，那么script将被异步下载并执行，同时浏览器继续后续的处理。
总结： 对于支持HTML5的浏览器，实现JS的异步加载只需要在script元素中加上async属性，为了兼容老版本的IE还需加上defer属性；对于不支持HTML5的浏览器(IE可以用defer实现)，可以采用以上几种方法实现。原理基本上都是向DOM中写入script或者通过eval函数执行JS代码，你可以把它放在匿名函数中执行，也可以在onload中执行，也可以通过XHR注入实现，也可以创建一个iframe元素，然后在iframe中执行插入JS代码。
‘玖’ js/javascript 异步执行方法
var xmlHttp;
function createXMLHttpRequest(){
//Mozilla 浏览器（将XMLHttpRequest对象作为本地浏览器对象来创建）
if(window.XMLHttpRequest){ //Mozilla 浏览器
xmlHttp = new XMLHttpRequest();
}else if(window.ActiveXObject) { //IE浏览器
//IE浏览器（将XMLHttpRequest对象作为ActiveX对象来创建）
try{
xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
}catch(e){
try {
xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
}catch(e){}
}
}
if(xmlHttp == null){
alert("不能创建XMLHttpRequest对象");
return false;
}
}
//用于发出异步请求的方法
function sendAsynchronRequest(url,parameter,callback){
createXMLHttpRequest();
if(parameter == null){
//设置一个事件处理器，当XMLHttp状态发生变化，就会出发该事件处理器，由他调用
//callback指定的javascript函数
xmlHttp.onreadystatechange = callback;
//设置对拂去其调用的参数（提交的方式，请求的的url，请求的类型（异步请求））
xmlHttp.open("GET",url,true);//true表示发出一个异步的请求。
xmlHttp.send(null);
}else{
xmlHttp.onreadystatechange = callback;
xmlHttp.open("POST",url,true);
xmlHttp.setRequestHeader("Content-Type","application/x-www-form-urlencoded;");
xmlHttp.send(parameter);
}
}
//以上代码是通用的方法，接下来是调用以上的方法
function loadPros(title,count,pid,cid,level){
// 调用异步请求方法
url = "。。。。。。。。";
sendAsynchronRequest(url,null,loadCallBack);
}
// 指定回调方法
function loadCallBack(){
try
{
if (xmlHttp.readyState == 4) {
if (xmlHttp.status == 200) {
if(xmlHttp.responseText != null && xmlHttp.responseText != ""){
var divProid = document.getElementById('videolist');
divProid.innerHTML = xmlHttp.responseText;
for(i=0;i<len;i++)
{
var video_url = document.getElementById("videolist"+i+"").href;
if(video_url != undefined && video_url != null && video_url != ""){
window.location.href = video_url;
}
}
}
}
}
if (xmlHttp.readyState == 1)
{
//alert("正在加载连接对象......");
}
if (xmlHttp.readyState == 2)
{
//alert("连接对象加载完毕。");
}
if (xmlHttp.readyState == 3)
{
//alert("数据获取中......");
}
}
catch (e)
{
//alert(e);
}
}
‘拾’ javascript脚本如何异步加载，有什么作用
关于JavaScript脚本加载的问题，相信大家碰到很多。主要在几个点——
1> 同步脚本和异步脚本带来的文件加载、文件依赖及执行顺序问题
2> 同步脚本和异步脚本带来的性能优化问题
深入理解脚本加载相关的方方面面问题，不仅利于解决实际问题，更加利于对性能优化的把握并执行。
先看随便一个script标签代码——
复制代码代码如下:
<script src="js/myApp.js"></script>
如果放在<head>上面，会阻塞所有页面渲染工作，使得用户在脚本加载完毕并执行完毕之前一直处于“白屏死机”状态。而<body>末尾的打脚本只会让用户看到毫无生命力的静态页面，原本应该进行客户端渲染的地方却散布着不起作用的控件和空空如也的方框。拿一个测试用例——
代码如下:
<!DOCTYPE html>
<html>
<head lang="en">
<meta charset="UTF-8">
<title>异步加载script</title>
<script src="js/test.js"></script>
</head>
<body>
<div>我是内容</div>
<img src="img/test.jpg">
</body>
</html>
其中,test.js中的内容——
代码如下:
alert('我是head里面的脚本代码，执行这里的js之后，才开始进行body的内容渲染!');
我们会看到,alert是一个暂停点，此时，页面是空白的。但是要注意，此时整个页面已经加载完毕，如果body中包含某些src属性的标签(如上面的img标签)，此时浏览器已经开始加载相关内容了。总之要注意——js引擎和渲染引擎的工作时机是互斥的（一些书上叫它为UI线程）。
因此,我们需要——那些负责让页面更好看、更好用的脚本应该立即加载，而那些可以待会儿再加载的脚本稍后再加载。