60年代時，作業系統中獨立運作的單元通常是程序。但随着計算機技術的發展，人們發現在程序運作過程中，建立、撤銷與切換都要花費較大的時空開銷。
到了80年代為了解決這一問題，出現了更小的獨立運作基本機關——線程。
作業系統把 CPU 處理時間劃分成許多更小的時間片，在每一個獨立時間片執行一個線程的指令，到下一個時間片繼續執行下一線程的指令，各線程輪流執行，由于每一個時間片時間都比較短，所有線程都會運作，對于使用者而言就好像所有線程在同時進行。最終達到的效果就是在程式設計時可以建立多個線程，同一時間運作，各線程可以"并行"運作，以完成不同的任務。
這時新的問題也出現了，在單獨線程的運作模式之下，一段代碼調用另一段代碼時，隻能采用同步調用，隻有目前代碼執行完成傳回結果之後，調用才能繼續往下執行。用一個例子就是現在隻有一個水槽，一匹馬想喝水隻能等上一匹馬走了才能繼續喝。
而有了多線程的支援，可以采用異步函數的調用，這個問題就迎刃而解了。
程式中會有很多内容，計算内容複雜、渲染内容繁多，在處理過程中需要花費比較多的時間。當某個子產品A調用了子產品B的處理内容時，這時子產品B中的内容就需要一些時間處理，此時子產品A如果不停地等待，就會嚴重影響程式性能。在實際情況中，就比如在前端頁面中需要進行線上填報的資料處理，需要對資料内容進行計算後放入表格中展示，這是由于計算并未完成，頁面内容也不顯示，給使用者帶來的感覺就是内容都點選運作了，但是頁面遲遲沒有任何回報。
出現了異步函數的調用之後，此時執行的子產品A和子產品B分别屬于不同的線程。
在異步調用中，子產品A不需要等到子產品B傳回内容，就可以繼續執行後續代碼。
子產品B中的内容執行完畢後，會通知子產品A：我這邊處理完畢，你記得處理後續内容。
借助異步調用，可以把剛剛我們提到的前端頁面中顯示問題進行優化：把整個初始化處理放進一個單獨線程，主線程啟動此線程後接着往下走，讓主視窗瞬間顯示出來。等思索需要進行的操作的内容時，資料計算處理就已經在暗中處理完畢；程式開始穩定運作以後，異步調用還可以進一步優化人機互動的過程。使用者點選滑鼠時進行操作的時候，操作内容比較費時，點選後系統沒有立馬作出回應，這會讓使用者的使用體驗很糟糕。将更費時、速度更慢的操作内容轉為異步調用，讓主線程随時恭候下一條消息，這樣使用者的滑鼠操作動作響應速度更快，使用體驗自然大大提升。
我們用一個簡單的例子，看看在前端電子表格單元格計算中，如何使用異步函數。
在這個算法中我們将設定的計算解析方法部分放在伺服器上，方法名稱叫DECODE
下一步将參數用jquery.get請求發送到伺服器中，然後擷取請求内容後完成設定
然後将整個異步函數注冊進入Spread中
最後在B1單元格中，輸入DECODE(A1)
這樣當A1單元格内容發生變化的時候，B1就會根據我們設定的計算規則重算成對應内容
工具總在不同人手中被挖掘出各種各樣的用法，而在去年冬天我們就收到了使用者回報的異步函數的各種奇妙使用方式。
他們使用異步函數的參數組合成了一個SQL，發送給資料庫進行資料查詢，并在查詢結束後顯示查詢結果。結果一切正确，但是卻出現了一個小問題。
在使用過程中，使用者發現查詢在整個過程中超過了 四次 ，詢問我們是否是公式出錯？
我們當即開展問題排查，在檢視源代碼的過程中我們發現，在最早實作這個功能的時候為了強調資料重要性，當同一個公式中出現多個異步函數調用時，再次計算下一個内容時我們還會再計算一次已經計算過的異步函數的内容。
沒想到使用者确實會這樣使用異步函數，這一部分内容随後也進行整體調整。現已調整為每次調用隻計算一次異步函數。
有了這次經曆，再遇到使用者對異步函數的其他花裡胡哨的用法，我們就見怪不怪了。
果不其然，沒多久又收到了其他使用者的花式使用回報。
這一次使用者使用異步函數從伺服器擷取目前服務名，并在SpreadJS顯示出來。
我們發現這個使用者還在其中添加了格式字元串，用以擷取使用者的二維碼。同時在這裡還設定了條件格式，如果使用者沒有登入會有報錯提示。
這個例子内容雖短，但在這裡使用者将異步函數、條件、格式還有格式字元串三個功能都結合在一起使用。
以上就是我們全部對異步函數誕生背景和原理，以及在前端電子表格中異步函數的使用和各種神仙使用者的花式使用，到本節關于電子表格計算原理的全部内容就已經介紹完畢。
覺得内容不錯點個贊再走吧~
本文是由葡萄城技術開發團隊釋出，轉載請注明出處：葡萄城官網