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

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

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

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

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

除了高耦合問題外，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)存占用過高，瀏覽器應(yīng)能使被移除后的模塊能被完全釋放。

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

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

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

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

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

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

沙盒雖然很穩(wěn)妥，但其過于獨(dú)立，這導(dǎo)致模塊內(nèi)元素不能突破沙盒限制顯示在模塊外區(qū)域，比如說一些復(fù)合型模塊（即嵌入主模塊中的模塊，沙盒一般適用與獨(dú)立的全屏模塊），當(dāng)你有這個(gè)需求時(shí)沙盒特性則不能滿足你，此時(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)降級處理）

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

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

模塊刷新機(jī)制

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

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

更多敬請期待...

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

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

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

傳送門：IOING 仿ios界面

傳送門：官網(wǎng)

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