1.2　單頁應(yīng)用

單頁應(yīng)用（single-page application，SPA）由覆蓋了整個前端應(yīng)用功能的一個或幾個 JavaScript 文件組成，這些文件通常會被預(yù)先下載。Web 服務(wù)器或內(nèi)容分發(fā)網(wǎng)絡(luò)（content delivery network，CDN）返回 HTML 入口頁后，單頁應(yīng)用會加載 JavaScript、CSS 和其他資源。使用單頁應(yīng)用有很多好處，比如客戶端只需在應(yīng)用的生命周期開始時下載一次代碼，此后用戶會話中的全部應(yīng)用邏輯就都處于可用狀態(tài)。

單頁應(yīng)用通常通過 API 來與后端（也叫服務(wù)器端）的持久層交換數(shù)據(jù)。此外，單頁應(yīng)用避免了客戶端和服務(wù)器之間為了加載附加邏輯而導(dǎo)致的頻繁通信，做到在應(yīng)用的生命周期內(nèi)可以立刻渲染所有視圖。

上述這些能力都增強了用戶體驗，模擬了用戶與移動設(shè)備或桌面的原生應(yīng)用交互時的情況，用戶無須等待太長時間就可以在應(yīng)用中進行跳轉(zhuǎn)。

另外，單頁應(yīng)用中的路由機制完全由客戶端維護。這意味著每次更改視圖時，應(yīng)用都會更改 URL（uniform resource locator），以便用戶分享頁面鏈接或把 URL 加入書簽后仍可以直接訪問指定的頁面。單頁應(yīng)用也讓我們可以自由地決定如何在服務(wù)器端和客戶端之間劃分應(yīng)用邏輯。比如，我們可以打造一個“胖客戶端”和一個“瘦服務(wù)器端”，客戶端用來存儲邏輯，服務(wù)器端則用作持久層；或者打造一個“瘦客戶端”和一個“胖服務(wù)器端”，邏輯主要交給服務(wù)器端，而客戶端不執(zhí)行任何智能邏輯，只是響應(yīng) API 返回的狀態(tài)。

在過去的幾十年里，一直有著對“胖客戶端”和“瘦客戶端”哪種方式更好的討論，兩種觀點都曾成為主流。盡管有爭論，但這兩種方式都有各自的優(yōu)缺點。哪種才是更好的選擇往往取決于我們創(chuàng)建的應(yīng)用類型。如果想創(chuàng)建一個跨平臺的應(yīng)用，那么選擇“瘦客戶端”和“胖服務(wù)器端”的組合非常合適。通過這種方式，一個功能只需設(shè)計一次就可以讓部署在多種宿主環(huán)境的所有客戶端響應(yīng)存儲在服務(wù)器端的應(yīng)用狀態(tài)。

而當(dāng)創(chuàng)建桌面應(yīng)用時，離線存儲一些數(shù)據(jù)會是一個基本功能。在這種情況下，經(jīng)常選擇“胖客戶端”和“瘦服務(wù)器端”的組合。我們不需要在兩個地方管理業(yè)務(wù)邏輯，而只用客戶端進行管理，使用服務(wù)器端同步用戶數(shù)據(jù)。

然而，對于某些類型的應(yīng)用來說，單頁應(yīng)用存在一些缺點。因為要下載整個應(yīng)用，而不是只下載用戶當(dāng)前用到的部分，所以單頁應(yīng)用的首次加載時間可能比其他架構(gòu)長。如果應(yīng)用沒有設(shè)計好，下載時間可能會成為嚴(yán)重問題，尤其是在網(wǎng)絡(luò)連接不穩(wěn)定的智能手機、平板電腦等移動設(shè)備上。

現(xiàn)在，我們可以采用多種方式在客戶端直接緩存應(yīng)用內(nèi)容，從而緩解上述問題。除了代碼拆分或 JavaScript 模塊的懶加載，值得一提的技術(shù)當(dāng)屬漸進式 Web 應(yīng)用（progressive Web application，PWA）。漸進式 Web 應(yīng)用基于 Service Worker 提供了一系列新的能力。Service Worker 是瀏覽器在后臺獨立于網(wǎng)頁運行的腳本，用于提供離線體驗或推送通知等功能。

有了 Service Worker，就可以使用瀏覽器原生 API 為 Web 應(yīng)用制定緩存策略。這種模式被稱為離線優(yōu)先或緩存優(yōu)先，它是 Web 應(yīng)用向用戶提供內(nèi)容的最流行的策略。如果一個資源已被緩存并可離線使用，就先使用緩存，而不是直接從服務(wù)器下載；如果這個資源還沒有被緩存，就下載并緩存起來，以便將來使用。雖然這看起來很簡單，但是對于提升 Web 應(yīng)用的用戶體驗非常有用，特別是在移動設(shè)備上的用戶體驗。

單頁應(yīng)用的另一個缺點與 SEO（search engine optimization）有關(guān)。當(dāng)爬蟲（一種系統(tǒng)地爬取網(wǎng)頁并創(chuàng)建數(shù)據(jù)索引的程序）試圖爬取單頁應(yīng)用時，它很難為網(wǎng)頁的內(nèi)容創(chuàng)建索引，除非我們提供了其他方式來讓爬蟲獲取內(nèi)容。

通常情況下，當(dāng)想讓單頁應(yīng)用更好地被爬蟲爬取內(nèi)容時，我們往往會專門為爬蟲制定一個特殊策略。比如，當(dāng)請求 Netflix 的 Web 應(yīng)用的用戶代理被識別為爬蟲時，Netflix 就會將定位機制退化，避免根據(jù) URL 里的國家信息來決定提供什么內(nèi)容。這是一個非常機智的策略，因為爬蟲經(jīng)常只在同一個地理位置爬取全世界的網(wǎng)頁。

一口氣下載應(yīng)用的所有邏輯也會成為單頁應(yīng)用的一個缺點，因為如果代碼實現(xiàn)有問題或者沒有正確處理不再使用的對象，那么當(dāng)用戶從一個視圖跳轉(zhuǎn)到另一個視圖時，可能會導(dǎo)致潛在的內(nèi)存泄漏。這在大型應(yīng)用中可能是一個嚴(yán)重問題，因為可能需要花費幾天或幾周的時間重構(gòu)和改進，才能讓單頁應(yīng)用的代碼正常運行。如果加載單頁應(yīng)用的硬件資源有限，比如智能電視或機頂盒，那么情況可能會更糟。我經(jīng)常看到一些應(yīng)用在四核的 MacBook Pro 上流暢運行，而在低端設(shè)備上運行時卻一塌糊涂。

單頁應(yīng)用的最后一個缺點是在團隊組織方面。當(dāng)大型單頁應(yīng)用由多個團隊在同一個代碼庫中共同開發(fā)時，這個應(yīng)用的不同部分可能會混合使用各種方法和策略，以至于讓團隊成員感到困惑。團隊合作時的溝通成本經(jīng)常是應(yīng)用開發(fā)工作的隱性成本。

復(fù)雜的項目導(dǎo)致團隊效率低下的問題經(jīng)常會被忽略，這并不是因為團隊沒有足夠的開發(fā)能力，而是因為公司的結(jié)構(gòu)或組織架構(gòu)讓他們的能力無法以最好的方式表現(xiàn)出來，以至于在開發(fā)一個新功能的過程中，執(zhí)行效率低下，產(chǎn)生了外部依賴，甚至出現(xiàn)沖突摩擦。此外，因為許多關(guān)鍵性決定可能不是出自開發(fā)人員，或者在開發(fā)人員加入公司時的幾個月前，甚至幾年前，這個大型單頁應(yīng)用的代碼庫就已經(jīng)存在了，所以他們會缺少主人翁精神。

所有這些情況都不會在公司每月的費用清單中有所體現(xiàn)，但是它們可能會影響團隊的產(chǎn)出，因為復(fù)雜的代碼庫會大大地降低團隊的交付能力。