256 |
257 |
258 |
259 |
260 |
261 | 你可以给包裹按钮的div绑定一个事件处理函数，而不是给每个按钮绑定一个。然后你可以使用和前面的示例中一样的myHandler()函数，但需要修改一个小地方：你需要将你不感兴趣的点击排除掉。在这个例子中，你只关注按钮上的点击，而在同一个div中产生的其它的点击应该被忽略掉。
262 |
263 | myHandler()的改变就是检查事件来源的nodeName是不是“button”:
264 |
265 | // ...
266 | // get event and source element
267 | e = e || window.event;
268 | src = e.target || e.srcElement;
269 |
270 | if (src.nodeName.toLowerCase() !== "button") {
271 | return;
272 | }
273 | // ...
274 |
275 | 事件委托的坏处是筛选容器中感兴趣的事件使得代码看起来更多了，但好处是性能的提升和更干净的代码，这个好处明显大于坏处，因此这是一种强烈推荐的模式。
276 |
277 | 主流的JavaScript库通过提供方便的API的方式使得使用事件委托变得很容易。比如YUI3中有Y.delegate()方法，它允许你指定一个用来匹配包裹容器的CSS选择器和一个用于匹配你感兴趣的节点的CSS选择器。这很方便，因为如果事件发生在你不关心的元素上时，你的事件处理回调函数不会被调用。在这种情况下，绑定一个事件处理函数很简单：
278 |
279 | Y.delegate('click', myHandler, "#click-wrap", "button");
280 |
281 | 感谢YUI抽象了浏览器的差异，已经处理好了事件的来源，使得回调函数更简单了：
282 |
283 | function myHandler(e) {
284 |
285 | var src = e.currentTarget,
286 | parts;
287 |
288 | parts = src.get('innerHTML').split(": ");
289 | parts[1] = parseInt(parts[1], 10) + 1;
290 | src.set('innerHTML', parts[0] + ": " + parts[1]);
291 |
292 | e.halt();
293 | }
294 |
295 | 你可以在message from the background thread: " + event.data + "
"; 319 | }; 320 | 321 | 下面展示了一个做1亿次简单的数学运算的web worker： 322 | 323 | var end = 1e8, tmp = 1; 324 | 325 | postMessage('hello there'); 326 | 327 | while (end) { 328 | end -= 1; 329 | tmp += end; 330 | if (end === 5e7) { // 5e7 is the half of 1e8 331 | postMessage('halfway there, `tmp` is now ' + tmp); 332 | } 333 | } 334 | 335 | postMessage('all done'); 336 | 337 | web worker使用postMessage()来和调用它的程序通讯，调用者通过onmessage事件来接受更新。onmessage事件处理函数接受一个事件对象作为参数，这个对象含有一个由web worker传过来data属性。类似的，调用者（在这个例子中）也可以使用ww.postMessage()来给web worker传递数据，web worker可以通过一个onmessage事件处理函数来接受这些数据。 338 | 339 | 上面的例子会在浏览器中打印出： 340 | 341 | message from the background thread: hello there 342 | message from the background thread: halfway there, `tmp` is now 3749999975000001 message from the background thread: all done 343 | 344 | ## 远程脚本编程 345 | 346 | 现代web应用经常会使用远程脚本编程和服务器通讯，而不刷新当前页面。这使得web应用更灵活，更像桌面程序。我们来看一下几种用JavaScript和服务器通讯的方法。 347 | 348 | ### XMLHttpRequest 349 | 350 | 现在，XMLHttpRequest是一个特别的对象（构造函数），绝大多数浏览器都可以用，它使得我们可以从JavaScript来发送HTTP请求。发送一个请求有以下三步： 351 | 352 | 1. 初始化一个XMLHttpRequest对象（简称XHR） 353 | 2. 提供一个回调函数，供请求对象状态改变时调用 354 | 3. 发送请求 355 | 356 | 第一步很简单： 357 | 358 | var xhr = new XMLHttpRequest(); 359 | 360 | 但是在IE7之前的版本中，XHR的功能是使用ActiveX对象实现的，所以需要做一下兼容处理。 361 | 362 | 第二步是给readystatechange事件提供一个回调函数： 363 | 364 | xhr.onreadystatechange = handleResponse; 365 | 366 | 最后一步是使用open()和send()两个方法触发请求。open()方法用于初始化HTTP请求的方法（如GET，POST）和URL。send()方法用于传递POST的数据，如果是GET方法，则是一个空字符串。open()方法的最后一个参数用于指定这个请求是不是异步的。异步是指浏览器在等待响应的时候不会阻塞，这明显是更好的用户体验，因此除非必须要同步，否则异步参数应该使用true： 367 | 368 | xhr.open("GET", "page.html", true); 369 | xhr.send(); 370 | 371 | 下面是一个完整的示例，它获取新页面的内容，然后将当前页面的内容替换掉（可以在" + xhr.responseText + "<\/pre>"; };
399 |
400 | xhr.open("GET", "page.html", true);
401 | xhr.send("");
402 |
403 | 代码中的一些说明：
404 |
405 | - 因为IE6及以下版本中，创建XHR对象有一点复杂，所以我们通过一个数组列出ActiveX的名字，然后遍历这个数组，使用try-catch块来尝试创建对象。
406 | - 回调函数会检查xhr对象的readyState属性。这个属性有0到4一共5个值，4代表“complete”（完成）。如果状态还没有完成，我们就继续等待下一次readystatechange事件。
407 | - 回调函数也会检查xhr对象的status属性。这个属性和HTTP状态码对应，比如200（OK）或者是404（Not found）。我们只对状态码200感兴趣，而将其它所有的都报为错误（为了简化示例，否则需要检查其它不代表出错的状态码）。
408 | - 上面的代码会在每次创建XHR对象时检查一遍支持情况。你可以使用前面提到过的模式（如条件初始化）来重写上面的代码，使得只需要做一次检查。
409 |
410 | ### JSONP
411 |
412 | JSONP（JSON with padding）是另一种发起远程请求的方式。与XHR不同，它不受浏览器同源策略的限制，所以考虑到加载第三方站点的安全影响的问题，使用它时应该很谨慎。
413 |
414 | 一个XHR请求的返回可以是任何类型的文档：
415 |
416 | - XML文档（过去很常用）
417 | - HTML片段（很常用）
418 | - JSON数据（轻量、方便）
419 | - 简单的文本文件及其它
420 |
421 | 使用JSONP的话，数据经常是被包裹在一个函数中的JSON，函数名称在请求的时候提供。
422 |
423 | JSONP的请求URL通常是像这样：
424 |
425 | http://example.org/getdata.php?callback=myHandler
426 |
427 | getdata.php可以是任何类型的页面或者脚本。callback参数指定用来处理响应的JavaScript函数。
428 |
429 | 这个URL会被放到一个动态生成的\元素中，像这样：
430 |
431 | var script = document.createElement("script");
432 | script.src = url;
433 | document.body.appendChild(script);
434 |
435 | 服务器返回一些作为参数传递给回调函数的JSON数据。最终的结果实际上是页面中多了一个新的脚本，这个脚本的内容就是一个函数调用，如：
436 |
437 | myHandler({"hello": "world"});
438 |
439 | （译注：原文这里说得不是太明白。JSONP的返回内容如上面的代码片段，它的工作原理是在页面中动态插入一个脚本，这个脚本的内容是函数调用+JSON数据，其中要调用的函数是在页面中已经定义好的，数据以参数的形式存在。一般情况下数据由服务端动态生成，而函数由页面生成，为了使返回的脚本能调用到正确的函数，在请求的时候一般会带上callback参数以便后台动态返回处理函数的名字。）
440 |
441 | #### JSONP示例：井字棋
442 |
443 | 我们来看一个使用JSONP的井字棋游戏示例，玩家就是客户端（浏览器）和服务器。它们两者都会产生1到9之间的随机数，我们使用JSONP去取服务器产生的数字（图8-2）。
444 |
445 | 你可以在玩这个游戏。
446 |
447 | 
448 |
449 | 图8-2 使用JSONP的井字棋游戏
450 |
451 | 界面上有两个按钮：一个用于开始新游戏，一个用于取服务器下的棋（客户端下的棋会在一定数量的延时之后自动进行）：
452 |
453 |
454 |
455 |
456 | 界面上包含9个单元格，每个都有对应的id，比如：
457 |
458 |
459 |
460 |
461 | ...
462 |
463 | 整个游戏是在一个全局对象ttt中实现：
464 |
465 | var ttt = {
466 | // cells played so far
467 | played: [],
468 |
469 | // shorthand
470 | get: function (id) {
471 | return document.getElementById(id);
472 | },
473 |
474 | // handle clicks
475 | setup: function () {
476 | this.get('new').onclick = this.newGame;
477 | this.get('server').onclick = this.remoteRequest;
478 | },
479 |
480 | // clean the board
481 | newGame: function () {
482 | var tds = document.getElementsByTagName("td"),
483 | max = tds.length,
484 | i;
485 | for (i = 0; i < max; i += 1) {
486 | tds[i].innerHTML = " ";
487 | }
488 | ttt.played = [];
489 | },
490 |
491 | // make a request
492 | remoteRequest: function () {
493 | var script = document.createElement("script");
494 | script.src = "server.php?callback=ttt.serverPlay&played=" + ttt.played.join(',');
495 | document.body.appendChild(script);
496 | },
497 |
498 | // callback, server's turn to play
499 | serverPlay: function (data) {
500 | if (data.error) {
501 | alert(data.error);
502 | return;
503 | }
504 |
505 | data = parseInt(data, 10);
506 | this.played.push(data);
507 |
508 | this.get('cell-' + data).innerHTML = 'X<\/span>';
509 |
510 | setTimeout(function () {
511 | ttt.clientPlay();
512 | }, 300); // as if thinking hard
513 | },
514 |
515 | // client's turn to play
516 | clientPlay: function () {
517 | var data = 5;
518 |
519 | if (this.played.length === 9) {
520 | alert("Game over");
521 | return;
522 | }
523 |
524 | // keep coming up with random numbers 1-9
525 | // until one not taken cell is found
526 | while (this.get('cell-' + data).innerHTML !== " ") {
527 | data = Math.ceil(Math.random() * 9);
528 | }
529 | this.get('cell-' + data).innerHTML = 'O';
530 | this.played.push(data);
531 | }
532 | };
533 |
534 | ttt对象维护着一个已经填过的单元格的列表ttt.played，并且将它发送给服务器，这样服务器就可以返回一个没有玩过的数字。如果有错误发生，服务器会像这样响应：
535 |
536 | ttt.serverPlay({"error": "Error description here"});
537 |
538 | 如你所见，JSONP中的回调函数必须是公开的并且全局可访问的函数，它并不一定要是全局函数，也可以是一个全局对象的方法。如果没有错误发生，服务器将会返回一个函数调用，像这样：
539 |
540 | ttt.serverPlay(3);
541 |
542 | 这里的3是指3号单元格是服务器要下棋的位置。在这种情况下，数据非常简单，甚至都不需要使用JSON格式，只需要一个简单的值就可以了。
543 |
544 | ### 框架（frame）和图片信标(image beacon)
545 |
546 | 另外一种做远程脚本编程的方式是使用框架。你可以使用JavaScript来创建框架并改变它的src URL。新的URL可以包含数据和函数调用来更新调用者，也就是框架之外的父页面。
547 |
548 | 远程脚本编程中最最简单的情况是你只需要传递一点数据给服务器，而并不需要服务器的响应内容。在这种情况下，你可以创建一个新的图片，然后将它的src指向服务器的脚本：
549 |
550 | new Image().src = "http://example.org/some/page.php";
551 |
552 | 这种模式叫作图片信标，当你想发送一些数据给服务器记录时很有用，比如做访问统计。因为信标的响应对你来说完全是没有用的，所以通常的做法（不推荐）是让服务器返回一个1x1的GIF图片。更好的做法是让服务器返回一个“204 No Content”HTTP响应。这意味着返回给客户端的响应只有响应头（header）而没有响应体（body）。
553 |
554 | ## 部署JavaScript
555 |
556 | 在生产环境中使用JavaScript时，有不少性能方面的考虑。我们来讨论一下最重要的一些。如果需要了解所有的细节，可以参见O'Reilly出社的《高性能网站建设指南》和《高性能网站建设进阶指南》。
557 |
558 | ### 合并脚本
559 |
560 | 创建高性能网站的第一个原则就是尽量减少外部引用的组件（译注：这里指文件），因为HTTP请求的代价是比较大的。具体就JavaScript而言，可以通过合并外部脚本来显著提高页面加载速度。
561 |
562 | 我们假设你的页面正在使用jQuery库，这是一个.js文件。然后你使用了一些jQuery插件，这些插件也是单独的文件。这样的话在你还一行代码都没有写的时候就已经有了四五个文件了。把这些文件合并起来是很有意义的，尤其是其中的一些体积很小（2-3kb）时，这种情况下，HTTP协议中的开销会比下载本身还大。合并脚本的意思就是简单地创建一个新的js文件，然后把每个文件的内容粘贴进去。
563 |
564 | 当然，合并的操作应该放在代码部署到生产环境之前，而不是在开发环境中，因为这会使调试变得困难。
565 |
566 | 合并脚本的不便之处是：
567 |
568 | - 在部署前多了一步操作，但这很容易使用命令行自动化工具来做，比如使用Linux/Unix的cat：
569 |
570 | $ cat jquery.js jquery.quickselect.js jquery.limit.js > all.js
571 | - 失去一些缓存上的便利——当你对某个文件做了一点小修改之后，会使得整个合并后的代码缓存失效。所以比较好的方法是为大的项目设定一个发布计划，或者是将代码合并为两个文件：一个包含可能会经常变更的代码，另一个包含那些不会轻易变更的“核心”。
572 | - 你需要处理合并后文件的命名或者是版本问题，比如使用一个时间戳all_20100426.js或者是使用文件内容的hash值。
573 |
574 | 这就是主要的不便之处，但它带来的好处却是远远大于这些麻烦的。
575 |
576 | ### 压缩代码
577 |
578 | 第二章中，我们讨论过代码压缩。部署之前进行代码压缩也是一个很重要的步骤。
579 |
580 | 从用户的角度来想，完全没有必要下载代码中的注释，因为这些注释根本不影响代码运行。
581 |
582 | 压缩代码带来的好处多少取决于代码中注释和空白的数量，也取决于你使用的压缩工具。平均来说，压缩可以减少50%左右的体积。
583 |
584 | 服务端脚本压缩也是应该要做的事情。配置启用gzip压缩是一个一次性的工作，能带来立杆见影的速度提升。即使你正在使用共享的空间，供应商并没有提供那么多服务器配置的空间，大部分的供应商也会允许使用.htaccess配置文件。所以可以将这些加入到站点根目录的.htaccess文件中：
585 |
586 | AddOutputFilterByType DEFLATE text/html text/css text/plain text/xml application/javascript application/json
587 |
588 | 平均下来压缩会节省70%的文件体积。将代码压缩和服务端压缩合计起来，你可以期望你的用户只下载你写出来的未压缩文件体积的15%。
589 |
590 | ### 缓存头
591 |
592 | 与流行的观点相反，文件在浏览器缓存中的时间并没有那么久。你可以尽你自己的努力，通过使用Expires头来增加非首次访问时命中缓存的概率：
593 |
594 | 这也是一个在.htaccess中做的一次性配置工作：
595 |
596 | ExpiresActive On
597 | ExpiresByType application/x-javascript "access plus 10 years"
598 |
599 | 它的弊端是当你想更改这个文件时，你需要给它重命名，如果你已经处理好了合并的文件命名规则，那你就已经处理好这里的命名问题了。
600 |
601 | ### 使用CDN
602 |
603 | CDN是指“文件分发网络”（Content Delivery Network）。这是一项收费（有时候还相当昂贵）的托管服务，它将你的文件分发到世界上各个不同的数据中心，但代码中的URL却都是一样的，这样可以使用户更快地访问。
604 |
605 | 即使你没有CDN的预算，你仍然有一些可以免费使用的东西：
606 |
607 | - Google托管了很多流行的开源库，你可以免费使用，并从它的CDN中得到速度提升（译注：鉴于Google在国内的尴尬处境，不建议使用）
608 | - 微软托管了jQuery和自家的Ajax库
609 | - 雅虎在自己的CDN上托管了YUI库
610 |
611 | ## 加载策略
612 |
613 | 怎样在页面上引入脚本，这第一眼看起来是一个简单的问题——使用\元素，然后要么写内联的JavaScript代码或者是在src属性中指定一个独立的文件：
614 |
615 | // option 1
616 |
618 | // option 2
619 |
620 |
621 | 但是，当你的目标是要构建一个高性能的web应用的时候，有些模式和考虑点还是应该知道的。
622 |
623 | 作为题外话，来看一些比较常见的开发者会用在\元素上的属性：
624 |
625 | - language="JavaScript"
626 |
627 | 还有一些不同大小写形式的“JavaScript”，有的时候还会带上一个版本号。language属性不应该被使用，因为默认的语言就是JavaScript。版本号也不像想象中工作得那么好，这应该是一个设计上的错误。
628 | - type="text/javascript"
629 |
630 | 这个属性是HTML4和XHTML1标准所要求的，但它不应该存在，因为浏览器会假设它就是JavaScript。HTML5不再要求这个属性。除非是要强制通过难，否则没有任何使用type的理由。
631 | - defer
632 |
633 | （或者是HTML5中更好的async）是一种指定浏览器在下载外部脚本时不阻塞页面其它部分的方法，但还没有被广泛支持。关于阻塞的更多内容会在后面提及。
634 |
635 | ### \元素的位置
636 |
637 | script元素会阻塞页面的下载。浏览器会同时下载好几个组件（文件），但遇到一个外部脚本的时候，会停止其它的下载，直到脚本文件被下载、解析、执行完毕。这会严重影响页面的加载时间，尤其是当这样的事件在页面加载时发生多次的时候。
638 |
639 | 为了尽量减小阻塞带来的影响，你可以将script元素放到页面的尾部，在\之前，这样就没有可以被脚本阻塞的元素了。此时，页面中的其它组件（文件）已经被下载完毕并呈现给用户了。
640 |
641 | 最坏的“反模式”是在文档的头部使用独立的文件：
642 |
643 |
644 |
645 |
646 | My App
647 |
648 |
649 |
650 |
651 |
652 |
653 |
654 | ...
655 |
656 |
657 |
658 | 一个更好的选择是将所有的文件合并起来：
659 |
660 |
661 |
662 |
663 | My App
664 |
665 |
666 |
667 | ...
668 |
669 |
670 |
671 | 最好的选择是将合并后的脚本放到页面的尾部：
672 |
673 |
674 |
675 |
676 | My App
677 |
678 |
679 | ...
680 |
681 |
682 |
683 |
684 | ### HTTP分块
685 |
686 | HTTP协议支持“分块编码”。它允许将页面分成一块一块发送。所以如果你有一个很复杂的页面，你不需要将那些每个站都多多少少会有的（静态）头部信息也等到所有的服务端工作都完成后再开始发送。
687 |
688 | 一个简单的策略是在组装页面其余部分的时候将页面\的内容作为第一块发送。也就是像这样子：
689 |
690 |
691 |
692 |
693 | My App
694 |
695 |
696 |
697 | ...
698 |
699 |
700 |
701 |
702 | 这种情况下可以做一个简单的发动，将JavaScript移回\，随着第一块一起发送。
703 |
704 | 这样的话可以让服务器在拿到head区内容后就开始下载脚本文件，而此时页面的其它部分在服务端还尚未就绪：
705 |
706 |
707 |
708 |
709 | My App
710 |
711 |
712 |
713 |
714 | ...
715 |
716 |
717 |
718 | 一个更好的办法是使用第三块内容，让它在页面尾部，只包含脚本。如果有一些每个页面都用到的静态的头部，也可以将这部分随和一块一起发送：
719 |
720 |
721 |
722 | My App
723 |
724 |
725 | 
726 | ...
727 |
728 |
729 |
730 | ... The full body of the page ...
731 |
732 |
733 |
734 |
735 |
736 |
737 |
738 | 这种方法很适合使用渐进增强思想的网站（关键业务不依赖JavaScript）。当HTML的第二块发送完毕的时候，浏览器已经有了一个加载、显示完毕并且可用的页面，就像禁用JavaScript时的情况。当JavaScript随着第三块到达时，它会进一步增强页面，为页面锦上添花。
739 |
740 | ### 动态\元素实现非阻塞下载
741 |
742 | 前面已经说到过，JavaScript会阻塞后面文件的下载，但有一些模式可以防止阻塞：
743 |
744 | - 使用XHR加载脚本，然后作为一个字符串使用eval()来执行。这种方法受同源策略的限制，而且引入了eval()这种“反模式”。
745 | - 使用defer和async属性，但有浏览器兼容性问题
746 | - 使用动态\元素
747 |
748 | 最后一种是一个很好并且实际可行的模式。和介绍JSONP时所做的一样，创建一个新的script元素，设置它的src属性，然后将它放到页面上。
749 |
750 | 这是一个异步加载JavaScript，不阻塞其它文件下载的示例：
751 |
752 | var script = document.createElement("script");
753 | script.src = "all_20100426.js";
754 | document.documentElement.firstChild.appendChild(script);
755 |
756 | 这种模式的缺点是，在这之后加载的脚本不能依赖这个脚本。因为这个脚本是异步加载的，所以无法保证它什么时候会被加载进来，如果要依赖的话，很可能会访问到（因还未加载完毕导致的）未定义的对象。
757 |
758 | 如果要解决这个问题，可以让内联的脚本不立即执行，而是作为一个函数放到一个数组中。当依赖的脚本加载完毕后，再执行数组中的所有函数。所以一共有三个步骤。
759 |
760 | 首先，创建一个数组用来存储所有的内联代码，定义的位置尽量靠前：
761 |
762 | var mynamespace = {
763 | inline_scripts: []
764 | };
765 |
766 | 然后你需要将这些单独的内联脚本包裹进一个函数中，然后将每个函数放到inline_scripts数组中，也就是这样：
767 |
768 | // was:
769 | //
770 |
771 | // becomes:
772 |
777 |
778 | 最后一步是使用异步加载的脚本遍历这个数组，然后执行函数：
779 |
780 | var i, scripts = mynamespace.inline_scripts, max = scripts.length;
781 | for (i = 0; i < max; max += 1) {
782 | scripts[i]();
783 | }
784 |
785 | #### 插入\元素
786 |
787 | 通常脚本是插入到文档的中的，但其实你可以插入任何元素中，包括body（像JSONP示例中那样）。
788 |
789 | 在前面的例子中，我们使用documentElement来插到\中，因为documentElement就是\，它的第一个子元素是\：
790 |
791 | document.documentElement.firstChild.appendChild(script);
792 |
793 | 通常也会这样写：
794 |
795 | document.getElementsByTagName("head")[0].appendChild(script);
796 |
797 | 当你能控制结构的时候，这样做没有问题，但是如果你在写挂件（widget）或者是广告时，你并不知道托管它的是一个什么样的页面。甚至可能页面上连\和\都没有，尽管document.body在绝大多数没有\标签的时候也可以工作：
798 |
799 | document.body.appendChild(script);
800 |
801 | 可以肯定页面上一定存在的一个标签是你正在运行的脚本所处的位置——script标签。（对内联或者外部文件来说）如果没有script标签，那么代码就不会运行。可以利用这一事实，在页面的第一个script标签上使用insertBefore()：
802 |
803 | var first_script = document.getElementsByTagName('script')[0];
804 | first_script.parentNode.insertBefore(script, first_script);
805 |
806 | frist_script是页面中一定存在的一个script标签，script是你创建的新的script元素。
807 |
808 | ### 延迟加载
809 |
810 | 所谓的延迟加载是指在页面的load事件之后再加载外部文件。通常，将一个大的合并后的文件分成两部分是有好处的：
811 |
812 | - 一部分是页面初始化和绑定UI元素的事件处理函数必须的
813 | - 第二部分是只在用户交互或者其它条件下才会用到的
814 |
815 | 目标就是逐步加载页面，让用户尽快可以进行一些操作。剩余的部分可以在用户可以看到页面的时候再在后台加载。
816 |
817 | 加载第二部分JavaScript的方法也是使用动态script元素，将它加在head或者body中：
818 |
819 | .. The full body of the page ...
820 |
821 |
822 |
823 |
830 |
831 |