摘要：為使瀏覽器載入大量模塊時(shí)不會(huì)造成內(nèi)存占用過(guò)高，瀏覽器應(yīng)能使被移除后的模塊能被完全釋放。瀏覽器應(yīng)使模塊運(yùn)行在獨(dú)立空間中，以保證模塊自身錯(cuò)誤時(shí)不至于導(dǎo)致整個(gè)應(yīng)用停止工作。

IOING 在你的代碼和瀏覽器之間架設(shè)了一個(gè)中間解釋層，該解釋層提供了一套新的語(yǔ)法來(lái)填補(bǔ)瀏覽器所不具備的能力。

開(kāi)發(fā)一個(gè) SPA 應(yīng)用的痛點(diǎn)是不同模塊頁(yè)面的狀態(tài)保存，當(dāng)從一個(gè)頁(yè)面跳轉(zhuǎn)到另一個(gè)頁(yè)面的時(shí)候窗口的所有狀態(tài)都將被清空重載，歷史頁(yè)面與當(dāng)前頁(yè)面將不產(chǎn)生任何聯(lián)系，這個(gè)過(guò)程是一個(gè)拆毀重建的過(guò)程，如果你要回到歷史同樣只能再次拆毀重建，并且在這個(gè)過(guò)程中不可避免的出現(xiàn)加載期的窗口白屏，顯然這樣的丑陋效果不符合一個(gè)高貴 App 的設(shè)定，但正因這種方式前后頁(yè)面不共存的簡(jiǎn)單特性也使得開(kāi)發(fā)邏輯變得簡(jiǎn)單，開(kāi)發(fā)者只需考慮單個(gè)頁(yè)面的邏輯即可，而每一次新頁(yè)面的加載都能將之前頁(yè)面進(jìn)行完全釋放，完全不需要擔(dān)心高耦合和內(nèi)存無(wú)法完全釋放的問(wèn)題，這也算是傳統(tǒng)技術(shù)的優(yōu)點(diǎn)，雖然簡(jiǎn)單粗暴，但是它很管用。那到底有沒(méi)有兩全其美的辦法呢？

和 SPA 應(yīng)用不同的是多頁(yè)面應(yīng)用往往相對(duì)要變得簡(jiǎn)單，頁(yè)面與頁(yè)面之間不需要有復(fù)雜的數(shù)據(jù)交換，也無(wú)需保存頁(yè)面歷史狀態(tài)，因此使用傳統(tǒng)技術(shù)最適合不過(guò)了。

而 SPA 應(yīng)用則要協(xié)調(diào)頁(yè)面間的關(guān)系，它的每一個(gè)模塊都可能是聯(lián)動(dòng)的，而且需要保持窗口的數(shù)據(jù)狀態(tài)，因而催生了另一個(gè)技術(shù)的流行，即通過(guò)使用 Ajax 和模版將新模塊內(nèi)容載入到當(dāng)前頁(yè)面，但這也導(dǎo)致新載入模塊的腳本和 DOM 樹(shù)內(nèi)容在主文檔下不斷堆積，且在不需要時(shí)也無(wú)法將其很好移除和釋放（比如 setTimeout 等僵尸事件）。另一種情況是一旦其中一個(gè)模塊發(fā)生錯(cuò)誤將很有可能導(dǎo)致整個(gè) SPA 應(yīng)用崩潰。

除了高耦合問(wèn)題外，Ajax 每次載入大量的 DOM 結(jié)構(gòu)到主 DOM Tree 下時(shí)都將可能會(huì)導(dǎo)致這個(gè)龐大的 DOM Tree 進(jìn)行 reflow(回流) 和 repaint(重繪)，從而影響整體運(yùn)行效率

基于上述分析，我們要得到一個(gè)穩(wěn)定的 SPA 應(yīng)用時(shí)必須改造瀏覽器使其支持以下特性：

為保證應(yīng)用松耦合，瀏覽器必須具備能夠使新加載的模塊與已加載模塊不產(chǎn)生相互干擾的能力。

為使瀏覽器載入大量模塊時(shí)不會(huì)造成內(nèi)存占用過(guò)高，瀏覽器應(yīng)能使被移除后的模塊能被完全釋放。

瀏覽器應(yīng)使模塊運(yùn)行在獨(dú)立空間中，以保證模塊自身錯(cuò)誤時(shí)不至于導(dǎo)致整個(gè)應(yīng)用停止工作。

只有具備了這些特性時(shí)才能保證一個(gè)大型 WEB 應(yīng)用的穩(wěn)定運(yùn)行，那么對(duì)于上述問(wèn)題 IOING 是怎么處理的呢？

首先為了保證模塊的代碼錯(cuò)誤不至于影響整個(gè)應(yīng)用的運(yùn)行，我們需要保證除引擎外的所有不可控腳本都不能運(yùn)行在主 window 下，而模塊腳本自需要運(yùn)行在多帶帶的沙盒中。

沙盒（Sandbox）簡(jiǎn)單來(lái)講就是:
無(wú)需解釋大家也就都懂了，但是很多人在看到 iframe 時(shí)就開(kāi)始各種擔(dān)心起來(lái)，聯(lián)想起各種文章對(duì) iframe 的負(fù)面描述。這里需要解釋一下，iframe 直接作為嵌入網(wǎng)頁(yè)使用時(shí)確實(shí)會(huì)占用當(dāng)前頁(yè)面連接池，但其在引擎中其主要目的是作為沙盒使用而并不是為了嵌入網(wǎng)頁(yè)使用的，當(dāng)引擎將編譯好內(nèi)容時(shí)會(huì)先主動(dòng)創(chuàng)建一個(gè)空 iframe，然后直接將編譯內(nèi)容直接丟入其中，注意 iframe 的 src="_blank"，這是一個(gè)空頁(yè)面，該情況下 iframe 并不會(huì)共享主窗口連接池。

我們?cè)O(shè)想一下這樣一個(gè)場(chǎng)景：你在瀏覽器打開(kāi)多個(gè)窗口分別載入不同的模塊頁(yè)面，然后在你需要打開(kāi)其他頁(yè)面時(shí)能通過(guò)自定義動(dòng)畫(huà)使瀏覽器窗口進(jìn)行動(dòng)畫(huà)過(guò)渡將頁(yè)面展示，當(dāng)你返回時(shí)也能通過(guò)反向動(dòng)畫(huà)再將之前窗口內(nèi)容過(guò)渡回來(lái)，如果瀏覽器支持這些或許 webApp 看起來(lái)將更酷，但現(xiàn)實(shí)是瀏覽器并沒(méi)有這樣的操作??♂?。

而這個(gè)設(shè)想可以通過(guò)沙盒來(lái)實(shí)現(xiàn)，在沙盒中的頁(yè)面就像新開(kāi)一個(gè)瀏覽器窗口那樣，能夠很好的隔離模塊的 DOM 元素和變量，也能保存頁(yè)面狀態(tài)，并能通過(guò)動(dòng)畫(huà)控制其轉(zhuǎn)場(chǎng)。

沙盒雖然很穩(wěn)妥，但其過(guò)于獨(dú)立，這導(dǎo)致模塊內(nèi)元素不能突破沙盒限制顯示在模塊外區(qū)域，比如說(shuō)一些復(fù)合型模塊（即嵌入主模塊中的模塊，沙盒一般適用與獨(dú)立的全屏模塊），當(dāng)你有這個(gè)需求時(shí)沙盒特性則不能滿(mǎn)足你，此時(shí)你應(yīng)該支持另一種模塊運(yùn)行方式：shadowbox 應(yīng)運(yùn)而生。

使用 shadowbox 配置的模塊，其模塊內(nèi)容將以一顆新 DOM Tree 插入到主 DOM Tree 中（即 shadowdom 方式），這顆新 DOM Tree 中的 CSS樣式 和 元素id 將不會(huì)和外部元素耦合，而此時(shí)模塊的 js 文件則依舊在其沙盒中運(yùn)行。（若運(yùn)行瀏覽器不支持該特性時(shí)應(yīng)自動(dòng)降級(jí)處理）

當(dāng)然只有一個(gè)沙盒模型是遠(yuǎn)遠(yuǎn)不夠的，比如組件同樣需要一套合理運(yùn)作機(jī)制。之后「兩分鐘了解IOING」將會(huì)繼續(xù)推出以下話(huà)題：

組件設(shè)計(jì)與通信

模塊刷新機(jī)制

量子 DOM 原理（和 Def 算法不同的數(shù)據(jù)雙向綁定設(shè)計(jì)）

CSS 引擎的設(shè)計(jì)思想

更多敬請(qǐng)期待...

IOING在開(kāi)發(fā)SPA大型應(yīng)用時(shí)有哪些必要的技術(shù)條件？
如何用 js 獲取虛擬鍵盤(pán)高度？（適用所有平臺(tái)）
讓 CSS 完成背景圖加載完畢后顯示 之 解析 IOING 的 onload url 原理

IOING 是一款高性能的前端開(kāi)發(fā)引擎。它為創(chuàng)建一個(gè)大型應(yīng)用提供一整套的完備方案，如頁(yè)面模塊化拆分、層級(jí)路由控制、可編程CSS、熱拔插組件、雙向數(shù)據(jù)綁定、DOM語(yǔ)法擴(kuò)展、自動(dòng)兼容處理等

掃碼二維碼關(guān)注我的公眾號(hào)：

傳送門(mén)：IOING 仿ios界面

傳送門(mén)：官網(wǎng)

傳送門(mén)：Github 項(xiàng)目地址