寫在前面
- 書籍介紹：《JavaScript異步編程》講述基本的異步處理技巧，包括PubSub、事件模式、Promises等，通過這些技巧，可以更好的應對大型Web應用程式的復雜性，互動快速回應的代碼，理解了JavaScript的異步模式可以讓讀者寫出結構更合理、性能更出色、維護更方便的JavaScript程式，
- 我的簡評：js異步編程的科普小書，內容比較全面但不夠深入，作為前端開發，了解異步處理機制和優化異步代碼非常重要，特別推薦一下《JavaScript異步編程》，
- ！！福利：文末有pdf書籍、筆記思維導圖、隨書代碼打包下載地址哦！想看看[書籍精讀]系列所有文章，請移步：[推薦收藏]JavaScript書籍精讀筆記系列導航
第一章 深入理解JavaScript事件
1.1.事件的調度
- JavaScript代碼用于不會被中斷，因為代碼在運行期間只需要排隊事件即可，而這些事件在代碼運行結束之前不會被觸發
1.2.異步函式的型別
- 每一種JavaScript環境都有自己的異步函式集
- 在瀏覽器端，Ajax方法有一個可設定為false的async選項
- 在Node.js中同步的API方法在名稱上會有明確的標示如fs.readFileSync
- WebKit的console.log列印輸出并沒有立即拍攝物件快照，只存盤了一個指向物件的參考，等代碼回傳事件佇列才去列印輸出快照
- Node的console.log是嚴格同步的
- 當同一個JavaScript行程正運行著代碼時，任何JavaScript計時函式都無法使其他代碼運行
- setInterval調度事件設定成0，chrome等瀏覽器觸發頻率大約為200次/秒，node大約是1000次/秒
- 替換成while回圈時在Chrome中觸發頻率達到400萬次/秒，在node中會達到500萬次/秒
- 需要更細粒度的計時，在node中使用process.nextTick，在現代瀏覽器中使用requestAnimationFrame(主意兼容性)
1.3.異步函式的撰寫
- 要想確認某個函式異步與否，唯一的方法就是審查其源代碼
- 有些函式某些時候是異步的，但其他時候卻不是
- 大量延時的話，會造成巨大的計算荷載
- 異步遞回有一點很害怕，即在等待任務完成期間，可觸發延時的次數是不受限的
- 永遠不要定義一個潛在同步而返值卻有可能用于回呼的函式
1.4.異步錯誤的處理
- JavaScript也允許拋出例外，隨后再用一個try/catch陳述句塊捕獲
- 正因如此，Node.js中的回呼幾乎總是接受一個錯誤作為其首個引數，這樣就允許回呼自己來決定如何處理這個錯誤
- 始終記住，只能在回呼內部處理源于回呼的異步錯誤
- 在瀏覽器環境中，windows.onerror可以捕獲例外，如果回傳true，則能阻止瀏覽器默認的錯誤處理行為
- 在node中，類似的process物件的uncaughtException事件捕獲錯誤，正常情況下，node應用會因未捕獲的例外而立即退出
- 但自Node0.8.4起，uncaughtException事件就被廢棄了
- domain物件是事件化物件，它將throw轉化為error事件
1.5.嵌套式回呼的解嵌套
- 最常見的反模式做法是，回呼內部再嵌套回呼
- 嵌套式回呼傭訓我們通過添加更多代碼來添加更多特性，而不是將這些特性實作為可管理、可重用的代碼片段
- 按照慣例，請避免兩層以上的函式嵌套
第二章 分布式事件
- 希望使用分布式事件：事件的蝴蝶偶然扇動下翅膀，整個應用到處都引發反應
- PubSub意為發布/訂閱，模式來分發事件
- PubSub模式的一些具體表現：Node的EventEmitter物件，Backbone的事件化模型，JQuery的自定義事件
2.1.PubSub模式
- Node中幾乎所有的I/O都是EventEmitter物件：檔案流、HTTP服務器，甚至是應用行程本身
- 事件處理器本身無法知道自己是從事件佇列中還是從應用代碼中運行的
- 對于無需即刻發生的事情維持一個佇列，并使用一個計時函式定時運行此佇列中的下一項任務
- PubSub簡化了事件的命名、分發、堆積
2.2.事件化模型
- 只要物件帶有PubSub介面，就可以稱之為事件化物件
- 每次一個物件上的事件引發了一系列事件并最終對這個物件本身觸發了相同的事件，結果就事件回圈了
- 事件化模型為我們帶來了一種將應用狀態變化轉換為事件的直觀方式
2.3.jQuery自定義事件
- jQuery簡化了強大分布式事件系統向任何Web應用程式的移植
- jQuery提供了非冒泡式的triggerHandler方法
- jQuery的自定義事件允許直接通過DOM來表達DOM相關的事件，不必再把DOM變化的狀態復制到應用程式的其他地方
小結
- PubSub模式尤其不適合一次性事件
- 用于解決一次性事件問題的工具叫做Promise
第三章 Promise物件和Deferred物件
3.1.Promise極簡史
- Promise物件也和EventEmitter物件一樣，允許向同一個事件系結任意多個處理器(堆積技術)
- 使用Promise物件的最大優勢在于，可以輕松從現有Promise物件派生出新的Promise
- 在一般性用法中，Promise、Deferred和Future這三個詞大體可算作同義詞
3.2.生成Promise物件
- 準確的說，Deffered是Promise的超集，它比Promise多一項關鍵特性，可以直接觸發
- 重申一點：每個Deferred物件都含有一個Promise物件，而每一個Promise物件都代表者一個Deferred物件
- Ajax是演示Promise的絕佳用例：每次對遠程服務器額呼叫都或成功或失敗，而我們希望以不同的方式來處理這兩種情況
3.3.向回呼函式傳遞資料
- 執行或拒絕Deferred物件時，提供的任何引數都會轉發至相應的回呼
- resolve/reject可以直接將其背景關系傳遞至自己所觸發的回呼
3.4.進度通知
- jQuery1.7中為Promise物件新添了一種可以呼叫無數次的回呼progress
- 總結下，Promise物件接受3種回呼形式：done、fail、progress
3.5.Promise物件的合并
- Promise物件的邏輯合并技術有一個最常見的用例：判定一組異步任務何時完成
3.6.管道連接未來
- JavaScript中常常無法便捷的執行一系列異步任務，一個主要原因是無法在第一個任務結束之前就向第二個任務附加處理器
- jQuery1.6為Promise物件新增pipe(管道)方法
- promise.promise() === promise
3.7.jQuery與Promises/A的對比
- jQuery使用resolve作為fail的反義詞，而Promise/A使用的是fulfill，在Promise/A規范中，Promise物件不管是已履行還是已失敗，都是已執行
3.8.用Promise物件代替回呼函式
- 理想情況下，開始執行異步任務的任何函式都應該回傳Promise物件
- Promise大大有助于讓意大利面式的回呼趨于平滑，而且也是因為Promise可以非常輕松的協調這種型別的異步任務
第四章 Async.js的作業流控制
4.1.異步作業流的次序問題
- 普通的異步代碼根本無法保證按照做出呼叫次序來觸發呼叫的回呼
4.3.Async.js的任務組織技術
- Async.js的資料收集方法解決了一個異步函式如何運用于一個資料集的問題
- 異步函式序列的運行：async.series和async.waterfall
- 便利的是Async.js按照任務串列的次序向完工事件處理器傳遞結果，而不是按照生成這些結果的次序
- Async.js的內核與靈魂：為最常見的異步情景提供簡單又省時的工具函式
4.4.異步作業流的動態排隊技術
- async.queue的底層基本理念令人想起DMV動態管理視圖
第五章 worker物件的多執行緒技術
5.0.寫在前面
- 事件能夠代替一種特殊的多執行緒，即應用程式行程可拆分成多個部分同時運行的多執行緒技術（或者通過中斷技術虛擬實作，或者通過多個CPU內核真正實作）
- 盡管只運行在一個執行緒上確實不理想，但天真的將應用直接分發給多個內核更加糟糕
- 與不同執行緒進行互動的方式與在JavaScript中進行I/O操作一摸一樣
- 同一個行程內的多個執行緒之間可以分享狀態，而彼此獨立的行程之間則不能
- 在JavaScript環境中，由worker物件運行的并發代碼從來不會分享狀態
5.1.網頁版的worker物件
- 首要目標，在不損害DOM回應能力的前提下處理復雜的計算
- 幾種潛在用法：解碼視頻、加密通信、決議網頁式編輯器
- 基于類似的理由，worker物件看不到全域的window物件和主執行緒及其他worker執行緒的任何物件
- 通過postMessage發送的物件會透明的做序列化和反序列化，想想JSON.parse與JSON.stringify
- worker物件可以隨意使用XMLHttpRequest
- 還有一個importScripts函式可以同步加載并運行指定的腳本
5.2.cluster帶來的Node版worker
- node0.6后推出一個支持多個行程系結同一個埠的API:cluster（群集）
- 通常為追求最佳性能而使用cluster按每顆CPU內核分化出一個行程
- Node版worker物件由cluster.fork()把運行自己的同一個腳本再次加載成一個獨立的行程
- 瀏覽器可以將任意多余的執行緒降格為后臺任務，而node服務器則要留出計算資源保障其請求處理的主要任務
- 最著名的魔法：多個worker物件試圖監聽一個TCP埠時，node利用內部訊息來允許分享該埠
- 同樣，cluster物件有一個主執行緒和多個worker執行緒，之間基于一些帶有序列化物件或附連字串的事件
- 為了盡可能減少執行緒之間的通信開銷，執行緒間分享的狀態應該存盤在像Redis這樣的外部資料庫中
第六章 異步的腳本加載
- 需要對腳本分而治之，那些負責讓頁面更好看、更好用的腳本應該立即加載，而那些可以待會再加載的腳本稍后加載
6.1.局限性與補充說明
- 請盡量避免使用行內技術
- 請勿使用document.write
- 只要知道document.write相當于操控DOM時的GOTO陳述句就行了
6.2.script標簽的再認識
- 現代瀏覽器中的script標簽分成了兩種新型別：經典型和非阻塞型
- 流行將腳本放在頁面body標簽的尾部，一方面用戶可以更快的看到頁面，另一方面可以主動親密接觸DOM而無需等待事件來觸發自己
- defer讓我們想到靜靜等待檔案加載的有序排隊場景，那么async就會讓我們想到混亂的無政府狀態
- 一個腳本即用defer又用async，則在那些同時支持的瀏覽器中，async會覆寫defer
6.3.可編程的腳本加載
- 兩種合理的方法來抓取并運行服務器腳本：生成Ajax請求并用eval函式處理回應；向DOM插入script標簽
- require.js強大的工具包能夠自動和AMD技術一起捋順哪怕最復雜的腳本依賴圖
- 如果要求根據條件來加載腳本，請考慮像yepnope這樣的腳本加載器，如果站點大量相互依賴的腳本，請考慮require.js
寫在后面
- pdf書籍、筆記思維導圖、隨書代碼打包下載地址：https://pan.baidu.com/s/1WMzAciLMfTasiWFQjz4ftA（提取碼：wd01）
- 紙質書京東購買地址：https://u.jd.com/e0BT68（推薦使用紙質書來學習）
- 為了方便在手機上查看，后面我會把這些筆記陸續發布到公眾號“派三派四”，可以掃碼關注一下，歡迎關注，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/118303.html
標籤：JavaScript